On Tue, Aug 25, 2015 at 6:21 PM, sebb <seb...@gmail.com> wrote: > On 25 August 2015 at 17:06, Andrey Ponomarev <andrey.ponoma...@gmail.com> > wrote: > > 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. > > No, that's only one aspect of the issue. > Some files use the revision number of the file they are compiled from > in their code. > As I already wrote, the file can contain the string @revision and this > will be replaced by > the revision number on checkout. > This number is used for test checks and for info in output files. >
I think I got it finally. You must be talking about $Revision$ in source files. Then yes, you are right, git don't modify source code before commit. There a few possible workarounds come into my mind: - write an ant task that will insert/replace the hash; - write git checkout/commit hooks that will replace the value. None of this workarounds is as good as SVN feature. On the other hand, the use of @version in javadocs is questionable. First, the full hash in every source file will look really ugly. Secondly, developer always knows the revision s/he is working with. > > 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? > > No, see above. > > > > > > >> 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 > > Again, that's not as flexible as SVN. > As I recall, not all files with the same extension need the same EOL. > So the property needs to be attached to the file, not in a separate text > file. > You can specify exact file name. It's not that flexible as SVN, I agree. If you rename the file, you may forget to update .gitattributes On the other hand the information about EOL is kept in source code instead of version control. I find it beneficial. /Andrey
