Re: [Firebird-docs] Test repository CVS to git migration
On 18/10/17 15:15, Mark Rotteveel wrote: Given the normalization done during conversion, that should not be a problem (unless a new file extension is introduced that isn't considered a text file by the configuration of the conversion). The thing I mentioned with autocrlf is the old way of doing things, up to Git 1.6 I think. From then on, .gitattributes is the way to go. However, if a new file type appears, Git will determine whether it is a text file by checking to see if it fails the tests for binary files. There's a good explanation of why it might be best to have both settings at http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
Re: [Firebird-docs] Test repository CVS to git migration
Hi Norman, >> A number of source files in my (Windows) CVS working dir have Unix line >> endings though, whereas their Git counterparts have DOS endings. >> >> That's no problem, as long as it doesn't lead to a huge number of 'changes' >> and log messages when such a file is committed, cluttering the history and >> drowning the real changes. > > This is a documented feature of Git. > > Github has a document about how you can set up your git client to cope > with this. The URL is > https://help.github.com/articles/dealing-with-line-endings/. (...) > So, windows users need: > > $ git config --global core.autocrlf true > > and Linux and Mac users need: > > $ git config --global core.autocrlf input > >> Anyway, I guess that won't occur if we commit all our work to CVS before the >> conversion/transition, get a fresh git clone afterwards and work only from >> that. Am I right? > > In a word, yes. Provided that you configure the Git client before > checking out and definitely before checking in. It's a bit risky to have it depend on the client, i.e. the individual user. But I see now that you can also take care of it in the .gitattributes file, and Mark has alreay done that. Cheers, Paul -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
Re: [Firebird-docs] Test repository CVS to git migration
Afternoon Paul, On 18/10/17 14:08, Paul Vinkenoog wrote: A number of source files in my (Windows) CVS working dir have Unix line endings though, whereas their Git counterparts have DOS endings. That's no problem, as long as it doesn't lead to a huge number of 'changes' and log messages when such a file is committed, cluttering the history and drowning the real changes. This is a documented feature of Git. Github has a document about how you can set up your git client to cope with this. The URL is https://help.github.com/articles/dealing-with-line-endings/. From the online "Pro Git" book, we have this from https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration (scroll down!): core.autocrlf If you’re programming on Windows and working with people who are not (or vice-versa), you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key. Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true – this converts LF endings into CRLF when you check out code: $ git config --global core.autocrlf true If you’re on a Linux or Mac system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input: $ git config --global core.autocrlf input This setup should leave you with CRLF endings in Windows checkouts, but LF endings on Mac and Linux systems and in the repository. If you’re a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to false: $ git config --global core.autocrlf false So, windows users need: $ git config --global core.autocrlf true and Linux and Mac users need: $ git config --global core.autocrlf input Anyway, I guess that won't occur if we commit all our work to CVS before the conversion/transition, get a fresh git clone afterwards and work only from that. Am I right? In a word, yes. Provided that you configure the Git client before checking out and definitely before checking in. Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: 27a Lidget Hill Pudsey West Yorkshire United Kingdom LS28 7LG Company Number: 05132767 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
Re: [Firebird-docs] Test repository CVS to git migration
Mark Rotteveel wrote: > Fixed in https://github.com/mrotteveel/test-firebird-documentation-4 I cloned this repository and built a number of targets, both in master and in the B_Release branch. Everything worked exactly as in my CVS checkout. A number of source files in my (Windows) CVS working dir have Unix line endings though, whereas their Git counterparts have DOS endings. That's no problem, as long as it doesn't lead to a huge number of 'changes' and log messages when such a file is committed, cluttering the history and drowning the real changes. Anyway, I guess that won't occur if we commit all our work to CVS before the conversion/transition, get a fresh git clone afterwards and work only from that. Am I right? Cheers, Paul Vinkenoog -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
Re: [Firebird-docs] Test repository CVS to git migration
Hi Mark, I used your repository for few Tests and further translation. I couldn't find any problems. The Linux scripts are working and no strange behavior when I create the html or pdf outputs. >From my point of view everything is fine and it is much easier to add new >contents (for me). Regards, Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
Re: [Firebird-docs] ATTN committers: SourceForge to terminate CVS support on November 30th
On 18/10/17 02:40, Helen Borrie wrote: >>From my dabblings with your test project yesterday, I think my > problems are with the Git desktop, mostly. I don't like the UI much > at all, although being able to connect from it to the source project > is a nice feature, but not a life saver. When I get clear of the > current crop of alligators, I'll download the Tortoise client app as > the TortoiseCVS and SVN packages always served me adequately. Where I'm having to work with projects that perhaps jumped to git too soon, I'm using TortoiseHg with git-hg. It provides views and navigation tools that I've been used to and gives a common base for CVS and SVN as well as GIT and the native HG which I've been using locally as an alternative to GIT. I don't know about the current GIT UI tools but it was simply not cross platform and complete at the time I was having to live with the change ... In my book GIT may have filled holes in CVS operations, but it also lost key facilities CVS was good at. The resulting project ports are now difficult to work with as a whole where one has dozens of isolated module which on CVS one could create a single view of selected 'sub-repos' :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Firebird-docs mailing list Firebird-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-docs
