Re: [RFC v2] submodule: Respect requested branch on all clones

> Am 09.01.2014 18:32, schrieb W. Trevor King:
> >  However, the local-branch setting needs to be both
> > per-submodule and per-superproject-branch, so .git/config doesn't work
> > very well.  I think it's better to use something like my
> > .git/modules/<submodule-name>/config implementation [1] to set this
> > override.
> 
> Yes, the local branch should be set in the submodule's .git/config
> to make operations done inside the submodule work seamlessly.

> > This lack of per-superproject-branch overrides applies to all of the
> > submodule.<name>.* settings, but you're unlikely to want an
> > out-of-tree override for 'path' or a per-superproject-branch override
> > for 'url', 'ignore', 'update', or 'chRecurseSubmodules'.
> 
> Unlikely it is not ;-) We do have people who set update=none in
> the .git/config of the superproject for submodules they don't have
> access to (and which is not necessary for their work).

> > On the other hand, maybe an in-tree .gitmodules is good enough,
> > and folks who want a local override can just edit .gitmodules in
> > their local branch?  I've never felt the need to override
> > .gitmodules myself (for any setting), so feedback from someone who
> > has would be useful.
> 
> That way these changes would propagate to others working on the same
> branch when pushing, which I believe is a feature.

> >> It have the impression that attaching the head to the given
> >> branch for merge and rebase might be the sensible thing to do,
> >> but it would be great to hear from users of merge and rebase if
> >> that would break anything for them in their current use cases for
> >> these settings.
> > 
> > Which local branch would you attach to before merging?  I think
> > 'git submodule update' should always use the current submodule
> > state (attached branch or detached HEAD) [3], and we should have a
> > separate call that explicitly checked out the desired submodule
> > branch [4].
> 
> Like we currently do with "git submodule update --remote" (where you
> have to have an explicit command telling git when to advance the
> branch)? Having a separate call that does something *after* a git
> command is exactly the problem I'm trying to fix with recursive
> update, so I'm not terribly excited ;-)

> >>> If it's not the first clone, you should take no action (and your
> >>> original patch was ok about this).
> >>
> >> I'm not sure this is the right thing to do, after all you
> >> configured git to follow that branch so I'd expect it to be
> >> updated later too, no? Otherwise you might end up with an old
> >> version of your branch while upstream is a zillion commits
> >> ahead.
> > 
> > Non-clone updates should not change the submodule's *local* branch
> > *name*.  They should change the commit that that branch references,
> > otherwise 'git submodule update' would be a no-op ;).
> 
> Okay, I seem to have misunderstood that. But what happens when the
> branch setting in .gitmodules changes, shouldn't that be updated?

> >> First I'd like to see a real consensus about what exactly should
> >> happen when a branch is configured to be checked out (and if I
> >> missed such a summary in this thread, please point me to it ;-).
> > 
> > I don't think we have a consensus yet.  A stand-alone outline of my
> > current position is in my v3 RFC [5], but I don't have any buy-in yet
> > ;).
> 
> I'll volunteer to prepare a table explaining the different modes
> in my github wiki. Will scan this thread and your pointers for input
> and will come back soon when I have something ready.

> >> And we should contrast that to the exact checkout and floating
> >> branch use cases.
> > 
> > With my v3 series, there are no more detached HEADs.  Folks using
> > checkout updates get a local master branch.  I do not change any of
> > the exact checkout (superproject gitlinked sha1) vs. floating
> > (subproject's remote submodule.<name>.branch via 'update --remote')
> > logic, because that already works well.  The problem is the local
> > branch handling, not the update/integration logic.
> 
> Ok. Maybe we could use the "<remote>:<local>" notation to store both
> remote and local branch in a single setting?

> >> later updates,
> > 
> > The same thing that currently happens, with the exception that
> > checkout-style updates should use reset to update the
> > currently-checked out branch (or detached-HEAD), instead of always
> > detaching the HEAD.
> 
> Won't the user loose any modifications to his local branch here?

> >> updates where the local and the remote branch diverged,
> > 
> > The same thing that currently happens.  For local (non --remote)
> > updates, the integrated branch is the superproject's gitlinked sha1.
> > For --remote updates, the integrated branch is the remote subproject's
> > submodule.<name>.branch.  We integrate that with the
> > currently-checked-out local branch (or detached HEAD) using the user's
> > preferred submodule.<name>.update strategy.
> 
> And for checkout I can easily overwrite the upstream branch with
> my local changes?

> >> when superproject branches are merged (with and without conflicts),
> > 
> > I don't think this currently does anything to the submodule itself,
> > and that makes sense to me (use 'submodule update' or my 'submodule
> > checkout' if you want such effects).  We should keep the current logic
> > for updating the gitlinked $sha.  In the case that the
> > .gitmodule-configured local-branches disagree, we should give the
> > usual conflict warning (and <<<===>>> markup) and let the user resolve
> > the conflict in the usual way.
> 
> For me it makes lots of sense that in recursive checkout mode the
> merged submodules are already checked out (if possible) right after
> a superproject merge, making another "submodule update" unnecessary
> (the whole point of recursive update is to make "submodule update"
> obsolete, except for "--remote").