"W. Trevor King" <wking@xxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html