sudo: git describe during GIT_VERSION_GEN not as expected..

sudo: git describe during GIT_VERSION_GEN not as expected..

[Philip Oakley]

Hi,

I have run into a problem with make/install of git on my old travel 
laptop. While trying to make / install git with some patches on top of 
yesterdays next (coincidental timing) I'm finding that the generated git 
version is the default value rather than that of a regular 'get 
describe' as used in GIT_VERSION_GEN.

Commit tree state:
~/repos/git (die_preserve_2)$ git log -4 --oneline --decorate
dd96dd88c3 (HEAD -> die_preserve_2) rebase: note `preserve` merges may 
be a pull config option
53d93c1c94 rebase: help users when dying with `preserve-merges`
65721c069b rebase.c: state preserve-merges has been removed
7e84679e2a (junio/next, gitster/next, gitgitgadget/next, git/next) Merge 
branch 'cb/ci-make-p4-optional' into next

After a make/install of the above I'm getting a version string is the 
default, rather than referencing the current hash as below. I've already 
tried setting the safe.directory as advised. The second describe 
invocation is from GIT_VERSION_GEN. Note how it fails to provide the 
expected output.

~/repos/git (die_preserve_2)$ git version
git version 2.36.GIT
~/repos/git (die_preserve_2)$ git describe --match "v[0-9]*" HEAD
v2.36.1-165-gdd96dd88c3
~/repos/git (die_preserve_2)$ sudo git describe --match "v[0-9]*" HEAD
fatal: unsafe repository ('/home/philip/repos/git' is owned by someone else)
To add an exception for this directory, call:

     git config --global --add safe.directory /home/philip/repos/git
~/repos/git (die_preserve_2)$ git config --global --get safe.directory


Is this a temporary position, as the sudo safe.directory problem is 
still to be added to next? Or is it a secondary side effect of the 
install method as per [1,2]?

Philip

[1] 
https://www.digitalocean.com/community/tutorials/how-to-install-git-from-source-on-ubuntu-20-04-quickstart 

     see `sudo make prefix=/usr/local install`
[2] 
https://www.digitalocean.com/community/tutorials/how-to-install-git-on-ubuntu-20-04

Re: sudo: git describe during GIT_VERSION_GEN not as expected..

[Philip Oakley]

couple corrections.

On 15/05/2022 11:12, Philip Oakley wrote:
> Hi,
>
> I have run into a problem with make/install of git on my old travel 
> laptop. While trying to make / install git with some patches on top of 
> yesterdays next (coincidental timing) I'm finding that the generated 
> git version is the default value rather than that of a regular 'get 
> describe' as used in GIT_VERSION_GEN.
>
> Commit tree state:
> ~/repos/git (die_preserve_2)$ git log -4 --oneline --decorate
> dd96dd88c3 (HEAD -> die_preserve_2) rebase: note `preserve` merges may 
> be a pull config option
> 53d93c1c94 rebase: help users when dying with `preserve-merges`
> 65721c069b rebase.c: state preserve-merges has been removed
> 7e84679e2a (junio/next, gitster/next, gitgitgadget/next, git/next) 
> Merge branch 'cb/ci-make-p4-optional' into next
>
> After a make/install of the above I'm getting a version string is the 
> default, rather than referencing the current hash as below. I've 
> already tried setting the safe.directory as advised. The second 
> describe invocation is from GIT_VERSION_GEN
which, in this case, is invoked by the sudo in the `make install`
> . Note how it fails to provide the expected output.
>
> ~/repos/git (die_preserve_2)$ git version
> git version 2.36.GIT
> ~/repos/git (die_preserve_2)$ git describe --match "v[0-9]*" HEAD
> v2.36.1-165-gdd96dd88c3
> ~/repos/git (die_preserve_2)$ sudo git describe --match "v[0-9]*" HEAD
> fatal: unsafe repository ('/home/philip/repos/git' is owned by someone 
> else)
> To add an exception for this directory, call:
>
>     git config --global --add safe.directory /home/philip/repos/git
> ~/repos/git (die_preserve_2)$ git config --global --get safe.directory

Bad cut & paste. The response was:
/home/philip/repos/git

>
>
> Is this a temporary position, as the sudo safe.directory problem is 
> still to be added to next? Or is it a secondary side effect of the 
> install method as per [1,2]?
>
> Philip
>
> [1] 
> https://www.digitalocean.com/community/tutorials/how-to-install-git-from-source-on-ubuntu-20-04-quickstart 
>
>     see `sudo make prefix=/usr/local install`
> [2] 
> https://www.digitalocean.com/community/tutorials/how-to-install-git-on-ubuntu-20-04
>

Re: sudo: git describe during GIT_VERSION_GEN not as expected..

[Carlo Arenas]

On Sun, May 15, 2022 at 3:12 AM Philip Oakley <philipoakley@iee.email> wrote:
> Is this a temporary position, as the sudo safe.directory problem is
> still to be added to next?

yes, it should be fixed once/if that branch graduates to next, and it
is currently broken in master and all maint branches as well as the
last 2 releases from those.

Carlo

Re: sudo: git describe during GIT_VERSION_GEN not as expected..

[Philip Oakley]

Hi Carlo

On 15/05/2022 12:05, Carlo Arenas wrote:
> On Sun, May 15, 2022 at 3:12 AM Philip Oakley <philipoakley@iee.email> wrote:
>> Is this a temporary position, as the sudo safe.directory problem is
>> still to be added to next?
> yes, it should be fixed once/if that branch graduates to next, and it
> is currently broken in master and all maint branches as well as the
> last 2 releases from those.
>
> Carlo
Thanks for clarifying. Wasn't sure if it was finger trouble on my side.
P.

Re: sudo: git describe during GIT_VERSION_GEN not as expected..

[Junio C Hamano]

Philip Oakley <philipoakley@iee.email> writes:

> I have run into a problem with make/install of git on my old travel
> laptop. While trying to make / install git with some patches on top of 
> yesterdays next (coincidental timing) I'm finding that the generated
> git version is the default value rather than that of a regular 'get 
> describe' as used in GIT_VERSION_GEN.

Yup, we've been discussing on this issue since the Git 2.35.3 (and
friends) and Git 2.36 release.

  https://lore.kernel.org/git/20220426183105.99779-1-carenas@gmail.com/

I think the last round:

  https://lore.kernel.org/git/20220513010020.55361-1-carenas@gmail.com/

is more or less done, so perhaps we should start merging it down to
'next' and all the way down to the older maintenance tracks like
maint-2.30 that are affected.

Thanks.