Can't diff against the 00000000 revision

If I look at the initial commit on a branch, I see something like:

    % git show d59cfff346c3e210adc26501f8cebf8da5ab2e7d
    commit d59cfff346c3e210adc26501f8cebf8da5ab2e7d
    Author: Stefan Monnier <monnier@iro.umontreal.ca>
    Date:   Wed Dec 2 20:46:51 2015 -0500
    
        Initial release
    
    diff --git a/bugit b/bugit
    new file mode 100755
    index 0000000..681bd38
    --- /dev/null
    +++ b/bugit
    @@ -0,0 +1,512 @@
    ...

which is great.  But I can't get the same result with

    git diff 0000000..681bd38

because it complains:

    % git diff 0000000..681bd38
    fatal: ambiguous argument '0000000..681bd38': unknown revision or path not in the working tree.
    Use '--' to separate paths from revisions, like this:
    'git <command> [<revision>...] -- [<file>...]'
    %

I bumped into this problem in a post-receive hook where I need to pay attention to all newly added files, and where this problem means that I can't use the same code for a newly added branch as for a push on a pre-existing branch.

I currently work around the problem by adding a dummy empty branch, but being able to use the revision 00000000 as a known reference to an empty tree would come in really handy, and since it's already used at various places in Git (post-receive hook and "git show" output, at least), it would seem like a natural extension.

        Stefan

On Tue, Jan 12, 2016 at 10:17:24AM -0500, Stefan Monnier wrote:

Right. There is no "000000" blob; it's just a syntactic placeholder.

If you want to diff against the empty blob, you can. Its name is:

  $ git hash-object -t blob /dev/null
  e69de29bb2d1d6434b8b29ae775ad8c2e48c5391

Keep in mind that the "000000" in your example is showing the change in the _blob_, not the change in revisions. Even if it were not 0's, you could not run "git diff A..B" on it, because that syntax only works with commits.

So the corner case you need to deal with is not about a newly added branch; it is about a newly added file (or in the opposite direction, a deleted file).

Or from your description, maybe you are also running into the all-zero sha1 in the argument to the post-receive hook (where it is standing in for a commit sha1 on a newly-pushed branch).

The empty tree also has a name:

  $ git hash-object -t tree /dev/null
  4b825dc642cb6eb9a060e54bf8d69288fbee4904

and you can diff against that.

And hopefully that explains why "000000" does not necessarily make a good placeholder for "the empty thing". There are multiple empty things, and it is not clear what:

  git diff 0000000 1234abcd

means. Is 0000000 a tree? A blob?

-Peff

On Tue, Jan 12, 2016 at 10:32:39AM -0500, Jeff King wrote:

By the way, the empty tree and empty blob objects are baked-in to git, so you can always rely on diffing against them. IOW, it is fine to write:

  while read old new ref; do
	if test "$old" = "0000000000000000000000000000000000000000"; then
		old=4b825dc642cb6eb9a060e54bf8d69288fbee4904
	fi
	git diff-tree $old $new | whatever_checks_you_want_to_do
  done

in your post-receive hook.

-Peff

Yay!

   git diff 4b825dc642cb6eb9a060e54bf8d69288fbee4904..d59cfff346c3e210adc26501f8cebf8da5ab2e7d

seems to give me the expected diff. Thanks!

Well, Git is the one who uses 000000 to refer to an empty thing, but indeed it seems like it does inconsistently: it's sometimes used as the "empty blob" and sometimes as an "empty tree".

        Stefan

On Tue, Jan 12, 2016 at 11:26:24AM -0500, Stefan Monnier wrote:

Yes. You can think of it kind of like a NULL pointer; it just means "nothing". So its meaning is context-dependent. The problem is if we expect to feed it back to git in a place where the context isn't obvious.

-Peff

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Git does not use 0*40 to refer to "an empty thing" at all. It is used to denote a "missing thing". A change to _create_ a new file and a diff to _modify_ an existing empty file are conceptually two different things, and are shown differently.

It would be incorrect to say "it used to be an empty blob" by using e69de29bb2d1d on the left hand side of a patch that creates a new file.

Jeff King <peff@peff.net> writes:

Perhaps there should be an easy syntax for an empty thing, something like 0^{tree} and 0^{blob}. Not sure whether it is worth the effort, though.

Andreas.

On Tue, Jan 12, 2016 at 07:11:14PM +0100, Andreas Schwab wrote:

I think I proposed a magic EMPTY_TREE token or something like that at one point. It is slightly more convenient than trying to remember the exact tree sha1, but I think in practice it doesn't save much effort (outside of scripts, you can often use "--root" to accomplish the same thing, depending on the command being run).

-Peff