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