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

Hi,

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

On Fri, Mar 1, 2013 at 6:46 PM, Junio C Hamano [off-list ref] wrote:

Francis Moreau [off-list ref] writes:

quoted

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.

[...]

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