0

I am bit confused about how git review works ?

I got the official documentation here fine manual but am still unable to understand how modifying a downloaded change and then comitting and pushing it using git commit --amend and git review works with simple push ?

I mean, isn't this same as rewriting history/making changese to pushed commit ?

Also there is git review -R, wondering when n why to use that ?

mittal
  • 915
  • 10
  • 29
  • I have not actually *used* Gerrit but it must in fact use `git push`. I believe the reference it uses for a review is `refs/for/`, and clearly it is going to have to re-create that pointing to the new commit(s). – torek Apr 22 '17 at 03:53
  • You mean re-create the branch, meaning a new branch ? – mittal Apr 22 '17 at 06:21
  • 1
    I mean re-create the *reference*. `refs/for/abc` is not a branch name, it's just a reference. `refs/heads/master` is a branch name, and `refs/tags/v1.2` is a tag name, and all three of these are *references*. The word "reference" is the general form. Branches are references whose name starts with `refs/heads/`. When you run `git push`, you have your Git ask another Git to set or change references. That other Git is allowed to refuse; if you "force push" you send it a more insistent demand, which it might still refuse. Whether force push is required, or even sufficient, is [cont'd] – torek Apr 22 '17 at 06:25
  • 1
    ... is up to that other Git. To make `refs/for/abc` point to a new hash ID, Gerrit will do whatever is required, whether that's force-push, or delete-and-re-create, or whatever. Note that it's all up to Gerrit, your Git, and the foreign Git to figure out what it takes to make all this work—but as long as Gerrit is using `refs/for/` this never interferes with any *branch* since branches all start with `refs/heads/`. – torek Apr 22 '17 at 06:26

2 Answers2

0

If you:

  1. Download a OPEN change
  2. Make some changes
  3. Commit with --amend
  4. Push to Gerrit (refs/for/BRANCH)

You'll create a new PATCHSET for the previous change. The "git review" is just a tool to make the steps 1 and 4 more easy/automatic.

"git review -R" is used to skip the automatic "git rebase -i" step that is executed by git review before the push step. If you aren't sure what the "git rebase -i" does I think it's good don't use it.

I suggest you to read A Quick Introduction item on Gerrit documentation to learn more about Gerrit and to understand how it works

Marcelo Ávila de Oliveira
  • 19,950
  • 3
  • 39
  • 50
  • So it will create a new branch with the updated patchset ? Since trying to push on the same previous branch would require `--force` option ? This link https://github.com/github/hub/issues/908 makes some contrast between Gerrit and github – mittal Apr 22 '17 at 02:36
  • No. You're not pushing to the branch yet, you're pushing to review (a "magical" branch). I think you need to learn more about Gerrit to understand how it works. I suggest you to read "A Quick Introduction" item on Gerrit documentation: https://gerrit-review.googlesource.com/Documentation/intro-quick.html – Marcelo Ávila de Oliveira Apr 22 '17 at 13:31
  • I just added the Gerrit documentation to the answer. – Marcelo Ávila de Oliveira Apr 24 '17 at 17:03
  • Thanks for the explanation and the link. I found more gritty details here http://stackoverflow.com/questions/10461214/why-is-git-push-gerrit-headrefs-for-master-used-instead-of-git-push-origin-mast – mittal Apr 25 '17 at 07:09
  • In your answer, is this a typo "if you aren't sure ... it's good to use it" . Did you mean, not to use it ? – mittal Apr 25 '17 at 07:14
0

I found my complete answer here. Comments from torek and Marcelo also helped

Basically, pushing to gerrit is not pushing to branch but a staging area(pending changes) which are references to the branches to which eventually each of the commits will be merged

These refs are also not exactly refs but some Gerrit magic to fool the client into belief of there existance

Community
  • 1
  • 1
mittal
  • 915
  • 10
  • 29