tag subcommand complains that the working tree is dirty when it isn't

[Robie Basak]

Bryce had this error:

triage-hirsute+21.04:~/pkg/Apache2/merge-v2.4.46-4/apache2-gu-test$ git ubuntu tag --upload
03/04/2021 22:20:20 - ERROR:Working tree must be clean to continue.
triage-hirsute+21.04:~/pkg/Apache2/merge-v2.4.46-4/apache2-gu-test$ git status
On branch merge-v2.4.46-4-hirsute
Your branch is up to date with 'bryce/merge-v2.4.46-4-hirsute'.

nothing to commit, working tree clean

I remember other people mentioning this issue too.

[Robie Basak (racb)]

I'm not sure we've ever had exact steps to reproduce this problem, though multiple have mentioned it so it's definitely an issue. If someone finds reproduction steps, I'd appreciate that.

[Bryce Harrington (bryce)]

I've pushed an apache2 merge to diglett that currently reproduces this error.

bryce@diglett:~/apache2-gu$ git ubuntu tag --upload --verbose
03/08/2021 19:23:04 - DEBUG:Executing: git config gitubuntu.lpuser
gitubuntu.lpuser is not set. What is your Launchpad username? We will set this in your personally global git configuration for you. To abort, press Enter.
Username: bryce
03/08/2021 19:23:09 - WARNING:Setting the Launchpad user for git-ubuntu to bryce with `git config --global gitubuntu.lpuser bryce`.
03/08/2021 19:23:09 - DEBUG:Executing: git config --global gitubuntu.lpuser bryce
03/08/2021 19:23:10 - ERROR:Working tree must be clean to continue.
bryce@diglett:~/apache2-gu$ git diff
bryce@diglett:~/apache2-gu$ git status
On branch merge-v2.4.46-4-hirsute
Your branch is up to date with 'bryce/merge-v2.4.46-4-hirsute'.

nothing to commit, working tree clean

Notably, I've run the 'empty directories' workaround script on this. I do not know if that has caused the above, or if this is an existing problem with apache that the empty directory trouble just hid until now.

Fwiw, my first instinct was to just add a --force to the command line, then when that didn't work, look at --help to see if there was force-like option. So FWIW either of those would have WFM as a workaround.

[Bryce Harrington (bryce)]

(Sorry, the LP username stuff is unrelated to the issue, that's just because I hadn't run git ubuntu on diglett before.)

[Christian Ehrhardt  (paelzer)]

For `gut ubuntu tag --logical` (but not split, deconstruct, upload) this issue has hit me I think every time I tried to use it.
To illustrate that the tagging is affected by various things here a few more testcases for your branch to solve this.

$ git ubuntu clone strongswan
...
$ cd strongswan/
$ git ubuntu tag --logical
03/09/2021 08:30:44 - ERROR:HEAD is not a defined object in this git repository.
$ git ubuntu tag --split
03/09/2021 08:30:51 - ERROR:Working tree must be clean to continue.

IMHO both make no sense, just tag it please :-)

But then - for comparison - the behavior differs per repo

$ git ubuntu clone hello
$ cd hello/
$ git ubuntu tag --logical
03/09/2021 08:34:15 - ERROR:HEAD is not a defined object in this git repository.
$ git ubuntu tag --split

^^ here split worked, but logical did not.

If you use those two together with Bryce use case of above and the new branch works fine for all three we should be more on the safe side (in case more than one underlying issue is hidden here).

[Robie Basak (racb)]

I looked at Bryce's reproducer. If I run the check that the tag subcommand is doing but using pygit2 from python3-pygit2 on diglett, it succeeds. If I run the check with the pygit2 from the git-ubuntu snap (using snap run --shell git-ubuntu and then the python3 REPL in there), it fails. pygit2 lists many files as GIT_STATUS_INDEX_NEW.

I therefore suspect that this is a bug in pygit2 that has since been fixed. I will have a test snap built against core20 with a newer pygit2 soon, so let's see if the problem reproduces there.

Christian, I think "ERROR:HEAD is not a defined object in this git repository" is a separate issue. Please could you file a separate bug with a reproducer in there? Like Bryce did here, it might be easiest for you to give me a copy of an affected git repository checkout, rather than full steps to reproduce.

[Robie Basak (racb)]

I just remembered that we discussed not checking for a clean working tree at all, or adding a --force option. Let's see where we are with a newer pygit2 and then we can decide on the best solution.

[Nish Aravamudan (nacc)]

I do recall seeing this weird pygit2 issue. At the time I didnt have cycles to debug and I think we decided that a pygit2 bump would fix it, but that without more tests we weren't sure that it wouldnt break hash stability in some subtle way.