Re: [PATCH v3 2/3] sha1dc: optionally use sha1collisiondetection as a submodule
On Tue, Jul 04 2017, Junio C. Hamano jotted:
Show 23 quoted lines
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>>>> diff --git a/.gitmodules b/.gitmodules
>>>> new file mode 100644
>>>> index 0000000000..cbeebdab7a
>>>> --- /dev/null
>>>> +++ b/.gitmodules
>>>> @@ -0,0 +1,4 @@
>>>> +[submodule "sha1collisiondetection"]
>>>> + path = sha1collisiondetection
>>>> + url = https://github.com/cr-marcstevens/sha1collisiondetection.git
>>>> + branch = master
>>>
>>> Do we need to say this "branch" bit?
>>
>> Yes, it's to make future updates easier, see b928922727 ("submodule add:
>> If --branch is given, record it in .gitmodules", 2012-12-19).
>
> Why? It's not like we want to _follow_ the 'master' branch of that
> sha1collisiondetection repository. We declare that a specific
> commit from the (sub)module is suited for our project, and do not
> really care to automatically update from whatever happens to be at
> the tip of 'master' there.I'm honestly at a bit of a loss as to to what the confusion is here. So to try to unravel that let's start from square one, explaining some things you surely know already, but hopefully clearing this up.
> It's not like we want to _follow_ the 'master' branch of that
> sha1collisiondetection repository.
Git has no support at all for submodules that somehow follow an upstream branch in the SVN sense of remotes, so no, that's not what putting "branch" into the .gitmodules config means at all.
> We declare that a specific commit from the (sub)module is suited for
> our project, and do not really care to automatically update from
> whatever happens to be at the tip of 'master' there.
There is no automatic updating involved. The "master" branch here is just metadata. If and when we bump the sha1collisiondetection submodule that's going to be from the master branch, so by recording it we save ourselves one step (in theory) by issuing some "pull updates from the branch we always update from" command, rather than being at a loss as to where we should go from the currently detached ref to N potential upstream branches to update from.
Now, it seems git-submodule's tooling for doing this is still rather crappy, but I think that's the idea, maybe I'm just holding it wrong.
Before git ever got this "branch" key in .gitmodules I'd added it to my own aliases (and they're happily compatible with git-submodule). It still (for me) works better than what git-submodule does:
$ git config alias.sm-mainbranch
!git config --file ../.gitmodules submodule.$NAME.branch || git describe --all --always | sed 's!^heads/!!'
$ git config alias.sm-pull-all
!git submodule foreach 'git checkout $(NAME=$name git sm-mainbranch) && git pull'So in a repo with submodules I can simply run "git sm-pull-all" and it'll update them all to the branch they're tracking, and at this point I can "git add" them and review the updates.
I think some invocation of "git submodule update ???" will do the same, but I can't from the docs see what that is right now.
In any case, if and when I/others figure that out the metadata will be there, saving us one step in updating this in the future.
>>
>>> Other than that looks good to me.
>>>
>>> Thanks.
