Re: Question: behavior when reverting a commit from a shallow clone

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> Yeah, this can indeed be surprising behaviour. The reason for it is that
> in a shallow clone, we rewrite the boundary commit (so in your case B)
> so that it doesn't have any parents anymore. It thus looks like just
> another root commit that has added all files in a single go. And the
> consequence of that is that reverting it will then delete everything.
>
> Now arguably, Git could be improved here. We just recently had a similar
> discussion around maybe forbidding to "git commit --amend" such a
> shallow commit. Your scenario is a second one where Git should probably
> at least warn about what's happening.
>
> Arguably we should even completely refuse editing such a shallow commit
> by default. I would guess that in 99% of all the cases where a user does
> it it's unintended. And for the 1% where it's actually intended we could
> give users a way to override this safeguard.

Yeah, I think that line of thinking is going in the right direction.

It is not surprising that these non-core features (read: as opposed
to really core features that were already considered mature even
back in Git 1.5.3) that had many years to mature still has rough
edges even today around corners that practicaly nobody has touched,
and we should not be afraid to round them further.

> I wouldn't warn about an empty tree in general. But editing a commit
> that is a shallow boundary is something that I'd agree Git should warn
> about, if not even refuse by default.

Yes.  Committing an empty tree, whether at the beginning of a
project or in the middle of a project after you fed up with too many
bugs in your early attempts and want to start clean, is a perfectly
normal, if wasteful, thing to do.

Thanks.