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:
signature.asc
Description: OpenPGP digital signature