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

["W. Trevor King" <wking@tremily.us>]

[-- Attachment #1: Type: text/plain, Size: 6106 bytes --]

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

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

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

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

> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]