Hi, sorry for the late reply but my git time is limited. On Sat, Nov 10, 2012 at 02:02:32PM -0500, W. Trevor King wrote: > On Fri, Nov 09, 2012 at 05:29:27PM +0100, Heiko Voigt wrote: > > I think we should agree on a behavior for this option and implement it > > the same time when add learns about it. When we were discussing floating > > submodules as an important option for the gerrit people I already started > > to implement a proof of concept. Please have a look here: > > > > https://github.com/hvoigt/git/commits/hv/floating_submodules > > After skimming through this, something like > > $ git submodule update --pull > > would probably be better than introducing a new command: Yeah along the lines of that, but one thing to keep in mind: We already have --rebase and --merge which do slightly different things (I think). Adding --pull here should behave similar to them. Like fetch and merge is the same to pull without submodules. If I am understanding your goal correctly your --pull would be different. On the other hand: A --pull makes no sense if we apply it to the existing --merge option since it merges the recorded sha1 into the current HEAD. Just a fetch would not really make a difference. Thinking along the existing options I would probably still expect --pull to merge something into the current HEAD. So maybe we have to iron out where this command/option should go. But changing that once we have a patch to discuss should not be that much work. So please proceed with --pull and once we know exactly what it does we can polish that. > On Sat, Nov 10, 2012 at 01:44:37PM -0500, W. Trevor King wrote: > > $ git submodule pull-branch > > I think "floating submodules" is a misleading name for this feature > though, since the checkout SHA is explicitly specified. We're just > making it more convenient to explicitly update the SHA. How about > "tracking submodules"? Until now we have always called this workflow floating submodules. I imaging since the submodule floats to the newest revision (whatever the user chooses that to be) instead of staying at the recorded sha1. "tracking submodules" sounds strange to me since the term tracked in git is mainly used in combination with exact recorded history (e.g. tracking branch). Since it is about *not* checking out the recorded sha1 but something that can change I think that could cause confusion. I think floating is a more unambiguous term and already known on the list. Cheers Heiko -- 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