Re: Suggestion: make --left-right work with --merge

From: Paul Mackerras <paulus@samba.org>
Date: Feb 29, 2008, 10:52 UTC
Message-ID: <18375.58359.687664.855599@cargo.ozlabs.ibm.com>
In-Reply-To: <7vprugdxpj.fsf@gitster.siamese.dyndns.org>

Junio C Hamano writes:

Show 5 quoted lines

> Doesn't
> 
> 	git rev-parse --revs-only --no-flags "$@" | grep '^[0-9a-f]'
> 
> give you what you want?

Well, it does, except for --merge, which is perhaps a special case.

(Actually, what would git rev-parse --revs-only --no-flags output that isn't a SHA1 ID? Why do you have the grep command there?)

Also, --left-right with symmetric difference is an interesting case, because git rev-parse will turn a symmetric difference into three SHA1 IDs, with the 3rd one negated. If I pass what I get from git rev-parse to git log --left-right, then git log doesn't recognize that as a symmetric difference and shows all commits with the ">" marker.

Show 21 quoted lines

> Interesting.
> 
>  * gitk has already done what the user asked once.  E.g. "git
>    log next..master" to find out new trivially correct fixes
>    that are already applied to 'master' and will be brought to
>    'next' when I merge 'master' to 'next' next time;
> 
>  * The user does "git merge master" while on 'next', and tell
>    gitk to "Update".
> 
>  * gitk is expected to re-run "git log next..master" (textually
>    the same command line), but most part of the graph it already
>    knows about.  You need a way to omit what you already know,
>    so when you run the query for the first time you would want
>    to remember the actual object names, so that you use them to
>    tweak the query to "git log next..master --not <positive ones
>    in the first round>" for the second query.
> 
> In the above example, the set of commits actually will shrink
> ('next' moves and you will exclude more than before upon
> "Update").

"Update" adds new commits and moves the head/tag markers as necessary, but doesn't remove commits from the graph, because that's a bit hard. There is also a "Reload" function that restarts from scratch and so will not show the newly-removed commits (i.e., the same as "Update" does now in current gitk master), but it is a lot slower than "Update". In the common case (a few commits added), "Update" takes less than a second.

Show 6 quoted lines

> If you are only interested in cases that the only positive end
> grows (in the above example, the user adds commit to 'master'
> instead of merging it into 'next'), then grabbing only the
> positive ends (e.g. 'master' in 'next..master'), negate them and
> append them to the original query would speed things up, but
> obviously that would not work in the above example.

That's essentially what I do. I think I'll just have to do special cases for --merge and --left-right.

Paul.