git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: Tentative built-in "git show"
Date: Sat, 15 Apr 2006 13:57:14 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0604151345050.3701@g5.osdl.org> (raw)
In-Reply-To: <7v3bgefxkp.fsf@assigned-by-dhcp.cox.net>



On Sat, 15 Apr 2006, Junio C Hamano wrote:
> 
> I sometimes do "git show -4" myself, and wondered why defaulting
> to "-n 1"is insufficient

I detest -n1 for a variety of reasons, and giving multiple refs is just 
one of them.

The reason I like "--no-walk" is that it's conceptually much stronger, and 
more efficient. Remember how we tried to optimize "-1" (as used by gitweb) 
by adding magic special cases to get_revision()? And how they always ended
up being problematic because of how they interact with all the other 
options?

So we don't do it any more, and as a result, "git-rev-list -1 HEAD" will 
actually walk all the parents too.

In contrast, "--no-walk" just does exactly what you tell it: don't start 
walking the parents. It's kind of equivalent to -1 with one argument, but 
in the presense of path limiting it actually does the RightThing(tm), 
unlike -1.

Try this as a replacement for "git show":

	git log -1 kernel/
	git log --no-walk kernel/

on the current kernel source tree to see the difference. "--no-walk" gives 
the right answer (for some definition of "right"). While -1 gives a 
totally random answer that has nothing to do with the current HEAD (except 
that it's _reachable_ from the current HEAD).

So I think "-n 1" is fundamentally incompatible with "git show". Git 
"show" is "show _this_ commit". While "-1" fundamentally means "show the 
_first_ commit when you walk the tree". Which is really really 
fundamentally different.

In contrast "--no-walk" tells you exactly what it is about. Don't walk the 
tree. Show _this_ commit.

(Now, the reason I said 'for _some_ definition of "right"' is that the 
question about path limiting in the absense of commit walking is somewhat 
ambiguous. The current "git show" shows the commit regardless. My 
suggested patch will potentially prune the commit away, and if the 
specified commit does not touch the path, no commit is shown at all. 
Both make sense. While "git-rev-list -1" does _not_ make sense)

			Linus

      reply	other threads:[~2006-04-15 20:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-15 19:09 Tentative built-in "git show" Linus Torvalds
2006-04-15 19:28 ` Junio C Hamano
2006-04-15 20:57   ` Linus Torvalds [this message]

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=Pine.LNX.4.64.0604151345050.3701@g5.osdl.org \
    --to=torvalds@osdl.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /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).