On 03/30/2011 11:08 PM, Junio C Hamano wrote: > Nicolas Morey-Chaisemartin <devel-git@xxxxxxxxxxxxxxxxxxxxxx> writes: >> Well I was'nt sure about it either. >> The idea for me was to be able to put the repo and submodules in the cloned state (except for ignored files) >> In the current version the right thing to do is a bit of a mess: >> $ git submodule foreach --recursive 'git checkout -f HEAD' >> $ git submodule foreach --recursive 'git clean -f' # An untracked file on HEAD may be overwrittent by the new HEAD so checkout may fail if you don't do that >> $ git submodule update --recursive > > Shouldn't you be questioning _why_ your users have such changes that > require them to run "checkout -f" everywhere in the submodule forests and > still want to run "submodule update" in the first place? If it happens > very often and your users are constantly discarding what they have half > accomplished, there is something wrong with the way your project works. > I did. Thee reason is we commit file generated by compilation. Whether it's docs, references (for automated integration) or simply result files that take 2 days to build, we have a strong need to commit generated files. And in this case, we need to discard a lot of things very often. > If we read your motivation section in your original, > > > This implies that to reset a whole git submodule tree, a user has to run > > first 'git submodule foreach --recursive git checkout -f' to then be > > able to run git submodule update. > > this is about "resetting", i.e. throwing away the work. I think that is a > sensible thing to do, but it is a very different purpose than "updating > submodules so that I can work on top of what other people did", which > would happen a lot more often than that. > > Wouldn't it be both safer and easier to understand for the users if this > "obliterate all my uncommitted work" were a separate subcommand, e.g. "git > submodule reset --recursive" or something? > I agree. A git submodule reset command makes a lot of sense. But I also still think having a --force option to update does too, in the way Jens proposed it (only on submodule that actually needed a checkout), don't you? -- 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