Re: [PATCH 0/3] git-describe deals gracefully with broken submodules

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 21, 2017, 06:54 UTC
Message-ID: <xmqq37e7t902.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqq7f3jta7o.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 12 quoted lines

> I do not have a strong preference for or against the "treat a broken
> repository as if nothing is wrong with the revision, but just mark
> it as dirty" idea.  I would be more receptive if it substituted the
> "-dirty" marker with something else, e.g. "-broken", though.
> ...
> But it is possible there may be a reason why submodules are special.
> I do not think the third paragraph quoted above is a good
> justification.  A repository with broken submodule is just as broken
> and untrustworthy as a broken repository without a submodule, and if
> you want to allow such a checkout with broken submodule to call
> itself v2.0-dirty, you would also want to allow a broken checkout
> without any submodule to do so, too.

Having said all that, if I thought it were a good idea to optionally allow people to treat "repository is corrupt in some ways to make it impossible for us if the checkout is dirty or not, even though we are fairly certain what commit .git/HEAD points at is" as a state that is describable, I probably would

 - introduce a new "git describe --possibly-broken" option;

 - instead of running "diff-index" internally to decide the "-dirty"
   state, spawn "diff-index" as a separate process;

 - observe the exit status from "diff-index" and add "-dirty" suffix
   when it is _known_ to be dirty, add "-broken" suffix when it
   died, and leave out the suffix when we know that the checkout is
   clean.

That way, we wouldn't have to contaminate the generic codepath with a "treat broken and modified states as if they are the same" logic, only to support such a niche feature that we wouldn't want to use anywhere else.