Re: [RFC/PATCH] add update to branch support for "floating submodules"
- From
Phil Hord <phil.hord@gmail.com>
- Date
- Jan 31, 2012, 22:50 UTC
- Message-ID
- <CABURp0pSGGT8eyzNad-dNNx49oioAxOPOf3dmqu7M3fnV+PzdA@mail.gmail.com>
- In-Reply-To
- <4F28554D.9090107@web.de>
On Tue, Jan 31, 2012 at 3:55 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
Show 17 quoted lines
> Am 30.01.2012 22:15, schrieb Phil Hord: >> I lost my grip on this thread over the holidays... >> >> On Tue, Dec 13, 2011 at 4:09 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote: >>> Am 13.12.2011 15:17, schrieb Phil Hord: >>>> git pull origin topic_foo && git submodule foreach 'git pull origin topic_foo' >>>> >>>> git submodule foreach 'git push origin topic_foo' && git push origin topic_foo >>> >>> This sounds to me like you would need the "--recurse-submodules" option >>> implemented for "git pull" and "git push", no? >> >> Only if I have nested submodules, but yes, we do use --recurs* in our scripts. > > I'm confused, push doesn't know the "--recurse-submodules" option > at all yet while pull only does a deep fetch when it is given, the > submodule work trees are not updated to the merge result right now.
Sorry. I type faster than I think sometimes.
I meant that I do use something like this: git submodule foreach --recursive 'git checkout master' && git checkout master
And I expect to use something like this: git submodule foreach --recursive 'git push origin topic_foo' && git push origin topic_foo
Show 14 quoted lines
>>> And I miss to see how >>> floating would help when the tips of some submodules are not ready to >>> work with other submodules tips ... >> >> By project policy, for any branch, all submodules' tips of the >> same-named branch should be interoperable. The CI server looks after >> this, as much as he can. > > We do the same thing on our CI server, but it can only test some > combinations (even though that tends to show most problems pretty > early). But in the end every superproject is responsible to use a > working set of submodule commits, and I would rather bet on a > combination the CI server tested than on what happens to be on the > current tips.
Yes, I see what you mean. In our case, what "happens to be on the tips" should also have been vetted by our Gerrit+Jenkins code review dance (for each branch * each superproject), and so it should always be good. If it's not, we have the Jenkins-maintained gitlink history we can use to bisect.
Show 8 quoted lines
>> I think of branch names as sticky notes (extra-lightweight tags, >> sometimes). We have linear history in many of our vendor submodules, >> but multiple "branches" indicate where each superproject branch has >> presumably finished integration. > > We also add a branch in submodules every time a superproject needs > to move away from the submodules master (so the commits won't get > lost by accident).
Good idea. Gerrit sees to this for us also, but we do share code on ancillary git servers and we follow the same practice.
Show 10 quoted lines
>>>> But not all my developers are git-gurus yet, and they sometimes mess >>>> up their ad hoc scripts or miss important changes they forgot to push >>>> in one submodule or another. >>> >>> Sure, even though current git should help you some by showing changes >>> in the submodules. >> >> Real newbies may not even remember to use 'git status' strategically. > > Hmm, but then they will screw up things in the superproject too, no?
What I mean is that a developer may be completely focused on one particular submodule (his domain). He does his work in this module, and when it's ready he commits and pushes to the server. 'git status' shows him that his directory is clean. But this is only because he doesn't really know where the submodules top-directories are, so he doesn't realize that he has changes in another submodule that he has not committed. He has to know to run 'git status' from somewhere in the superproject (ostensibly in the root directory of that superproject). But he may forget since 'git status' already assured him he was done.
Like this:
#-- Setup mkdir super && cd super && git init mkdir A && touch A/foo git add . git submodule add gerrit:iptv/iptv_scripts B git commit -m "Initial commit"
#-- Work flow cd A && echo changes > foo cd ../B && echo changes > foo git add . && git commit -m "Made some changes" git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # nothing to commit (working directory clean)
So git just told my new-to-git developer that his workdir is clean because he happened to run it from super/B. But if he ran it from super/A (or super) it would tell him otherwise.
I guess what would help here is something like the opposite of 'git status' showing the status of descendant submodules; it would help if it showed the status of sibling submodules and the superproject as well.
Show 29 quoted lines
>>>> Or worse, their pull or push fails and >>>> they can't see the problem for all the noise. So they email it to me. >>> >>> We circumvent that by not pulling, but fetching and merging in the >>> submodule first and after that in the superproject. You have much more >>> control about what is going wrong where (and can have more >>> git-experienced people help with - or even do - the merges). >> >> I do that, too, and I wish I didn't have to. I wish I could safely >> and sanely recover from a conflicted "git pull --recurse-submodules" >> pull from the superproject. > > That's what my recursive checkout work is aiming at. Me thinks after > that we will also need some good ideas on how to present and help > solving submodule merge conflicts. > >> That is, I wish doing so were as >> straightforward as recovering from the same condition would be if all >> my code were in one repository instead of in submodules. >> >> Which is the gist -- I wish submodules did not make git more >> complicated than it already is. > > I think we can make working with submodule much easier than it is > now, the next step being updating all submodule work trees as git > updates the superproject's work tree. Even though I suspect that in > the long run submodules will always be a bit more complicated than > having everything in one repository, I'm confident that will be by > far outweighed by the advantages they bring.
I'm really looking forward to it.
Thanks, Phil