Re: [PATCH 0/2] fix problems with recursive submodule fetching
On Sep 19, 2010, at 9:40 AM, Jens Lehmann wrote:
Show 20 quoted lines
> Am 19.09.2010 05:54, schrieb Kevin Ballard:
>> Here's the submodule layout:
>>
>> .--Root-.
>> / / /|\ \ \
>> A B C D E F G
>> |
>> H
>> /|\
>> I J K
>> /|\
>> L M N
>> /|\
>> O P Q
>>
>> I control the root, and I control most of the first-level of submodules. I would also not mind seeing updates to other submodules at that level, though that doesn't generally concern me. However, I don't control submodule H, and I have absolutely no desire whatsoever to see updates to I-Q unless needed by submodule H. In this layout, regularly running `git submodule update --init --recursive` works perfectly. Having `git fetch` fetch submodules I-Q on every invocation is a complete waste of my time.
>
> Sounds like adding the "fetch=no" option to the .gitmodules entry
> for submodule H would help you. That would tell "git fetch" to not
> recurse into H and deeper.
The problem is that while I want to get updates from H, I don't control H so I can't add anything to its .gitmodules. I can go in and edit H's .git/config to handle this, but then everybody else that clones this project will have the exact same problem.
> But as you seem to be fine with running "git submodule update --init
> --recursive" when needed you might be even better off by setting the
> upcoming global config option to control recursive fetching to false.
Perhaps, but that negates any benefit from this patchset whatsoever. You're optimizing for the case where you control the project and every level of submodules beneath it, and you want to be notified the moment there's a commit available on any of them to pull into the parent. My argument is that two extremely common cases are you don't control all the submodules beneath yourself, and your submodules are pegged to versioned tags. In both these cases, you don't want to recursively fetch for changes every time. I think fetching everything every time has merit, but I don't think it's a worthwhile default. A far better default would be to only fetch submodules if a gitlink entry is updated in the parent repository. Given that this may be complicated, a reasonable compromise might be to update
submodules only if the parent repository had changes, and then this can be overridden to either always update or never update submodules.
I should also like to point out that, although the original motivation for this fetching (judging from the commit messages) seems to be to prevent you from having problems diffing the current submodule with the value stored in the gitlink, this doesn't actually do anything to help the fact that, if you have a clean tree with no changes and all submodules are up-to-date, you can run `git pull` and end up with a dirty tree as submodules are not automatically updated when their gitlink changes. I hope someone is considering modifying pull/merge behavior to update submodules automatically if their gitlink changes and they were already in a clean state with a detached HEAD pointing at the old value of the gitlink (e.g. if you checkout master, or if you make changes, don't update it).
> But IMHO it makes more sense to let checkout take care of submodules
> too and get rid of the necessity to call "git submodule update" every
> time a submodule needs to be updated ...
I agree. Checkout should be perfectly capable of handling this. Submodules are a powerful feature, but they are one of the least user-friendly aspects of git in my opinion.
-Kevin Ballard
Kevin Ballard <kevin@sb.org>