[Nfd-dev] git rebase question

[Eric Newberry]

Junxiao,

This is actually the process I've used to rebase all of my commits to NDN.

--
Eric Newberry

Computer Science Undergraduate
The University of Arizona
Vice President, University of Arizona ACM Student Chapter

On 9/8/2015 7:50 PM, Spyridon (Spyros) Mastorakis wrote:
> 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
>>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev