El dv 05 de 11 de 2010 a les 13:34 +0200, en/na Khaled Hosny va escriure: > On Fri, Nov 05, 2010 at 01:29:15PM +0200, Simos Xenitellis wrote: > > > > On Fri, Nov 5, 2010 at 9:51 AM, Matej Urban <matej.ur...@gmail.com> wrote: > > > > > > > > Well, we don't care much, the master branch is unmaintained and > > > hopefully nobody uses it. > > > > > > > I understand this developers perspecitve. But I read your statement > > as: "Well, we don't care much *about the quality of the translations*, > > the master branch is unmaintained and *if somebody uses it, eeee, why > > do we bother translating anyway?*. > > I also read: "If translators want some order in the project, they > > should get one of those boring paper-sorting jobs". > > I also hear: "Anyway, be glad that we let you use it." > > > > Is really so hard to "rename" master to old_master and then "rename" > > gcomvcyvycprxsyvcyvcydsfdaso to master? > > > > > > > > I would say the concern is something like this, > > http://stackoverflow.com/questions/1526794/git-rename-remote-branch > > > > Bruno mentioned that he does not oppose to the switch (I am rephrasing). > > > > Therefore, assuming that indeed people would need to clone again the > > gcompris > > repository > > (who can verify this? Matej, Александър?), there should be an announcement > > for those with gcompris clones to clone again after a specific cutoff date. > > I discussed this a while ago with Bruno, and IIRC the only practical > solution requires admin intervention because some git operations are > restricted on g.g.o. > > Regards, > Khaled >
Hi, Maybe there's an even easier solution if you (gcompris devs I mean) reply 'no' to the following question: Does any commit on master branch really matters[1]? If the answer is no then you can just clone gcompris and checkout master branch, then in a separate folder clone again compris and checkout to gcomprixogoo. With those two folders (one containing master and the other gcomprixogoo) just do a plain replace of all files changed and added from gcomprixogoo to master and remove all files not in gcomprixogoo which are on master and make a huge commit with it (or partial commits if you prefer). With this you will simulate a git merge but effectively you are making master as gcomprixogoo. With this approach no sysadmins' help is needed and you will be 100% sure that the resulting master branch will be exactly the gcomprixogoo branch. A first step to do this would be to plain copy/replace/remove all images and binary files, just doing a git diff --stat master..gcomprixogoo gives that +5k files are changed but lots of them are images which is trivial to move (you know the good ones are on gcomprixogoo) and it will allow git merge tool to be less stressed when doing the merge. After either approach is taken just create a new branch based on master if you still plan to work on different branches for stable/dev work. Hope this approach can help. Cheers, [1] Sure translations, but those can be easily migrated -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net planet: http://planet.guifi.net _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n