On Tue, Dec 22, 2009 at 6:37 PM, Junio C Hamano <gitster@xxxxxxxxx> 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 -- 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