git clone https://git-wip-us.apache.org/repos/asf/isis.git
the git.apache.org is meant to be a read-only copy, but I think infra haven't quite got the commit hooks sorted out yet. On 4 December 2012 23:22, Alexander Krasnukhin <[email protected]>wrote: > You did it the right way. Nothing to add. > > Btw, what is the current git repo? > > The one specified on http://isis.apache.org/download.html doesn't work: > > $ git clone https://git.apache.org/isis.git > Cloning into 'isis'... > error: Failed connect to git.apache.org:443; Operation now in progress > while accessing > https://git.apache.org/isis.git/info/refs?service=git-upload-pack > fatal: HTTP request failed > > This one works: > $ git clone git://git.apache.org/isis.git > > But has only svn commits as I can see: > > $ git show -s trunk > commit 73178db96b8f9371bc55cd0ee8d9c1f466d987b4 > Author: Daniel Keir Haywood <[email protected]> > Date: Thu Nov 29 16:36:51 2012 +0000 > > ISIS-188: fixing up supplemental-models for missing license info > > git-svn-id: > > https://svn.apache.org/repos/asf/isis/trunk@141526213f79535-47bb-0310-9956-ffa450edef68 > > Am I missing something? > > > On Wed, Dec 5, 2012 at 12:08 AM, Dan Haywood > <[email protected]>wrote: > > > Hi Alexander, > > > > Yeah, I've done that. I actually found two different ways to do it. The > > first [1] was: > > > > $ rm .git/index # Remove the index to force git to > > $ git reset # re-scan the working directory > > $ git status # Show files that will be normalized > > $ git add -u > > > > Which found a bunch, so I committed locally. > > > > Then I found [2]: > > > > $ git rm --cached -r . > > git reset --hard > > git add . > > > > This took longer to run, but - gratifyingly - it found no files changed. > > > > Let me know if there's something I haven't done that should've. > > > > Cheers > > Dan > > > > [1] > > > > > http://christoph.ruegg.name/blog/2011/7/30/cleaning-up-after-migrating-from-hg-to-git.html > > [2] https://help.github.com/articles/dealing-with-line-endings > > > > > > On 4 December 2012 22:56, Alexander Krasnukhin <[email protected] > > >wrote: > > > > > Have you normalized the whole repo first? If you still have some files > in > > > CRLF style or even with mixed CRLF & LF style you will have some fun > with > > > them later. Nothing crucial but sometimes *very* confusing. > > > > > > > > > On Tue, Dec 4, 2012 at 11:36 PM, Dan Haywood > > > <[email protected]>wrote: > > > > > > > All, > > > > > > > > just an fyi, I've just pushed a commit so that our line endings are > > > > normalized to unix-style LF in the git repo. > > > > > > > > For those who use Windows, git can be configured to automatically > > convert > > > > LF to Windows-style CRLF on checkout, and back again to LF on > checkin. > > > > > > > > This is traditionally done by running the "git config core.autocrlf > > auto" > > > > command (as documented on our site [1]), and it certainly doesn't > harm > > to > > > > run that command. However, I've also checked in a .gitattributes > file > > > that > > > > takes precedence over this config setting. The file specifies what > > > should > > > > be considered as text (eg .java, .xml) and what as binary (eg .png). > > > It's > > > > worth being aware of this file and adding in entries for new file > > binary > > > > types. > > > > > > > > Thx > > > > Dan > > > > > > > > [1] http://isis.apache.org/contributors/using-git.html > > > > > > > > > > > > > > > > -- > > > Regards, > > > Alexander > > > > > > > > > -- > Regards, > Alexander >
