Can I send changes of git staged area for code review (to any code review tool)?

Question

I learned that git has notion of different file states: 1. New 2. Modified 3. Staged 4. Committed

After searching a lot, what I have found is if I want to send for code review to any tool, I have to make commit to local repository and push it to some central repo set for code review (by any code review tool e.g. Gerrit).

Now, suppose file was in state A before starting code review process and it went through 10 more reviews rework i.e. 10 more modifications i.e. 10 more commits to local repository and finally file is in state B, which should finally be committed.

From state A to B 10 commits were done.

Assume of these 10, 4 commits were on same section / part of file.

So, finally, when I will push reviewed and accepted file's final state B to main central repository I will have to make 10 commits of which some intermediate commits took rework i.e. unwanted commits.

But I don't want those unwanted commits.

From what I can think is I am interested in final state B to be pushed to repository with only one commit.

So I am looking for any such approach / tool which allows git staged changes to be sent for reviewed. Reviewer will review. If he rejects and suggest some changes then I unstage previous changes. Apply suggested changes, stage those changes and again sent for review.

Thus finally when code reviewed accepts I will make single commit my staged changes and will need only single final push.

Answer 1

It is not possible to push uncommited changes in a git repository. However you could use different branches to achieve what you want. You could work on a development branch, and make as many commits as you want. You can push them to a certain development branch on the remote server. After the reviewer accepts the changes, you can merge the commits into the main branch. If you want, you can use git rebase to merge the commits into one single commit.

Answer 2

git push origin stash@{0}^1:refs/heads/tmp/for-code-review

That will push your stashed index to be reviewable

• replace "origin" with whatever remote is accessible to others
• replace "@{0}" with whatever stash number you are wanting reviewed
• if you want your stashed filesystem changes to be reviewed, then remove the "^1" part.
• if you want both your stashed index and stashed filesystem to be reviewed, then push index first (with ^1), then non-index (no ^1).

---

here are reasons why it's better to use a uniquely created, separate branch:

• presumably you are going to merge your changes somewhere if code review passes. you can't merge stashes into anything.
  • the parent history is butt-ugly. Your two stash commits both share the same parent. The "WIP" is technically a merge commit, but that's not really indicative of what's going on.
  • The commit messages are bad.
• With a branch, you can actually change your code according to the feedback of the code review -- which is the entire point of having a code review. You can add more commits, remove commits, rebase, squash, etc. You can't do that with stashes. (or rebase, etc)

To me, I don't feel like I really need to "convince" anyone to use branches instead because everyone who tries using stashes like this (or some other way) will figure out for themselves that the right/better/easier way is to just use side branches for work/code-reviews. aka git branch bugfix/xyz; edit...; git push origin bugfix/xyz;

Answer 3

I believe most code review tools will take a diff, so just use 'git diff' to produce the appropriate diff of your code to be reviewed.

As for merging your multiple commits into one, well, there's more than one way to do it:

1. You may want to look on the manpage at the --squash option to git merge. Or read this SO article.

2. Alternately, you can do all the commits you want locally on your dev branch but before you merge to mainline, use git rebase to squash them together. See the manpage for details or read this SO article.