On Mon, 3 Nov 2008, Santi Béjar wrote: > > I tried it once, but I had problems simplifying the merges, and it is trivial... It depends on the new --simplify-merges code which does that. > Not that it matters a lot, but if you try it on master you get some > extra merges without a ref like: > > 373a273 (Merge git-gui 0.11.0, 2008-08-17) Umm? Your point is? That merge itself doesn't have a ref, but it's required becase there are refs along both legs of the merge - one side has the "gitgui-0.11.0" tag, while the other has (for example) v16.0-rc3. > f44bc33 (Sync with 1.5.6.5, 2008-08-06) Again, the merge doesn't have a ref, but it's needed because there are refs on both parents (v1.5.6.5 vs v1.6.0-rc[01]). So no, --simplify-namespace in no way guarantees that all resulting commits will have refs pointing to them, because it also needs to return enough of the merges to make it a real and meaningful DAG. The one thing I note is that when you have lots and lots of refs in the gitk output, the gitk window itself becomes very ugly. I'd love to get rid of the black line between the ref (tag or branch name) and the circle, because with "gitk --simplify-namespace" it ends up looking like some kind of insane "ladder" due to all those vertical lines. And they really aren't necessary, and it would probably be better to just make selecting a commit highlight the whole row (and thus avoid any ambiguity between that highlighted commit message and the circle in the graph it goes with if you have a very wide graph). But I can't read tcl/tk enough to even figure out where it's being painted. Linus -- 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
