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: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	git@vger.kernel.org
Subject: Re: [PATCH 2/3] merge-recursive: make empty tree a known object
Date: Sun, 10 Dec 2006 13:31:56 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0612101326420.12500@woody.osdl.org> (raw)
In-Reply-To: <7vpsar4fcu.fsf@assigned-by-dhcp.cox.net>



On Sun, 10 Dec 2006, Junio C Hamano wrote:
> 
> That is fine by me.  We would benefit from an empty blob and an
> empty tree.

I was wondering if we ever had any special case where we wanted the empty 
blob, and couldn't come up with any. Unlike the "tree diff" case, a "blob 
diff" will not actually do a "real diff" with a non-existing object, it 
special-cases it (and, for performance reasons, I think it really should). 

And all the blob-diff routines generally want to be able to take explicit 
data anyway, not just diffing two SHA1's (since we often don't have a SHA1 
anyway - the working tree case).

So while I think it would make sense to have both the "empty tree" and the 
"empty blob" as special cases, off-hand I can't actually see where we'd 
ever use the empty blob SHA1.

In contrast, the empty tree clearly ends up being an interesting special 
case that actually gets used occasionally, ie here we had two independent 
uses for the same thing..

But maybe somebody can point to a case where we actually would want to 
internally have an easy representation of "empty blob".


  reply	other threads:[~2006-12-10 21:32 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-07 10:17 [PATCH 1/1] Make sure the empty tree exists when needed in merge-recursive Shawn O. Pearce
2006-12-09 23:55 ` [PATCH 1/3] diff_tree_sha1(): avoid rereading trees if possible Johannes Schindelin
2006-12-10  1:47   ` Junio C Hamano
2006-12-10 22:49     ` Johannes Schindelin
2006-12-09 23:56 ` [PATCH 2/3] merge-recursive: make empty tree a known object Johannes Schindelin
2006-12-10 18:37   ` Linus Torvalds
2006-12-10 21:21     ` Junio C Hamano
2006-12-10 21:31       ` Linus Torvalds [this message]
2006-12-10 22:33         ` Junio C Hamano
2006-12-10 22:54           ` Linus Torvalds
2006-12-10 22:28       ` Junio C Hamano
2006-12-10 23:16         ` Johannes Schindelin
2006-12-09 23:56 ` [PATCH 3/3] add test case for recursive merge Johannes Schindelin
2006-12-10  0:18   ` Johannes Schindelin
2006-12-10  3:10     ` Junio C Hamano
2006-12-10 22:51       ` Johannes Schindelin
2006-12-12 22:49       ` [PATCH] t6024: fix timing problem Johannes Schindelin
2006-12-12 23:23         ` Junio C Hamano
2006-12-12 23:59           ` Johannes Schindelin
2006-12-13  3:05           ` [PATCH] merge-recursive: add/add really is modify/modify with an empty base Johannes Schindelin
2006-12-13  6:33             ` Junio C Hamano
2006-12-13 11:46               ` StGit repo & gitweb, was " Johannes Schindelin
2006-12-13 11:56                 ` Jakub Narebski
2006-12-13 22:09                 ` Catalin Marinas
2006-12-13 23:06                   ` Robin Rosenberg
2006-12-13 23:50                   ` Johannes Schindelin
2006-12-13 23:57                     ` Jakub Narebski
2006-12-19 18:50                 ` Petr Baudis
2006-12-19 19:39                   ` Jakub Narebski
2006-12-13 22:01               ` Catalin Marinas
2006-12-13 22:26                 ` Junio C Hamano
2006-12-13 23:48                 ` Johannes Schindelin
2006-12-14 11:31                   ` Catalin Marinas
2006-12-14 11:41                     ` Shawn Pearce
2006-12-14 12:00                     ` Shawn Pearce
2006-12-14 13:44                     ` Johannes Schindelin
2006-12-14 14:15                       ` Catalin Marinas

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.0612101326420.12500@woody.osdl.org \
    --to=torvalds@osdl.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=spearce@spearce.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).