Any way to get complete diff up to a tag?

[Peter Kjellerstedt]

If I use

$ git diff v1.7.1..

I get a diff for everything that has happened after the v1.7.1
release (up to HEAD). Is there a way to do the opposite, i.e.,
get everything (including the initial commit) up to and including
v1.7.1? I first tried  

$ git diff ..v1.7.1

but it gave me the reverse of the above, which I later found out
was due to it being the same as

$ git diff HEAD..v1.7.1

which of course does not yield the result I want.

If I use

$ git diff $(git rev-list --reverse v1.7.1 |head -1)..v1.7.1

I almost get what I want, but the initial commit is still missing.
Is there any way to get that initial commit included in the diff?

Basically, what I think I am asking for is a way to specify the
empty parent of the initial commit, i.e., where v1.7.1~1000000 would
end up. I can see this being useful in at least one other case as
well, namely when doing an interactive rebase to allow the initial
commit to be rebased (something I have wanted to do a couple of
times...)

//Peter

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bert Wesarg]

On Thu, May 6, 2010 at 11:27, Peter Kjellerstedt
<[hidden email]> wrote:
> I almost get what I want, but the initial commit is still missing.
> Is there any way to get that initial commit included in the diff?

git diff-tree -p 4b825dc642cb6eb9a060e54bf8d69288fbee4904 v1.7.1^{tree}

Bert
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Björn Steinbrink]

On 2010.05.06 11:27:40 +0200, Peter Kjellerstedt wrote:
> If I use
>
> $ git diff $(git rev-list --reverse v1.7.1 |head -1)..v1.7.1
>
> I almost get what I want, but the initial commit is still missing.
> Is there any way to get that initial commit included in the diff?

git internally knows about the empty tree, so you can use:
git diff 4b825dc642cb6eb9a060e54bf8d69288fbee4904 v1.7.1

Björn
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Peter Kjellerstedt]

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Björn Steinbrink
> Sent: den 6 maj 2010 11:42
> To: Peter Kjellerstedt
> Cc: [hidden email]
> Subject: Re: Any way to get complete diff up to a tag?
>
> On 2010.05.06 11:27:40 +0200, Peter Kjellerstedt wrote:
> > If I use
> >
> > $ git diff $(git rev-list --reverse v1.7.1 |head -1)..v1.7.1
> >
> > I almost get what I want, but the initial commit is still missing.
> > Is there any way to get that initial commit included in the diff?
>
> git internally knows about the empty tree, so you can use:
> git diff 4b825dc642cb6eb9a060e54bf8d69288fbee4904 v1.7.1
>
> Björn

Thank you, that was useful. However, I need to be able to do this
for an arbitrary repository, and that SHA seems to be specific for
the git repository. How do I get the SHA for the empty tree in an
arbitrary repository?

//Peter

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Santi Béjar-2]

2010/5/6 Peter Kjellerstedt <[hidden email]>:

>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of Björn Steinbrink
>>
>> On 2010.05.06 11:27:40 +0200, Peter Kjellerstedt wrote:
>> > If I use
>> >
>> > $ git diff $(git rev-list --reverse v1.7.1 |head -1)..v1.7.1
>> >
>> > I almost get what I want, but the initial commit is still missing.
>> > Is there any way to get that initial commit included in the diff?
>>
>> git internally knows about the empty tree, so you can use:
>> git diff 4b825dc642cb6eb9a060e54bf8d69288fbee4904 v1.7.1
>>
>> Björn
>
> Thank you, that was useful. However, I need to be able to do this
> for an arbitrary repository, and that SHA seems to be specific for
> the git repository. How do I get the SHA for the empty tree in an
> arbitrary repository?

It is not specific for the git repository, there is only one SHA1 for
the empty tree. But it is hard-coded in git itself since 1.5.5. If you
use an older git you have to create it yourself.

Santi
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Johannes Sixt-2]

Am 5/6/2010 13:20, schrieb Peter Kjellerstedt:

> Björn Steinbrink
>> git internally knows about the empty tree, so you can use:
>> git diff 4b825dc642cb6eb9a060e54bf8d69288fbee4904 v1.7.1
>>
>> Björn
>
> Thank you, that was useful. However, I need to be able to do this
> for an arbitrary repository, and that SHA seems to be specific for
> the git repository. How do I get the SHA for the empty tree in an
> arbitrary repository?

Aha, so you think Björn et.al. were able to guess the SHA1 for your
specific repository? ;)

