Paul Mackerras <paulus@xxxxxxxxx> writes:
> 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.
--
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
