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

Paul Mackerras [off-list ref] writes:

Junio C Hamano writes:

quoted

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.