On Wed, Dec 7, 2011 at 23:18, Justin Martin <frozenf...@php.net> wrote: > On 11-12-07 01:35 PM, Hannes Magnusson wrote: >> >> On Wed, Dec 7, 2011 at 22:01, Justin Martin<frozenf...@php.net> wrote: >>> >>> On 11-12-07 11:46 AM, Hannes Magnusson wrote: >>>> >>>> >>>> On Wed, Dec 7, 2011 at 18:09, Justin Martin<frozenf...@php.net> >>>> wrote: >>>>> >>>>> >>>>> On 11-12-07 02:58 AM, Hannes Magnusson wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 7, 2011 at 01:57, Justin Martin<frozenf...@php.net> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hello everyone, >>>>>>> >>>>>>> There's been some informal discussion in #php.doc on EFnet about how >>>>>>> the >>>>>>> transition from Subversion to Git will be achieved, and what the >>>>>>> resulting >>>>>>> structure will look like. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> We can't use submodules. >>>>>> Submodules in git reference a specific commit, not "last commit" like >>>>>> it does in svn by default. >>>>>> >>>>>> If we use git submodules in means; >>>>>> Every time we update doc-base, you have to update the submodule in >>>>>> _all_ translations to the last commit and commit the change. >>>>>> >>>>>> -Hannes >>>>> >>>>> >>>>> >>>>> >>>>> Hi Hannes, >>>>> >>>>> I was actually thinking of that issue, and thought that it would be a >>>>> simple >>>>> matter to use a client-side post-checkout hook to run "git submodules >>>>> foreach git pull". That'd update each submodule. >>>>> >>>>> Not sure of the specifics in that regard, but I can't think of any >>>>> other >>>>> solution to that problem than submodules. >>>> >>>> >>>> >>>> Debugging client side post hooks is not something I want to even think >>>> about when debugging why some translation doesn't work. >>>> >>>> And, using this model, you would need to have 100 checkouts of >>>> doc-base if you have 100 translations locally. >>>> >>>> I would rather recommend that you simply have to do an explicit >>>> doc-base checkout and update, not bundling. >>>> >>>> >>>> Also, what worries me more is the way we determine if a file is >>>> up2date or not. git doesn't have these sort of keywords and the idea >>>> of bumping the files revision manually has been rejected several times >>>> (although not in this context, the idea was to eliminate the >>>> translators need to bump their version on english typo and ws fixes). >>>> >>>> -Hannes >>> >>> >>> >>> Hi Hannes, >>> >>> There's not much difference between the way that Subversion does >>> svn:externals automatically, and scripting it with hooks in git. I mean, >>> if >> >> >> Sure there is. One is something you explicitly need to configure - >> even before your first checkout, and the other "just works". >> >>> you do have a better idea, I'm definitely all-ears, because I've been >>> racking my brain for one. :P >> >> >> Well, my first thoughts are >>>> >>>> I would rather recommend that you simply have to do an explicit >>>> doc-base checkout and update, not bundling. >> >> >> that also solves the issue of having bucketloads of copies of the >> exact same repo. >> Not to mention no pre-configuration and trivial to debug. >> >> >>> As for doing svn:keywords, I've already pretty-well solved that. >>> https://github.com/TheFrozenFire/git-rcs-keywords >>> >>> That's a fork of a solution which uses clean and smudge filters, which >>> I've >>> modified from using Perl to using PHP. It's still in the works, but it's >>> a >>> reasonable solution to a complicated problem. >> >> >> This is just adding more and more prerequisites. Increasing the >> difficulty to get up and running and more frustration and issues >> debugging when it doesn't work for someone :( >> >> >> -Hannes > > > Hi Hannes, > > Submodules are cloned automatically. With a simple hook, they can be updated > on pull as well. That's almost exactly equivalent to the subversion way; the > only difference is that it's something we configure explicitly. There's no > increase in debugging that I can see.
No, submodules aren't cloned automatically. But even if they were, we still have a problem. When I fork the repo, I would not want the submodule to point to the original doc-base, I ofcourse would want it to point to my own fork. I really don't like the idea of submodule and really really would prefer an explicit checkout of doc-base. -Hannes
