Hi, Sorry for the long delay, I somehow missed your answer... On Fri, Mar 1, 2013 at 6:46 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Francis Moreau <francis.moro@xxxxxxxxx> 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 ? Thanks. -- Francis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html