[PATCH 1/2] hard-code the empty tree object

[PATCH 1/2] hard-code the empty tree object

[Jeff King]

This maps sha1 4b825dc642cb6eb9a060e54bf8d69288fbee4904 to
the empty tree object, whether such an object exists in the
object database or not. The empty tree is useful for showing
some specialized diffs, especially for initial commits.

We also hard-code the special ref '{}' as an alias for the
empty tree. Users may refer to the empty tree by its
sha1 or by '{}'.

Thanks to Johannes Schindelin for the '{}' syntax and
implementation.

Signed-off-by: Jeff King <peff@peff.net>
---
This is a cleaned-up version of what's in pu, along with the magic ref
syntax from Johannes (2/2 will have the fixes to "git add -i").

 cache.h     |    5 +++++
 sha1_file.c |    9 +++++++++
 sha1_name.c |    5 +++++
 3 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/cache.h b/cache.h
index 3867ba7..e3abbe1 100644
--- a/cache.h
+++ b/cache.h
@@ -253,6 +253,11 @@ static inline enum object_type object_type(unsigned int mode)
 #define INFOATTRIBUTES_FILE "info/attributes"
 #define ATTRIBUTE_MACRO_PREFIX "[attr]"
 
+/* empty tree sha1: 4b825dc642cb6eb9a060e54bf8d69288fbee4904 */
+#define EMPTY_TREE_SHA1 \
+	"\x4b\x82\x5d\xc6\x42\xcb\x6e\xb9\xa0\x60" \
+	"\xe5\x4b\xf8\xd6\x92\x88\xfb\xee\x49\x04"
+
 extern int is_bare_repository_cfg;
 extern int is_bare_repository(void);
 extern int is_inside_git_dir(void);
diff --git a/sha1_file.c b/sha1_file.c
index 66a4e00..8068a4b 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1845,6 +1845,13 @@ static struct cached_object {
 } *cached_objects;
 static int cached_object_nr, cached_object_alloc;
 
+static struct cached_object empty_tree = {
+	EMPTY_TREE_SHA1,
+	OBJ_TREE,
+	"",
+	0
+};
+
 static struct cached_object *find_cached_object(const unsigned char *sha1)
 {
 	int i;
@@ -1854,6 +1861,8 @@ static struct cached_object *find_cached_object(const unsigned char *sha1)
 		if (!hashcmp(co->sha1, sha1))
 			return co;
 	}
+	if (!hashcmp(sha1, empty_tree.sha1))
+		return &empty_tree;
 	return NULL;
 }
 
diff --git a/sha1_name.c b/sha1_name.c
index be8489e..165aa7d 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -716,5 +716,10 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
 			return get_tree_entry(tree_sha1, cp+1, sha1,
 					      mode);
 	}
+	if (ret && !strcmp(name, "{}")) {
+		*mode = 0755;
+		hashcpy(sha1, (unsigned char *)EMPTY_TREE_SHA1);
+		ret = 0;
+	}
 	return ret;
 }
-- 
1.5.4.1.123.ge4e8d-dirty

Re: [PATCH 1/2] hard-code the empty tree object

[Johannes Schindelin]

Hi,

On Thu, 14 Feb 2008, Jeff King wrote:

> We also hard-code the special ref '{}' as an alias for the empty tree. 
> Users may refer to the empty tree by its sha1 or by '{}'.

Another idea just hit me: why not use "" (i.e. the empty string)?  It is 
not a valid ref name, and not a valid filename either...

But maybe that would be _too_ cute,
Dscho

Re: [PATCH 1/2] hard-code the empty tree object

[Jeff King]

On Thu, Feb 14, 2008 at 12:39:01PM +0000, Johannes Schindelin wrote:

> > We also hard-code the special ref '{}' as an alias for the empty tree. 
> > Users may refer to the empty tree by its sha1 or by '{}'.
> 
> Another idea just hit me: why not use "" (i.e. the empty string)?  It is 
> not a valid ref name, and not a valid filename either...
> 
> But maybe that would be _too_ cute,

IMHO, that is a bit too cute.

-Peff

Re: [PATCH 1/2] hard-code the empty tree object

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> We also hard-code the special ref '{}' as an alias for the
> empty tree. Users may refer to the empty tree by its
> sha1 or by '{}'.

I think the users of hard coded empty tree are oddballs.  Let's
not be too cute and instead leave it in the add -i patch.  {} is
already too cute.

Re: [PATCH 1/2] hard-code the empty tree object

[Jeff King]

On Fri, Feb 15, 2008 at 09:11:56AM -0800, Junio C Hamano wrote:

> > We also hard-code the special ref '{}' as an alias for the
> > empty tree. Users may refer to the empty tree by its
> > sha1 or by '{}'.
> 
> I think the users of hard coded empty tree are oddballs.  Let's
> not be too cute and instead leave it in the add -i patch.  {} is
> already too cute.

By "it" I assume you mean "the sha1 of the empty tree", meaning to not
include the {} bit at all?

I am fine with that, as I don't think anyone has even mentioned a
workflow where such a shorthand would be beneficial to users. The only
one I can think of is to represent some tree using diff tools (e.g., "git
diff --stat {} HEAD" instead of some variant on ls-files), but I have
never once actually wanted to do that.

Should I re-send, or do you want to just markup the existing patches?

-Peff

Re: [PATCH 1/2] hard-code the empty tree object

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> By "it" I assume you mean "the sha1 of the empty tree", meaning to not
> include the {} bit at all?

Yes, that's what I meant.

> I am fine with that, as I don't think anyone has even mentioned a
> workflow where such a shorthand would be beneficial to users. The only
> one I can think of is to represent some tree using diff tools (e.g., "git
> diff --stat {} HEAD" instead of some variant on ls-files), but I have
> never once actually wanted to do that.

Likewise.

> Should I re-send, or do you want to just markup the existing patches?

Shouldn't the previous one that uses the hardcoded empty tree
object name good enough that is already on 'pu'?

Re: [PATCH 1/2] hard-code the empty tree object

[Jeff King]

On Fri, Feb 15, 2008 at 09:42:26AM -0800, Junio C Hamano wrote:

> > Should I re-send, or do you want to just markup the existing patches?
> 
> Shouldn't the previous one that uses the hardcoded empty tree
> object name good enough that is already on 'pu'?

Yes, they are fine (I hadn't looked at them that carefully before, but
it looks like you cleaned up the ordering sensibly already).

The last paragraph in the commit message of the add--interactive patch
should be removed (the implementation is no longer "hack-ish").

-Peff