[Nfd-dev] git rebase question

[Junxiao Shi]

Hi Spyros

Thanks. That works great!
I have never heard of the `git cherry-pick` command previously.

The last 2 lines of my snippet should be replaced with:
git checkout -b branch3b
git cherry-pick branch3

And then it gives the correct history of commit1-commit2b-commit3.

Yours, Junxiao

On Tue, Sep 8, 2015 at 7:50 PM, Spyridon (Spyros) Mastorakis <
mastorakis at cs.ucla.edu> 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150908/5edd744f/attachment.html>