On Tue, 12 Feb 2008, James Bottomley wrote:
>
> Right at the moment, I maintain a <branch> and a <branch>-base and
> simply cherry pick the commits between the two to do the right thing
> when I know my volatile base has changed. It would be very helpful to
> have a version of rebase that new my base had been rebased.
Hey, I know, you could use.. drumroll..
"git rebase"
I know that's a big leap of faith, to use git rebase for rebasing, but
there you have it. Us git people are kind of odd that way.
IOW, if you know the old broken base, and the new base, just do
git rebase --onto newbase oldbase
and it should do exactly that (basically lots of automated cherry-picks).
[ But the fact is, if you did anything fancy (like pulled in other peoples
work), you cannot sanely rebase _those_ peoples work. They didn't screw
up to begin with! You can play with "git rebase -i --preserve-merges",
of course, but I really think you're doing something wrong if you start
pulling other peoples work into an unstable thing, so while it may work,
I'd strongly suggest against even trying, because the problem is your
workflow ]
So let's say that you have a remote branch that you track that goes
rebasing (let's call it "origin/pu" to match the real-life git behaviour),
then you should literally be able to do
old=$(git rev-parse origin/pu) &&
git fetch &&
new=$(git rev-parse origin/pu) &&
git rebase --onto $new $old
and no, I didn't actually test it, but hey, it really should be that
simple.
[ And no, you don't really need to do those "old=" and "new=" things, they
are there to make it explicit - you could easily just have done
git fetch
.. oh, noticed that origin/pu changed ..
git rebase --onto origin/pu origin/[EMAIL PROTECTED]
where we just let git take care of the old/new itself using the reflog,
so that "origin/[EMAIL PROTECTED]" assumes that you just know that the only
thing
that has changed origin/pu was that previous "git fetch", and that
really *did* change it. ]
In other words, git does give you exactly what you want, but nothing
really changes the fact that you should only rebase like this only if:
- you haven't already exported the result (or only exported it as those
unstables branches that people know to avoid)
- your changes on top are just your own linear series of commits (where
"applying a patch from somebody else" is still _your_ commit, of
course, just with authorship attributed to somebody else)
so that part really is very fundamental.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
