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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 29, 2008, 07:32 UTC
Message-ID: <7vprugdxpj.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <18374.39253.408961.634788@cargo.ozlabs.ibm.com>

Paul Mackerras <paulus@samba.org> writes:

Show 11 quoted lines

> Junio C Hamano writes:
>
>> Yeah, the option list is not maintained well for the last few
>> years and needs to be updated.
>
> Ah.  OK.  I am currently using git rev-parse in the gitk dev branch to
> determine what starting commits git log will use, so that when the
> user does an update, I can construct a git log command that will stop
> when it gets to any of those previous starting points.  That way the
> second git log will only give me new stuff that has been added since
> the first git log.

Doesn't

	git rev-parse --revs-only --no-flags "$@" | grep '^[0-9a-f]'

give you what you want?

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").

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.