On 17 October 2015 at 14:37, Philippe Mouawad <[email protected]> wrote: > Hi, > What's the status on this ?
There are some missing features in Git for which no alternatives have been provided. > What's the opinion of the rest of the dev team ? > > Thanks > > > On Sat, Oct 3, 2015 at 1:49 PM, Philippe Mouawad <[email protected] >> 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 < >> [email protected]> wrote: >> >>> On Tue, Aug 25, 2015 at 6:21 PM, sebb <[email protected]> wrote: >>> >>> > On 25 August 2015 at 17:06, Andrey Ponomarev < >>> [email protected]> >>> > wrote: >>> > > On Tue, Aug 25, 2015 at 4:25 PM, sebb <[email protected]> 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.
