[Nfd-dev] git rebase question

[Spyridon (Spyros) Mastorakis]

Hi Junxiao,

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:

http://stackoverflow.com/a/11477795

Let me know if that works.

--
Spyridon (Spyros) Mastorakis
Personal Website: http://cs.ucla.edu/~mastorakis/
Internet Research Laboratory
PhD Computer Science
UCLA





> On Sep 8, 2015, at 7:41 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Dear folks
> 
> 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.
> This would require the developer to rebase their commits, if the parent commit changes.
> 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.
> 
> Specifically, my trouble starts with this situation:
> 	• commit1 is already merged.
> 	• commit2a is an unmerged commit on Gerrit, which is based on commit1.
> 	• commit3 is the commit that I’m working on, which is based on commit2a.
> 	• Now commit2a is modified, and the new patchset is commit2b, whose parent is still commit1.
> 	• I want to rebase commit3 on top of commit2b.
> The situation can be re-created with the following git commands:
> git init
> touch file1
> git add file1
> git commit -m "commit1"
> git checkout -b branch2
> touch file2a
> git add file2a
> git commit -m "commit2a"
> git checkout -b branch3
> touch file3
> git add file3
> git commit -m "commit3"
> git checkout branch2
> git rm file2a
> touch file2b
> git add file2b
> git commit -a --amend -m "commit2b"
> git checkout branch3
> git rebase branch2
> 
> Expected: `git log branch3` shows commit1-commit2b-commit3
> Actual: `git log branch3` shows commit1-commit2b-commit2a-commit3
> 
> git doesn't seem to recognize that commit2b is a replacement of commit2a, and therefore keeps both.
> This happens only if there's no conflict between commit2a and commit2b.
> When there's a conflict, git would tell me to run `git rebase --skip` which would give the correct results.
> 
> If Alex or another git guru can help me solve this problem, I would be happy to start using unmerged parent commits.
> 
> Yours, Junxiao
>