Can't diff against the 00000000 revision

Can't diff against the 00000000 revision

[Stefan Monnier]

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

Re: Can't diff against the 00000000 revision

[Jeff King]

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

> 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>...]'
>     %

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

> 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.

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).

> 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.

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

Re: Can't diff against the 00000000 revision

[Jeff King]

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

> > 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.
> 
> The empty tree also has a name:
> 
>   $ git hash-object -t tree /dev/null
>   4b825dc642cb6eb9a060e54bf8d69288fbee4904

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

Re: Can't diff against the 00000000 revision

[Stefan Monnier]

>> 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.

> The empty tree also has a name:
>
>   $ git hash-object -t tree /dev/null
>   4b825dc642cb6eb9a060e54bf8d69288fbee4904

Yay!

   git diff 4b825dc642cb6eb9a060e54bf8d69288fbee4904..d59cfff346c3e210adc26501f8cebf8da5ab2e7d

seems to give me the expected diff.
Thanks!

> 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?

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

Re: Can't diff against the 00000000 revision

[Andreas Schwab]

Jeff King <peff@peff.net> writes:

> 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?

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.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Can't diff against the 00000000 revision

[Jeff King]

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

> > 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?
> 
> 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".

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

Re: Can't diff against the 00000000 revision

[Jeff King]

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

> Jeff King <peff@peff.net> writes:
> 
> > 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?
> 
> 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.

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

Re: Can't diff against the 00000000 revision

[Junio C Hamano]

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

>> 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?
>
> 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".

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.