Re: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes

On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King [off-list ref] wrote:

On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote:

quoted

On Fri, Nov 23, 2012 at 12:54 PM, W. Trevor King [off-list ref] wrote:

quoted

[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?

Eventually, I did.  Sorry for the out-of-order replies.

quoted

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.

This seems precisely backwards to me. Why not use

  $ git submodule update --remote --fetch

to do your "default" behavior instead?   I suppose I am arguing
against the tide of the dominant workflow, but the fetch-by-default
idea needlessly conflates two primitive operations:  "float" and
"fetch".

quoted

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've always felt that the "origin" defaults are broken and are simply
being ignored because most users do not trip over them.  But ISTR that
submodule commands use the remote indicated by the superproject's
current remote-tracking configuration, with a fallback to 'origin' if
there is none.  Sort of a "best effort" algorithm, I think.  Am I
remembering that wrong?

quoted

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).

quoted

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…

They've always been trouble for me.  But it may be that I am ignorant.

Phil