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

Michael J Gruber [off-list ref] writes:

Greg Price venit, vidit, dixit 23.12.2009 08:03:
...

quoted

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 ;-).