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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 11, 2012, 10:33 UTC
Message-ID: <7vzk2oo2d2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20121110184437.GC2739@mjolnir>

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

Show 25 quoted lines

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