Greg Price venit, vidit, dixit 23.12.2009 08:03: > 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 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... Michael -- 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