Am 31.03.2011 04:20, schrieb Nicolas Morey-Chaisemartin: > On 03/30/2011 11:08 PM, Junio C Hamano wrote: >> 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. We are in a similar situation at my dayjob, but we handled the issue in a different way. We were reluctant to check in generated files into our repository, so we decided to distribute them via zip files. We have a beefy build machine which builds and tests master over night and if everything went ok it zips the whole work tree including .git directory, build artifacts and submodules into one file. Then each developer just has to unpack this file, fetch from the git server and he is all set. >> 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. Me too agrees that being able to reset a whole work tree including all submodules recursively makes a lot of sense. But I would not be so happy seeing this functionality being added to the git-submodule.sh script, as I believe it belongs into "git reset", so you'll just have to do a "git reset --hard --recurse-submodules" and you are done. In the branch "git-checkout-recurse-submodules" in my github repo (which is at https://github.com/jlehmann/git-submod-enhancements) you can see a preliminary implementation of that (it works and I use it every day at my job. It has recursion enabled by default at the moment yet still might overwrite local changes even if it shouldn't, so use with care ;-). > 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? Yes, I still think it makes sense to add the "-f" flag to submodule update. -- 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