threads / patch / 12101

patch, 2 partshard-code the empty tree object

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

## tl;dr

7 messages between Feb 14, 2008 and Feb 15, 2008. Diffs are folded; open one to read it.

replies: 6people: 3as markdown or json

Jeff King· Feb 14, 2008, 10:32 UTC · lore

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(-)
Show changes to 3 files +19 −0

cache.h, sha1_file.c, sha1_name.c

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
Johannes Schindelin· Feb 14, 2008, 12:39 UTC · re: Jeff King · lore

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

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

Jeff King· Feb 14, 2008, 14:03 UTC · re: Johannes Schindelin · lore

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

On Thu, Feb 14, 2008 at 12:39:01PM +0000, Johannes Schindelin wrote:
Show 7 quoted lines
> > 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
Junio C Hamano· Feb 15, 2008, 17:11 UTC · re: Jeff King · lore

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

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.

Jeff King· Feb 15, 2008, 17:20 UTC · re: Junio C Hamano · lore

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

On Fri, Feb 15, 2008 at 09:11:56AM -0800, Junio C Hamano wrote:
Show 7 quoted lines
> > 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
Junio C Hamano· Feb 15, 2008, 17:42 UTC · re: Jeff King · lore

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

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.
Show 5 quoted lines
> 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'?

Jeff King· Feb 15, 2008, 18:25 UTC · re: Junio C Hamano · lore

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

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

← back to recent threads