Re: [PATCH RFC 4/4] rebase -i: add --refs option to rewrite heads within branch

[Greg Price <price@ksplice.com>]

On Tue, Dec 22, 2009 at 6:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
>  - As decoration is a fairly expensive operation (which is the reason why
>   loading_ref_decorations() is called lazily by format_decoration() in
>   the first place, especially in repositories with tons of refs), you
>   shouldn't give --format=%D to rev-list when the new feature is not
>   asked for.

OK, will do.


>  - This seems to rewrite only branch heads; don't you want to allow users
>   to rewrite lightweight tags and possibly annotated ones as well, by
>   perhaps giving "--rewrite-refs=refs/heads/" or "--rewrite-refs=refs/"
>   to limit what parts of the ref namespace to consider rewriting?

Sure.  I specifically left out tags because I generally think of a tag
as something immutable that it would not make sense to rewrite.  But
people use Git in different ways and it makes sense to give the option
of rewriting tags as well as heads.

I do worry that passing --rewrite-refs=refs/ will set up remote refs
for rewriting, which is likely to be confusing if the user does not
notice them and remove them from the TODO.  Perhaps it makes sense to
accept forms like "--rewrite-refs=refs/heads/,refs/tags/" or
"--rewrite-refs=refs/heads/ --rewrite-refs=refs/tags/".  Is there a
Git convention for accepting a sequence of arguments like this to an
option -- one of these, or something else?


> On the other hand, if the "partN" markers in your example workflow are
> primarily meant to be used to mark places on a branch (as opposed to
> arbitrary branch tips that independent development starting from them can
> further continue), it would make a lot more sense to use lightweight or
> annotated tags for them, and instead of "--refs" that rewrites only other
> branch tips, it might make a lot more sense to have "--rewrite-tags" that
> rewrites tags that point at the commits that are rewritten, without
> touching any branch tip.

I think of them as a topic branch developing one feature, then another
branch developing a related follow-on feature, etc.  I would also feel
odd rewriting tags as a routine operation, or calling a ref a tag when
I expect to rewrite it.  So I do think they're best recorded as branch
tips rather than tags.


> Obviously the series also needs tests.

Yes.


> I also have to wonder if this feature should also handle a case like this:
>
>                  side
>                  |
>                  V
>                  *
>                 /
>        part1   *    topic
>          |    /      |
>          v   /       v
>    A--*--*--*--*--*--*
>     \
>      B <--master
>
> ===>
>
>                     side
>                     |
>                     V
>                     *
>                    /
>           part1   *    topic
>     A       |    /      |
>      \      v   /       v
>       B--*--*--*--*--*--*
>       ^ [
>       |
>       master
>
> especially if it were to be specific to branch management.

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?

Greg