Re: git-rebase skips automatically no more needed commits

From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Sep 28, 2011, 14:49 UTC
Message-ID: <CAOeW2eFyTewS2+QK7UW_yOWpVKtCkwSBH0PjPutn0BYYqgV1HQ@mail.gmail.com>
In-Reply-To: <201109261110.59940.trast@student.ethz.ch>

On Mon, Sep 26, 2011 at 5:10 AM, Thomas Rast <trast@student.ethz.ch> wrote:

Show 9 quoted lines

> Martin von Zweigbergk wrote:
>>
>> If I understand correctly, [rebase --root] was introduced to solve
>> exactly the same reason problem that made Francis start this thread
>> -- to avoid re-applying patches that are already in $onto.
>
> Not quite; I wrote it because at the time, there was no way to
> transplant git history onto a git-svn "make empty subdir" commit for
> later dcommitting.  So the main point was really

But that was only due to the bug/limitation in format-patch that you (?) fixed a few days later, no?

Show 5 quoted lines

> I still think it would be natural for a user to want a way to say "all
> the way back to the root commit".  At least for me the "full" rebase
> invocation is
>
>  git rebase --onto onto base branch

Sure, I can understand that. Still, it would just be an alternative syntax and nothing else. So I think I should also update the documentation after my other patches to make it clear that that is the case. We also have to think about backwards compatibility, so I'm obviously not suggesting that we should stop supporting the flag; I just wanted to make sure that it is not technically needed.

Show 14 quoted lines

>> I saw that
>> "--root" is also passed to the hook. Should that value be passed to
>> the hook also when the old base is not explicitly a root (by "rebase
>> --root"), but only implicitly so (by an $onto that is disjoint from
>> $branch)?
>
> I think I did it that way because if you use --root, the base/upstream
> argument is missing, and the hook needs to know that.
>
> If the user specifies an upstream that is disjoint from the branch
> itself, the hook gets the upstream argument and can presumably work it
> out from there.  So you could perhaps save the hook some trouble if
> you *know* that it's a disjoint rebase, but I wouldn't spend too much
> time on that.

The hook would still have to be able to handle both cases (i.e. getting the upstream argument as "--root" or simply a commit that happens to be disjoint from the the branch-to-be-rebased). I believe that has been the case since that bug in format-patch was fixed. So if we were to change git-rebase so it no longer passes the --root flag to the hook, I think any (correctly written) hooks should still work. I don't see much reason to change it, though; if the user uses the --root syntax, we can pass the flag, otherwise we don't.

Martin