On Wed, Nov 13, 2019 at 12:12 AM Luigi Toscano w= rote: > > Ben Cooksley ha scritto: > > On Tue, Nov 12, 2019 at 10:00 AM Alexander Potashev > > wrote: > >> > >> =D0=BF=D0=BD, 11 =D0=BD=D0=BE=D1=8F=D0=B1. 2019 =D0=B3. =D0=B2 17:02, = Luigi Toscano : > >>> > >>> Alexander Potashev ha scritto: > >>>> =D0=B2=D1=81, 10 =D0=BD=D0=BE=D1=8F=D0=B1. 2019 =D0=B3. =D0=B2 18:09= , Luigi Toscano : > >>>>> Most of translators are not so technical as the developers. And eve= n > >>>>> developers can shoot them in the foot with git, I see many issues c= oming from > >>>>> unwanted merges. > >>>> > >>>> We can block unwanted merged on the server with a Git hook like this= : > >>>> https://github.com/FabreFrederic/git-hook-pre-receive-reject-merge-c= ommit > >>> > >>> When I talk about local merges, I foresee a bit of mess when resolvin= g a merge > >>> locally, which may result in proper commits whose content has an inva= lid syntax. > >> > >> I don't get it. > >> > >> If you have conflicting changes, either with SVN or Git, you have to > >> resolve the conflict manually. Of course it's easy to break the syntax > >> while doing so, however SVN does not make it any easier than Git. > >> > >>>> Cloning the whole repo would be too much for some translators, howev= er > >>>> the new Git feature "git clone --filter" might be a solution: > >>>> https://unix.stackexchange.com/a/468182 > >>> > >>> Documentation does not seem to help (or at least I don't seem to find= it in > >>> the man pages for git 2.24). Do you know how it could filter just som= e > >>> directories? It seems more focused on filtering by object type. > >> > >> OK, I now tried this approach with Git 2.23 (see attached log) and > >> found horrible problems that make it basically unusable: > >> > >> 1. git-checkout downloads each file in a new SSH connection. It make > >> the download really slow: less than 1 file per second in my setup. > >> That means downloading of translations into one language would take > >> more than an hour. > >> > >> 2. git-status silently tries to download to whole Git repository. > >> > >> 3. git-commit tries to download some files one by one again. > >> > >>>> Shall I create a new Phabricator task "[WIP] Migrate translations fr= om > >>>> SVN to Git" so we can put relevant ideas in one place? > >>> > >>> I don't know. For me having a board and tasks (it's not just a single= task, > >>> it's an entire project) sounds like there is something that can be > >>> implemented, and I don't think it's the case. > >> > >> The tag [WIP] would hint that we are not sure if it can be > >> implemented. We can even name it "Reasons why translations cannot > >> migrate to Git", if necessary. > > > > Sorry, but if you proceed with using a title such as that one, then > > you are not being constructive or helpful towards this conversation. > > > > That title would indicate to me that the translation community is > > completely unwilling to consider change of any form. > > That's why it shouldn't be a task at this point, but a document showing w= hy we > can't migrate. > It's not a matter that we are unwilling to consider. The problem is that = the > current state makes it almost impossible to migrate. The document would > explain why. Spin that around please. It should instead be 'Challenges to migrate to Git= '. This is an exercise Sysadmin is reasonably familiar with when it comes to any system transition - there are always workflows and processes that need to be adjusted, tooling that needs to be tweaked or rewritten, data that needs to be migrated, etc. > > > -- > Luigi Cheers, Ben