Re: [PATCH 2/2] Introduce git submodule attached update

From: W. Trevor King <wking@tremily.us>
Date: Jan 7, 2014, 04:10 UTC
Message-ID: <20140107041004.GA11060@odin.tremily.us>
In-Reply-To: <CALas-ihHD_eJOXLUrhCVZjidQDmrCN=QpdfMKoN1i9A7FAo3RQ@mail.gmail.com>

On Mon, Jan 06, 2014 at 06:47:58PM +0100, Francesco Pretto wrote:

> I'm really sorry, I thought this was already clear from the first
> patch iteration. I will go more in depth:

For me anyway, this extra detail is very helpful.  Thanks :).

Show 10 quoted lines

> Maintainer of "project1" also prepares a branch
> "project1-staging-featureA" on "common" and set ".gitmodules" of
> "project1" to point to "project1-staging-featureA". Developers of
> featureA would like to do this:
> 
> $ git pull
> $ git checkout staging-featureA
> $ git submodule update      # clones an attached HEAD of common on the branch
>                             # 'submodule.common.project1.staging-featureA'
> $ .... start coding in common seamlessly as they where in project1 ....

So the checked-out branch switches depending on the local superproject branch. That sounds nice, but I'm not sure where the superproject-branch-to-local-submodule-branch mapping would be stored. We currently do this for remote-tracking submodule branches with an in-tree .gitmodules (which can differ between submodule branches) with local overides in a single out-of-tree .git/config (which is independent of the checked out branch). Ideally we'd have a way to add local overrides on a per-superproject-branch basis, but I don't know what that would look like.

Show 6 quoted lines

> Also developers do frequently rebase:
> $ git pull --rebase
> $ git submodule update
> 
> Or maybe a shortcut of this: "git submodule update" should be given
> the possibility to go "--remote" by default.

Rebasing the superproject and then updating the submodules (to the superproject's gitlinked commits) is not the same as a --remote update (to the subproject's upstream branch tip).

> Of course if "common" of the developer is in a branch different that
> 'submodule.<name>.branch' "git submodule update" has not to switch
> the branch.

I don't understand what you're saying here.

Show 11 quoted lines

> >> Maybe who coded submodules at first was thinking that the best
> >> way to contribute to a project is to checkout that repository,
> >> and not work in the submodule. As said, this works well when the
> >> submodule repository is a full project, and not a bunch of shared
> >> code.
> >
> >Why not work in the submodule? See explanation above.
> 
> Because, as said above, the submodule is not independent. It does
> not have proper code that test it and the best test case is using
> the submodule in the scope of the superproject.

You can cd into the submodule, and develop it as an independent repository. When you want to test your changes, just cd back into the superproject and run your test suite.

Show 12 quoted lines

> 2014/1/6 Heiko Voigt <hvoigt@hvoigt.net>:
> > I am not so sure. svn:externals was IMO a hack in SVN to bind projects
> > together. It does not record the revision and so has nothing to do
> > with version control. If you simply want to always checkout the
> > development tip of some project you could do something like this:
> >
> >        git submodule foreach 'git fetch && git checkout origin/master'
> 
> This can be very unconvenient if the reccomended *starting* branch to
> where attach the HEAD is not "master":
> git submodule foreach 'branch="$(git config -f $toplevel/.gitmodules
> submodule.$name.branch)"; git checkout origin/$branch

Which is equivalent to:

  $ git submodule update --remote --checkout

except for branch-vs-detached-HEAD. If you are doing local development, I'd recommend setting up submodule.<name>.update to a non-checkout strategy and using:

  $ git submodule update --remote

which will integrate the upstream changes with any local changes (updating whichever local submodule branch you had checked out).

> Also with the comit[1] that blocks copying of !command to
> ".git/config" and sets default "none", you made it harder to offer a
> mantainer decided default update behavior like the one I described.

The maintainer can still suggest checkout/pull/rebase, and the developer can still clear remove the none from .git/config after initializing the submodule. You only need to do this once per submodule.

> I think maintainers should have the option to make developers to
> clone a repository starting with an attached HEAD on the branch
> suggested in submodule.$name.branch;

I agree, and want to use a non-checkout submodule.<name>.update mode to identify developers who would want this. My v2 patch switches on submodule.<name>.branch, but I'll update it in v3 to switch on submodule.<name>.update. There's no need to confuse this with additional attach/detach functionality.

> - "git submodule update" is missing a property to do automatically
> "--remote". I think in the use case I wrote it's really handy to have
> a "git submodule update" to act like this.

You can already add aliases, but a remote/local-gitlink config variable would be nice too.

Here's an attempted summary of our desires, and my ideal route forward:

* Preferred local submodule branches for each superproject branch.
  * Not currently supported by Git.
  * Requires some sort of per-superproject-branch .git/config.
  * Fall back to the remote-tracking submodule.<name>.branch?

* Auto checkout of the preferred branch
  * Can do this at clone-update time with my patch.
  * For later submodule branch switches, maybe we want:

      git submodule checkout [-b <branch>] [<paths>…]

    Then if a user blows off their detached HEAD, at least they'll
    feel a bit sheepish afterwards.

* Configurable (remote or local) default update source (so folks who
  primarily update --remote don't have to have long command lines).
  * New submodule.<name>.source = {remote|local} config
  * New 'update [--source={local|remote}]' option
  * Deprecate 'update --remote' with a long phase out.
  However:
  * Maybe they should just setup an alias instead?

Cheers, 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