On Tue, Aug 25, 2015 at 4:25 PM, sebb <seb...@gmail.com> wrote: > > >> However there are areas of the build and testing that rely on being > >> able to access the revision number of a file. > >> That is impossible in Git as far as I know. > >> > > > > Git has commit hashes. They play the same role as revision numbers in SVN > > One can checkout the whole commit or an individual file of any commit if > > needed. > > That is not what I meant. > The code and build file use the current revision of the file, e.g. > @revision. > This is automatically updated when a file is checked out. >
I've looked into build.xml and found svn.revision property. If this is what you mean, then I don't see any difference in using commit hash instead. The hash is obviously longer than svn revision number. Though first few characters are enough for git, so you don't need to type the whole hash. You can use "exec" task for calling "git rev-parse HEAD". That will return the current revision (hash). Is it what you mean? > So how do you configure some files as native, some as CRLF and some as LF? > This is trivial in SVN, and the settings stay with the file. > Create a file called ".gitattributes" in the project root. In this file you can specify attributes for files, including line endings. Here is modified example from github article "Dealing with line endings": # Set the default behavior, in case people don't have core.autocrlf set. * text=auto # Explicitly declare text files you want to always be normalized and converted # to native line endings on checkout. *.java text # Declare files that will always have CRLF line endings on checkout. *.cmd text eol=crlf *.bat text eol=crlf # Declare files that will always have LF line endings on checkout. *.sh eol=lf # Denote all files that are truly binary and should not be modified. *.png binary *.jpg binary /Andrey
