El 30/12/2009, a las 23:24, Sylvain Rabot escribió:
So,
I tried again "git rebase --onto 12.72.1 master feature".
Situation :
a--a--a--a--a--a--a--a--a feature
/
--x--x--x--x--x--x--x--x--x--x--x--x master
\
o--o--o--o--o--o--o 12.72.1
Work flow :
$ git checkout 12.72.1
$ git rebase --onto 12.72.1 master feature
a lot of conflicts, resolving and git rebase --continue
And then, at the end of the rebase, without me doing anything, feature
branch is checked out and it seems that its HEAD has been reset to the
new 12.72.1 HEAD.
--x--x--x--x--x--x--x--x--x--x--x--x master
\
o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a 12.72.1 feature
Is that normal ? If it is, how do I do to avoid my feature branch to
be
reset at 12.72.1's HEAD ?
Any enlightenment is very welcome.
Look at the "git-rebase" man page, particularly the order of the
arguments, what they mean, and the usage examples of "--onto":
$ git rebase --onto 12.72.1 master feature
Means, "replay these changes on top of 12.72.1", where "these changes"
refers to commits on branch "feature" with upstream "master", which is
what "git rebase" did for you.
If you actually want the "feature" branch to continue pointing at the
old feature branch rather than your newly rebased one, you could just
look up the old SHA1 for it and update it with:
$ git branch -f feature abcd1234
Where "abcd1234" is the hash of the old "feature" HEAD.
But I don't really know why you'd want to do that. The purpose of "git
rebase" isn't to copy or cherry-pick commits from one branch onto
another, but to actually _move_ (or transplant, or replay, if you
prefer) those commits.
Maybe I misunderstood your intentions though.
Cheers,
Wincent
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html