From: Junio C Hamano <gitster@pobox.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>, git@vger.kernel.org
Subject: Re: Suggestion: make --left-right work with --merge
Date: Fri, 29 Feb 2008 23:52:04 -0800 [thread overview]
Message-ID: <7vejau6fvf.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <18377.2084.30531.202087@cargo.ozlabs.ibm.com> (Paul Mackerras's message of "Sat, 1 Mar 2008 18:39:16 +1100")
Paul Mackerras <paulus@samba.org> writes:
> Junio C Hamano writes:
>
>> Try it on user inputs like "master..next", "next...master". You
>> wanted to grab only the positive ones, no?
>
> No... gitk passes the IDs it gets from git rev-parse (both positive
> and negative) to git log, rather than the original arguments.
I am not sure if I was answering the right question, then.
I thought the issue you were addressing was this.
(1) the user says "gitk master...next" to start you.
(2) you run "git log master...next" (or whatever the equivalent of what
the user gave you) and draw.
(3) the user does things outside your control to modify refs, and says
"Update".
(4) you could re-run "git log master...next" again, but that would show
mostly what you already know.
If you saved all the positive ones you used in (2), you could instead
run "git log master...next --not <positives in 2>" to ask only the
incremental changes (as long as the branches do not rewind, but you
do not discard nodes from the already drawn graph anyway).
<positives in 2> in this example sequence would be the object names
for master and next when (2) was run.
I think your "gitk passes the IDs" part is about the master...next part in
the above example. I do not think it really matters if they are converted
to object names or kept symbolic when given to "git log". I was talking
about the part you add after --not in the second round, and that was why
my answer was only about positive ones.
Come to think of it, when you are told to "Update", you already know the
positive tips you can use to optimize (4), don't you? They are the
commits you drew in (3) that do not have children.
next prev parent reply other threads:[~2008-03-01 7:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-27 2:49 Suggestion: make --left-right work with --merge Paul Mackerras
2008-02-27 7:18 ` Junio C Hamano
2008-02-27 22:36 ` Paul Mackerras
2008-02-27 22:50 ` Junio C Hamano
2008-02-28 11:21 ` Paul Mackerras
2008-02-29 7:32 ` Junio C Hamano
2008-02-29 10:52 ` Paul Mackerras
2008-02-29 19:26 ` Junio C Hamano
2008-03-01 7:39 ` Paul Mackerras
2008-03-01 7:52 ` Junio C Hamano [this message]
2008-03-01 10:59 ` Paul Mackerras
2008-02-29 21:05 ` Linus Torvalds
2008-02-29 7:49 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vejau6fvf.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=paulus@samba.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).