From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 23 Dec 2009 18:11:57 GMT
Subject: Re: [PATCH RFC 4/4] rebase -i: add --refs option to rewrite heads within branch
Message-ID: <7vpr65r24y.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B31DA96.1050608@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Greg Price venit, vidit, dixit 23.12.2009 08:03:
> ...
>> Huh, that's an interesting idea.  I hadn't thought of that.  This
>> feature could be nice.  But I am not sure what it would look like.
>> How might the user indicate that they want both "side" and "topic" to
>> be rebased?  I suppose we could extend the familiar command line
>>    git rebase <upstream> [<branch>]
>> to the form
>>    git rebase <upstream> [...<branches>...]
>> so that your example would be
>>    $ git rebase -i --rewrite-heads master topic side
>> If we choose this approach, it might even be independent of
>> --rewrite-refs, though the implementation would presumably rely on the
>> "ref" command.  Was this interface what you were thinking, or do you
>> have another idea?
>
> If I may jump in: I imagine this to be the more common use case, i.e.:
> You have a part of the DAG which you want to rebase, with all kinds of
> refs (branches, tags) pointing to commits in that part of the DAG. If
> you rebase that part of the DAG you typically want some refs rewritten
> (such as the head of the branch you're rebasing) but maybe not others
> (say a release tag or branch). remote refs should never be rebased. So,
> one would need an easy way to specify one ref, all or anything in between...

And warn (or perhaps reject without --force) if the sub-DAG you would
rebase contains an already tagged commit, especially if you are treating
tags as immutable, even the ones you haven't published.

I actually don't think "rebasing side branches while rebasing this branch"
was such a good idea---we have filter-branch for that already ;-).