No, the empty tree is the empty tree, and its name is as cited above, no
matter where in the universe you are.

-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Peter Kjellerstedt]

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Johannes Sixt
> Sent: den 6 maj 2010 15:04
> To: Peter Kjellerstedt
> Cc: Björn Steinbrink; [hidden email]
> Subject: Re: Any way to get complete diff up to a tag?
>
> Am 5/6/2010 13:20, schrieb Peter Kjellerstedt:
> > Björn Steinbrink
> >> git internally knows about the empty tree, so you can use:
> >> git diff 4b825dc642cb6eb9a060e54bf8d69288fbee4904 v1.7.1
> >>
> >> Björn
> >
> > Thank you, that was useful. However, I need to be able to do this
> > for an arbitrary repository, and that SHA seems to be specific for
> > the git repository. How do I get the SHA for the empty tree in an
> > arbitrary repository?
>
> Aha, so you think Björn et.al. were able to guess the SHA1 for your
> specific repository? ;)

No, not really, but I could not understand why it worked when I
tested it in my clone of git itself, but not in another git repository.

> No, the empty tree is the empty tree, and its name is as cited above,
> no matter where in the universe you are.
>
> -- Hannes

Well, I figured out my mistake. I had abbreviated the SHA1 since I
typed it in manually, and it worked fine in git's own repository,
but not in another repository. But when I used the full SHA1 it
worked in both. So I guess the empty dir SHA1 hardcoded in git just
happened to be the SHA1 for the empty dir in git's own repository...

Since the 4b825dc642cb6eb9a060e54bf8d69288fbee4904 SHA1 is somewhat
cumbersome to remember, wouldn't it be an idea to give it some kind
of alias or mnemonic? E.g., something like @~ (or some other mix of
odd characters which do not clash with all the other similar
constructs already used for references).

Anyway, thanks all for the help.
//Peter

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Björn Steinbrink]

On 2010.05.06 17:09:57 +0200, Peter Kjellerstedt wrote:
>
> Well, I figured out my mistake. I had abbreviated the SHA1 since I
> typed it in manually, and it worked fine in git's own repository,
> but not in another repository. But when I used the full SHA1 it
> worked in both. So I guess the empty dir SHA1 hardcoded in git just
> happened to be the SHA1 for the empty dir in git's own repository...

No, there can be only one SHA1 for the empty tree. It's the SHA1 hash of
the object, and the empty tree is the empty tree, always.

git.git just happens to actually contain that object, so the abbreviated
hash works, because git can find the object and doesn't actually need
the hardcoded built-in empty tree (which is only used when the full hash
is given).

Björn
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Knittl]

On Thu, May 6, 2010 at 11:27 AM, Peter Kjellerstedt
<[hidden email]> wrote:
> Basically, what I think I am asking for is a way to specify the
> empty parent of the initial commit, i.e., where v1.7.1~1000000 would
> end up. I can see this being useful in at least one other case as
> well, namely when doing an interactive rebase to allow the initial
> commit to be rebased (something I have wanted to do a couple of
> times...)


wait, let me get this straight. you want to diff some tag against the
empty parent of the root commit (empty tree)?

which in turn means you will get a diff, where all lines in all files
existing in the tree that tag references are added. all files get
basically prefixed with + and have header information (filename). what
purpose has such a diff?

regards, daniel

--
typed with http://neo-layout.org
myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Linus Torvalds-3]

On Thu, 6 May 2010, Peter Kjellerstedt wrote:
>
> Since the 4b825dc642cb6eb9a060e54bf8d69288fbee4904 SHA1 is somewhat
> cumbersome to remember, wouldn't it be an idea to give it some kind
> of alias or mnemonic? E.g., something like @~ (or some other mix of
> odd characters which do not clash with all the other similar
> constructs already used for references).

Well, you don't strictly speaking have to "remember" it, you can always
just re-generate it. The most straightforward way to do that is probably

        git hash-object -t tree --stdin < /dev/null

although I admit that maybe we could have some syntax for "git diff" that
would do the "diff against empty tree" automatically. It does seem to be
conceptually a reasonable thing to do.

For example, right now if you give "git diff" a single SHA1, it will work
against the working tree. Except if you add "--cached", to say that you
want the diff against the index. I don't think it would be in any way
_wrong_ to make "--root" mean that you want it against an empty tree.

[ We already accept "--root", but it has no meaning for "git diff" with a
  single SHA1. It matters for showing the root commit for 'git-diff-tree'.

  And means something totally different for git-format-patch ]

