<div dir="ltr">Hi Spyros<div><br></div><div>Thanks. That works great!</div><div>I have never heard of the `git cherry-pick` command previously.</div><div><br></div><div>The last 2 lines of my snippet should be replaced with:</div><div><font face="monospace, monospace">git checkout -b branch3b</font></div><div><font face="monospace, monospace">git cherry-pick branch3</font></div><div><br></div><div>And then it gives the correct history of commit1-commit2b-commit3.</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 8, 2015 at 7:50 PM, Spyridon (Spyros) Mastorakis <span dir="ltr"><<a href="mailto:mastorakis@cs.ucla.edu" target="_blank">mastorakis@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Junxiao,<br>
<br>
why do not you use git cherry-pick hash_of_commit3, while your are on a branch with commit2b as HEAD? I think that this should work. In case that you want to cherry-pick a commit from another remote repo, you will need to follow this process and then use git cherry-pick:<br>
<br>
<a href="http://stackoverflow.com/a/11477795" rel="noreferrer" target="_blank">http://stackoverflow.com/a/11477795</a><br>
<br>
Let me know if that works.<br>
<br>
--<br>
Spyridon (Spyros) Mastorakis<br>
Personal Website: <a href="http://cs.ucla.edu/~mastorakis/" rel="noreferrer" target="_blank">http://cs.ucla.edu/~mastorakis/</a><br>
Internet Research Laboratory<br>
PhD Computer Science<br>
UCLA<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
> On Sep 8, 2015, at 7:41 PM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:<br>
><br>
> Dear folks<br>
><br>
> Recently, Alex has been suggesting that commits in a feature branch (such as NFD management refactor, NDNLP implementation, etc) should not be merged until all commits are ready, and developers may start working on an unmerged parent commit.<br>
> This would require the developer to rebase their commits, if the parent commit changes.<br>
> I’m reluctant to do that, but prefers to wait for the parent commit to be merged before starting the next commit, because I had a lot of trouble in rebasing.<br>
><br>
> Specifically, my trouble starts with this situation:<br>
>       • commit1 is already merged.<br>
>       • commit2a is an unmerged commit on Gerrit, which is based on commit1.<br>
>       • commit3 is the commit that I’m working on, which is based on commit2a.<br>
>       • Now commit2a is modified, and the new patchset is commit2b, whose parent is still commit1.<br>
>       • I want to rebase commit3 on top of commit2b.<br>
> The situation can be re-created with the following git commands:<br>
> git init<br>
> touch file1<br>
> git add file1<br>
> git commit -m "commit1"<br>
> git checkout -b branch2<br>
> touch file2a<br>
> git add file2a<br>
> git commit -m "commit2a"<br>
> git checkout -b branch3<br>
> touch file3<br>
> git add file3<br>
> git commit -m "commit3"<br>
> git checkout branch2<br>
> git rm file2a<br>
> touch file2b<br>
> git add file2b<br>
> git commit -a --amend -m "commit2b"<br>
> git checkout branch3<br>
> git rebase branch2<br>
><br>
> Expected: `git log branch3` shows commit1-commit2b-commit3<br>
> Actual: `git log branch3` shows commit1-commit2b-commit2a-commit3<br>
><br>
> git doesn't seem to recognize that commit2b is a replacement of commit2a, and therefore keeps both.<br>
> This happens only if there's no conflict between commit2a and commit2b.<br>
> When there's a conflict, git would tell me to run `git rebase --skip` which would give the correct results.<br>
><br>
> If Alex or another git guru can help me solve this problem, I would be happy to start using unmerged parent commits.<br>
><br>
> Yours, Junxiao<br>
><br>
<br>
</div></div></blockquote></div><br></div></div></div>