Re: [PATCH 2/2] version --build-options: report commit, too, if possible

[Johannes Schindelin]

Hi Junio,

On Fri, 8 Dec 2017, Junio C Hamano wrote:

> Jonathan Nieder  writes:
> 
> >> We need to be careful, though, to report when the current commit cannot be
> >> determined, e.g. when building from a tarball without any associated Git
> >> repository.
> >
> > This means that on Debian, it would always print
> >
> > built from commit: (unknown)
> >
> > Maybe I shouldn't care, but I wonder if there's a way to improve on
> > that. E.g. should there be a makefile knob to allow Debian to specify
> > what to put there?
> 
> Another "interesting" possibility is to build from a tarball
> extracted into a directory hierarchy that is controlled by an
> unrelated Git repository.  E.g. "my $HOME is under $HOME/.git
> repository, and then I have a tarball extract in $HOME/src/git".
> We shouldn't embed the HEAD commit of that $HOME directory project
> in the resulting executable in such a case.
> 
> We should be able to do this by being a bit more careful than the
> presented patch.  Make sure that the toplevel is at the same
> directory as we assumed to be (i.e. where we found that Makefile)
> and trust rev-parse output only when that is the case, or something
> like that.

Cute.

I added specific handling for that.

Ciao,
Dscho

Re: [PATCH 2/2] version --build-options: report commit, too, if possible

[Johannes Schindelin]

Hi Jonathan,

On Fri, 8 Dec 2017, Jonathan Nieder wrote:

> Johannes Schindelin wrote:
> 
> > In particular when local tags are used (or tags that are pushed to some
> > fork) to build Git, it is very hard to figure out from which particular
> > revision a particular Git executable was built.
> 
> Hm, can you say more about how this comes up in practice?

I recently saw a version string on this here list (in a generated patch)
that looked something like "git v2.14.0.chrome".

I sometimes build custom Git for Windows snapshots from commits that I
keep in my own fork. I would expect other people to do the same.

With this patch, at least I can verify very easily whether I have access
to the corresponding commit or not.

> I wonder if we should always augment the version string with the commit
> hash.

That would probably be more confusing than helpful to the end-users.

> E.g. I am running
> 
>   git version 2.15.1.424.g9478a66081

which is currently good enough, but in the future may clash with another
object, maybe even a commit. Unabbreviated commit names are what I am
after.

> > We need to be careful, though, to report when the current commit cannot be
> > determined, e.g. when building from a tarball without any associated Git
> > repository.
> 
> This means that on Debian, it would always print
> 
>   built from commit: (unknown)
> 
> Maybe I shouldn't care, but I wonder if there's a way to improve on
> that. E.g. should there be a makefile knob to allow Debian to specify
> what to put there?

I changed the text to "no commit associated with this build". Does that
suffice? If not, what "UI" would you suggest (most likely a new Makefile
variable? What name would you prefer?).

Ciao,
Dscho

Re: [PATCH 2/2] version --build-options: report commit, too, if possible

[Junio C Hamano]

Jonathan Nieder  writes:

>> We need to be careful, though, to report when the current commit cannot be
>> determined, e.g. when building from a tarball without any associated Git
>> repository.
>
> This means that on Debian, it would always print
>
>   built from commit: (unknown)
>
> Maybe I shouldn't care, but I wonder if there's a way to improve on
> that. E.g. should there be a makefile knob to allow Debian to specify
> what to put there?

Another "interesting" possibility is to build from a tarball
extracted into a directory hierarchy that is controlled by an
unrelated Git repository.  E.g. "my $HOME is under $HOME/.git
repository, and then I have a tarball extract in $HOME/src/git".
We shouldn't embed the HEAD commit of that $HOME directory project
in the resulting executable in such a case.

We should be able to do this by being a bit more careful than the
presented patch.  Make sure that the toplevel is at the same
directory as we assumed to be (i.e. where we found that Makefile)
and trust rev-parse output only when that is the case, or something
like that.

Re: [PATCH 2/2] version --build-options: report commit, too, if possible

[Jonathan Nieder]

Hi,

Johannes Schindelin wrote:

> In particular when local tags are used (or tags that are pushed to some
> fork) to build Git, it is very hard to figure out from which particular
> revision a particular Git executable was built.

Hm, can you say more about how this comes up in practice?  I wonder if
we should always augment the version string with the commit hash.
E.g. I am running

git version 2.15.1.424.g9478a66081

now, which already includes the commit hash because it disambiguates
the .424 thing, but depending on the motivation, maybe we would also
want

git version 2.15.1.0.g9b185bef0c15

for people running v2.15.1 (or at least when such a tag is not a well
known, published tag).

> We need to be careful, though, to report when the current commit cannot be
> determined, e.g. when building from a tarball without any associated Git
> repository.

This means that on Debian, it would always print

built from commit: (unknown)

Maybe I shouldn't care, but I wonder if there's a way to improve on
that. E.g. should there be a makefile knob to allow Debian to specify
what to put there?

Thanks,
Jonathan