So we certainly _could_ do something like

        git diff --root <treeish>

and make it do what you want. That said, the "empty tree" thing works for
all versions of git (well, some older versions of git need the actual
object, but you could always use "-w" on that git-hash-object command
line, and then it really should work for every git version).

                        Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Greg Troxel]

Linus Torvalds <[hidden email]> writes:

> Well, you don't strictly speaking have to "remember" it, you can always
> just re-generate it. The most straightforward way to do that is probably
>
> git hash-object -t tree --stdin < /dev/null
>
> although I admit that maybe we could have some syntax for "git diff" that
> would do the "diff against empty tree" automatically. It does seem to be
> conceptually a reasonable thing to do.

How about

  git diff empty..

as if empty is a tag for the empty revision?  It works for 'git
checkout' already.

[Peter Kjellerstedt]

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Knittl
> Sent: den 6 maj 2010 17:44
> To: Peter Kjellerstedt
> Cc: [hidden email]
> Subject: Re: Any way to get complete diff up to a tag?
>
> On Thu, May 6, 2010 at 11:27 AM, Peter Kjellerstedt
> <[hidden email]> wrote:
> > Basically, what I think I am asking for is a way to specify the
> > empty parent of the initial commit, i.e., where v1.7.1~1000000 would
> > end up. I can see this being useful in at least one other case as
> > well, namely when doing an interactive rebase to allow the initial
> > commit to be rebased (something I have wanted to do a couple of
> > times...)
>
> wait, let me get this straight. you want to diff some tag against the
> empty parent of the root commit (empty tree)?
>
> which in turn means you will get a diff, where all lines in all files
> existing in the tree that tag references are added. all files get
> basically prefixed with + and have header information (filename). what
> purpose has such a diff?
>
> regards, daniel

Well, I can see a couple of purposes, but in my case I have a tool
post-processing the generated diff. And to it there is no difference
regarding what point was used as the start of the diff, whether it
was the empty tree (i.e., a diff containing everything), some commit
in the middle, or the last commit (i.e., an emptry diff). All it
wants is a diff.

//Peter
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Peter Kjellerstedt]

> -----Original Message-----

> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Linus Torvalds
> Sent: den 6 maj 2010 19:09
> To: Peter Kjellerstedt
> Cc: Johannes Sixt; [hidden email]; Björn Steinbrink
> Subject: RE: Any way to get complete diff up to a tag?
>
> On Thu, 6 May 2010, Peter Kjellerstedt wrote:
> >
> > Since the 4b825dc642cb6eb9a060e54bf8d69288fbee4904 SHA1 is somewhat
> > cumbersome to remember, wouldn't it be an idea to give it some kind
> > of alias or mnemonic? E.g., something like @~ (or some other mix of
> > odd characters which do not clash with all the other similar
> > constructs already used for references).
>
> Well, you don't strictly speaking have to "remember" it, you can always
> just re-generate it. The most straightforward way to do that is
> probably
>
> git hash-object -t tree --stdin < /dev/null

Thank you, that is good to know.

> although I admit that maybe we could have some syntax for "git diff"
> that would do the "diff against empty tree" automatically. It does
> seem to be conceptually a reasonable thing to do.
>
> For example, right now if you give "git diff" a single SHA1, it will
> work against the working tree. Except if you add "--cached", to say
> that you want the diff against the index. I don't think it would be in
> any way _wrong_ to make "--root" mean that you want it against an
> empty tree.
>
> [ We already accept "--root", but it has no meaning for "git diff"
>   with a single SHA1. It matters for showing the root commit for
>   'git-diff-tree'.
>
>   And means something totally different for git-format-patch ]
>
> So we certainly _could_ do something like
>
> git diff --root <treeish>

I went ahead and implemented support for --root as an option to git
diff (patch attached for reference). However, I then realized that
there are probably more commands that would benefit from the same
support, e.g., git diff-index. Then I thought about git diff-tree
and realized that it could also benefit from my version of --root,
but as you mentioned above, it already has a --root option with
a different semantic... I also figured it would be a hassle for me
to find all commands who can use a --root option, not knowing the
internals of git well enough yet.

So I then went back to my original idea of making an alias for the
empty tree, and came up with a two line patch which I will send as
a separate patch, and see what you guys think of the idea.

> and make it do what you want. That said, the "empty tree" thing works
> for all versions of git (well, some older versions of git need the
> actual object, but you could always use "-w" on that git-hash-object
> command line, and then it really should work for every git version).
>
> Linus

//Peter