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

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

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

On Mon, Dec 03, 2012 at 08:46:46AM -0800, Junio C Hamano wrote:
> As you hinted in the first paragraph, you could flip between merge,
> rebase, and detach with a command line option when running the
> "update" subcommand, but I would imagine that the expected use
> pattern is that for a particular project, you would choose one mode
> and consistently stick to that mode.  To make it easier, the user
> can set submodule.$name.update once and run "update" without having
> to give any flags.

Sure.

> And this is about adding another mode to the "update" subcommand
> where the HEAD is not detached, nor merged, nor rebased, but is set
> to follow whatever commit a remote branch points at.

This is about adding another suite of modes.  Currently you can
rebase/merge/checkout the superproject-recorded $sha1.  I'm adding the
ability to rebase/merge/checkout a submodule-upstream branch.  I
discuss this explicitly in Documentation/git-submodule.txt when
describing --remote.

> Shouldn't the patch add a way for the user to set a configuration
> variable to signal that this new mode is always used when "update"
> is run without a command line flag?

How about a new submodule.<name>.update-source with (which can be
either superproject-gitlink or submodule-upstream)?  Or to be a bit
simpler and less explicit, a submodule.<name>.update-remote boolean?
For lack of a better name, I'll call this submodule.<name>.<something>
below.

> As the user has to configure submodule.$name.branch in order to use
> this mode anyway, I have a feeling that taking that as a signal, and
> ignoring submodule.$name.update altogether, might be a simpler
> interface from the end user's point of view.  That is,

As I mention earlier, submodule.<name>.update is still important.  I
think it's good to add a new submodule.<name>.<something> config and a
--no-remote option (to override a configured
submodule.<name>.<something>).  This way a user that generally updates
via the superproject's gitlink can still configure a branch to update
from when they use --remote.

>  (1) if you are not interested in the submodule $name, you do not
>      "init" it; you "init" it for all of the following.
> 
>  (2) if you want to have the tree state as recorded in the
>      superproject, you do "update" without any option to make the
>      HEAD of the submodule detached at the commit the superproject's
>      tree records;
> 
>  (3) if you want to follow the upstream project of the submodule,
>      you set submodule.$name.branch to the branch you want to
>      follow, and you do "update"---submodule.$name.update is ignored
>      and you will make the HEAD of the submodule detached at the tip
>      of the branch at the remote (using remote-tracking branch);
> 
>  (4) if you want to --merge or --rebase, you give them from the
>      command line, or use submodule.$name.update.

But what if your whant to merge the upstream project into a currently
checked out submodule branch?  Or rebase a currently detached head
against the upstream branch?

> I may be oversimplifying a bit, but a separate
> submodule.$name.remote feels very wrong;

I use submodule.<name>.remote in patch 4 to specify the name of the
superproject's remote (for when get_default_remote doesn't give the
value you want), but I think you're referring to the potential
submodule.<name>.<something> and the presense of the --remote option.

> How does this compare with the floating submodules Heiko has been
> working on?

Heiko's older hv/floating_submodules also uses submodule.<name>.branch
(with a similar interpretation).  There's also a --branch option to
`update` for command-line overrides (which I don't have, perhaps I
should add them?).  He reverts to the original behavior in the
presense of submodule.<name>.branch with `update --checkout`, or when
submodule.<name>.branch=HEAD.

He also fetches all remotes, while I fetch just the explicitly
configured submodule.<name>.remote falling back on
$(get_default_remote.  His submodule.<name>.branch is the full local
ref for the branch (e.g. 'origin/master'), while mine is just the
remote branch (e.g. 'master').  I split the remote (e.g. 'origin')
into submodule.<name>.remote in patch 4 so you can explicitly fetch
just that remote (and not all the remotes you may have configured for
that submodule).

For reasons that I don't understand, he only supports the `checkout`
update logic for remote branches.

Heiko's newer hv/floating_submodules_draft builds on my earlier v4
--local-branch option, but he uses his own processing logic.  He pulls
the existing 'update to $sha1' logic out into a new
handle_on_demand_update() and uses the stored submodule.<name>.branch
as the name of a local submodule branch to check out when tracking.
Then he pulls that local branches default upstream (configured in
.git/modules/<name>/config) with --ff-only.

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