0

I use gerrit. I have fetched a remote repository. Now I have two options checkout or cherry-pick. I have tried the second options (cherry-pick) and the result that I got this way looks to me as I wonted (in my local repository I see my changes of the code as well a the changes introduced by the commit that I have fetched and cherry-picked).

However, my colleague insist that I need to checkout because "checkout also merges its dependencies". I have tried to checkout but, as a result, I do not see my changes in the code (I see only the changes introduced by the remote commit, that I have fetched and checked out). This behavior is, kind of, makes sense to me as well (I just put the HEAD of the repository to another "line of changes", it is like I switch to completely another brunch and, as a consequence, I do not see there changes from my original branch, where I did all my changes).

Now, I want to understand what my colleague wants from me. Why should I checkout and how exactly should it be done (with what sequence of commands)? Should I first create a new branch for the remote changes that I will check out? Should I merge this new branch into my branch with my changes?

Roman
  • 124,451
  • 167
  • 349
  • 456
  • 1
    I guess you fetched a `refs/changes/xx/yyyyy/z`. To checkout or cherry-pick FETCH_HEAD do different things. If you are going to apply the changes of that commit, `cherry-pick` does the job. If you are going to extract the files of that very revision, or switch to that revision, `checkout` brings them to your disk. Besides, if you are going to apply all of the changes including the commit's ancestors, you can merge FETCH_HEAD as the `Pull` command does. And the `Format Patch` commands create a patch of that commit. – ElpieKay Feb 07 '18 at 08:32
  • I guess I do not need to "extract" the files form a version since there are no new files in my case. How can I "merge FETCH_HEAD"? What exactly should I execute? In what branch should I be when I check out? Or it does not matter? – Roman Feb 07 '18 at 08:41
  • 1
    `git fetch origin xxx && git merge FETCH_HEAD` or simply `git pull origin xxx`. After fetch, you could run `git log HEAD..FETCH_HEAD` to find out the new commits you have fetched. `git cherry-pick ` introduces the very commit's changes and `git merge ` introduces all the changes of the commit and its ancestors. – ElpieKay Feb 07 '18 at 08:48

1 Answers1

3

Checkout doesn't merge anything (unless you use git checkout -m, but there is no hint in your question that you intend to use -m). The kind of git checkout you're alluding to, git checkout <commit>, simply checks out the specified commit. If the <commit> argument is not a local branch name, the result is a "detached HEAD" and you must, in general, eventually run git checkout <branch-name> to get back onto some named branch.

As ElpieKay noted in comments, you may really want to use git merge here. Or you may not: it depends on what you want to achieve. We cannot read the mind of your co-worker (any more than you can) and cannot tell you what he thinks you should be achieving here either. But you're correct in your description of git checkout.

Note that if you want to create a local branch name, pointing to the same commit identified by refs/changes/xx/yyyy/z, but usable as your own branch, you can use:

git checkout -b new-branch-name refs/changes/xx/yyyy/z

If you just want that commit to be your current commit (so that you can, e.g., run some tests on it or view its snapshot), you can use the detached HEAD you get by checking out that commit by that name or by its hash ID.

torek
  • 448,244
  • 59
  • 642
  • 775