On Thu, Apr 28, 2022 at 02:07:56PM -0700, Junio C Hamano wrote:
> Carlo Arenas <carenas@xxxxxxxxx> writes:
>
> >> Overall, I like the simplicity and clarity of "do not start this
> >> test as 'root'" in the previous round much better.
> >
> > I disagree, and think that the fact that the second test changes
> > behavior with this series proves my point.
>
> I do not know which second test you are talking about, but anyway.
My bad; by "second test" I was referring to the one that I introduced to
track the regression and its fix and which has its behavior changed, but
you would only notice if looking at it from all angles (and yes, that
includes as a regular user, as well as root, with and without sudo :
If we do :
[0] login as regular user || sudo to root || login as root
[1] % mkdir -p root/r
[2] % git init root/r
[3] % cd root/r && git status
we get
step \ type | regular user | sudo to root | root
--------------------------------------------------
1 | work | work | work
before 2 | work | work | work
3 | work | work | work
---------------------------------------------------
1 | work | work | work
after 2 | work | work | work
3 | work | fail | work
the reason why it fails is expected (git now finds the SUDO_UID variable
and rejects the repository because it is NOT owned by that id (it was created
by root anyway, even if there is no way for git to know that it was done
at a different time and with a different session, and therefore the SUDO_UID
variable it is honoring could be considered irrelevant in the current context.
in the documentation patch (which I think would be better to squash with the
fix) I explain what to do as a workaround, and I expect this use case to be
less common than the currently broken one (so a net positive)
Carlo
