Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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 ;-). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html