Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > I didn't check each site in detail, but I suspect each ignore option > was added on purpose to fix a problem. That means we still need "all" > (at least when diffing rev<->index). Unfortunately that area is not > covered well in our tests, I only got breakage from the filter-branch > tests when teaching "all" to only ignore work tree changes (see at the > end on how I did that). > > So I'm currently in favor of adding a new "worktree"-value which will > only ignore the work tree changes of submodules, which seems just what > the floating submodule use case needs. Could you help me clarify what it exactly mean to only ignore the work tree changes? Specifically, if I have a submodule directory whose (1) HEAD points at a commit that is the same as the commit that is recorded by the top-level's gitlink, (2) the index may or may not match HEAD, and (3) the working tree contents may or may not match the index or the HEAD, does it only have the work tree changes? If the HEAD in the submodule directory is different from the commit recorded by the top-level's gitlink, but the index and the working tree match that different HEAD, I am guessing that it no longer is with "only the work tree changes" and shown as modified. If that is the suggestion, it goes back to the very original Git submodule behavour where we compare $submoduledir/.git/HEAD with the commit object name expected by the top-level and say the submodule does not have any change when and only when these two object names are the same, which sounds like a very sensible default behaviour (besides, it is very cheap to check ;-). -- 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