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

On Fri, Mar 1, 2013 at 6:46 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Francis Moreau <francis.m...@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.


> 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 ?

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to