Hi, What's the status on this ? What's the opinion of the rest of the dev team ?
Thanks On Sat, Oct 3, 2015 at 1:49 PM, Philippe Mouawad <philippe.moua...@gmail.com > wrote: > Hello, > +1 for me to migrate to GIT. > > I think it's a great way to encourage contributions. > It will also make it easier for us to work on medium to large features as > git merge is really powerful. > > Many Apaches projet are doing it currently and I think we should follow > this movement. > > Regards > Philippe > > On Tue, Aug 25, 2015 at 8:19 PM, Andrey Ponomarev < > andrey.ponoma...@gmail.com> wrote: > >> 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 >> > > > > -- > Cordialement. > Philippe Mouawad. > > > -- Cordialement. Philippe Mouawad.
