On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote: > On Fri, Nov 23, 2012 at 12:54 PM, W. Trevor King <wk...@tremily.us> wrote: > > [snip initial thoughts leading to the update --remote v5] > > I was thinking the same thing, but reading this whole thread a couple of > weeks late. Thanks for noticing. > > Moreover, I think that 'git submodule update --pull' is also the wrong way > to spell this action. Maybe you are misled from the outset by your > current workflow:
Did you see my v5 (add --remote) series? > For that reason, I don't like the --pull switch since it implies a > fetch, but I will not always want to do a fetch. $ git submodule update --remote --no-fetch will not fetch the submodule remotes. > I don't know which remote I should be tracking, though. I suppose > it is 'origin' for now, but maybe it is just whatever > $superproject's HEAD's remote-tracking branch indicates. With the --remote series, I always use "origin" because that's what `submodule add` should be setting up. If people want to change that up by hand, we may need a submodule.<name>.remote configuration option. > I am not sure I want the gitlinks in superproject to update automatically > in the index, but I definitely do not want to automatically create a commit > for them. Commits are dissabled by default (see my recent --commit RFC for how they would be enabled). > But I really don't want to figure out how to handle submodule > collisions during a merge (or rebase!) of my superproject with changes that > someone else auto-committed in his local $superproject as he and I > arbitrarily floated up the upstream independently. There is nothing but > loathing down that path. This is true. I'm not sure how gitlink collisions are currently handled… Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
