Re: Transition from Subversion to Git
| From: | Justin Martin | Date: | Fri, 09 Dec 2011 20:29:03 +0000 |
| Subject: | Re: Transition from Subversion to Git | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.doc |
| Request: | Send a blank email to phpdoc+get-969383502@lists.php.net to get a copy of this message | ||
On 11-12-09 02:42 AM, Hannes Magnusson wrote:
On Wed, Dec 7, 2011 at 23:18, Justin Martin<frozenfire@php.net> wrote: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 Hi Hannes, I asked #git on Freenode about how best to resolve this issue, and the prevailing suggestion was to use git-slave (http://gitslave.sourceforge.net/gits-man-page.html). It apparently is particularly developed to solve this issue, and seems to be somewhat mature. I'll definitely be doing some testing, to see if it works. Thanks, Justin MartinOn 11-12-07 01:35 PM, Hannes Magnusson wrote: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.Sure there is. One is something you explicitly need to configure - even before your first checkout, and the other "just works".On Wed, Dec 7, 2011 at 22:01, Justin Martin<frozenfire@php.net> wrote:On 11-12-07 11:46 AM, Hannes Magnusson wrote:On Wed, Dec 7, 2011 at 18:09, Justin Martin<frozenfire@php.net> wrote: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, ifOn 11-12-07 02:58 AM, Hannes Magnusson wrote: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). -HannesOn Wed, Dec 7, 2011 at 01:57, Justin Martin<frozenfire@php.net> wrote: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.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. -Hannesyou do have a better idea, I'm definitely all-ears, because I've been racking my brain for one. :PWell, my first thoughts arethat also solves the issue of having bucketloads of copies of the exact same repo. Not to mention no pre-configuration and trivial to debug.I would rather recommend that you simply have to do an explicit doc-base checkout and update, not bundling.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