Re: Adding "--ignore-submodules" switch to git-describe

From: Francis Moreau <francis.moro@gmail.com>
Date: Mar 8, 2013, 20:04 UTC
Message-ID: <CAC9WiBhHmqn7QZMLFcLjqGPamHmbMFNxvQ6Yzv5dr=+fe+F3_g@mail.gmail.com>
In-Reply-To: <7v621bggi5.fsf@alter.siamese.dyndns.org>

Hi,

Sorry for the long delay, I somehow missed your answer...

On Fri, Mar 1, 2013 at 6:46 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 18 quoted lines

> Francis Moreau <francis.moro@gmail.com> writes:
>
>> Would it make sense to add the option --ignore-submodules (currently
>> available in git-status) to git-describe when the later is used with
>> --dirty option ?
>
> I think the spirit of "describe --dirty" is to allow people who
> gives out binaries this assurance:
>
>         The version string I got out of "describe --dirty" does not
>         say dirty. If the recipient of the binary later reports
>         issues, I should be able to reproduce the same binary by
>         starting from a pristine checkout of the version (provided
>         if I didn't screw up and depended on an untracked file when
>         I initially created the binary, or used a custom build
>         option, or lost the toolchain, ..., of course).
>
> With that in mind, does --ignore-submodules make sense?

Well, I wouldn't have thought about this definition of "describe --dirty". I would have thought that, by default, this command look only at the files that git knows/tracks. There're too many external (to the git repo) parameters that could influence the build of a project: environment variables, components of the toolchain, version of each components etc... that git doesn't know about.

[...]

Show 5 quoted lines

>
> But when we ignore untracked paths in the superproject, we should
> ignore untracked paths in submodule working trees consistently.
>
>

yes I agree.

But in the short term, could you suggest a method to workaround this inconsistency ?

Thanks.

-- 
Francis