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

From: W. Trevor King <wking@tremily.us>
Date: Dec 3, 2012, 18:15 UTC
Message-ID: <20121203181519.GC14981@odin.tremily.us>
In-Reply-To: <7v8v9ft761.fsf@alter.siamese.dyndns.org>

On Mon, Dec 03, 2012 at 08:46:46AM -0800, Junio C Hamano wrote:

Show 7 quoted lines

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

Show 16 quoted lines

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