Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option

[Junio C Hamano <gitster@pobox.com>]

"W. Trevor King" <wking@tremily.us> writes:

> On Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote:
>
>> I would not object to "git config submodule.$name.branch $value", on
>> the other hand.  "git config" can be used to set a piece of data
>> that has specific meaning, but as a low-level tool, it is not
>> _limited_ to variables that have defined meaning.
>
> This is what I'm doing now:
>
>   $ git submodule add -b <branch> <repo> <path>
>   $ git config --file .gitmodules submodule.<path>.branch <branch>
>   $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
>
> With my second patch (Phil's config export), that becomes
>
>   $ git submodule add -b <branch> <repo> <path>
>   $ git config --file .gitmodules submodule.<path>.branch <branch>
>   $ git submodule foreach 'git checkout $submodule_branch && git pull'
>
> With my first patch, that becomes
>
>   $ git submodule add -rb <branch> <repo> <path>
>   $ git submodule foreach 'git checkout $submodule_branch && git pull'
>
> This seems pretty useful to me,...

Ah, this reminds me of another thing I noticed when I saw that
patch.  The change seems to think "branch" is the _only_ thing the
user might want to record per submodule upon "git submodule add".
As an interface to muck with an uninterpreted random configuration,
it squats on a good option name for setting one single and arbitrary
variable---quite a selfish change that is not acceptable.

Calling the option "--record-branch-for-submodule" or something more
specific might alleviate the problem, but then it would become even
less useful as a short-hand for "config submodule.$name.branch", I
would suspect.

On the other hand, if this were one small part of a series to define
the "tip following mode" where (at least)

 (1) "git submodule update [$path]" makes sure that the checkout of
     the submodule at $path matches the commit at the tip of the
     branch named by submodule.$name.branch in .gitmodules of the
     superproject, instead of the commit that is recorded in the
     index of the superproject; and

 (2) "git diff [$path]" and friends in the superproject compares the
     HEAD of the checkout of the submodule at $path with the tip of
     the branch named by submodule.$name.branch in .gitmodules of
     the superproject, instead of the commit that is recorded in the
     index of the superproject.

and the option were called something like "--follow-branch=$branch",
it would make much more sense for its initial implementation to set
the name of the branch to submodule.$name.branch variable.  Later
iterations of such a feature may want to do more than just setting
that single variable but that is a part of the implementation detail
of the tip following mode the users do not have to know about, just
like setting the submodule.$name.branch variable is.

So in that sense, too, I would be somewhat unhappy to see this
change in the current form to go in.