> On 2018-03-15, at 11:37, Marko Mäkelä <msmakela@gmail.com> wrote: > > On Thu, Mar 15, 2018 at 09:52:42AM +0000, smf wrote: >> The last time I looked github doesn't allow you to follow renames when looking at history on their web interface, it's also limited in terms of number of files it will show you in a directory. We've just sucked it up for the moment and haven't looked at switching, the others might suffer the same problem. > > I believe that this is an inherent limitation of the git repository format. True. > My understanding is that unlike bzr and svn, git does not really track renames. True. > I guess I should convert my svn repositories to git and upload to GitHub. I already have a work-related account there. The point that each checked out copy of the repository is a full backup of the history is very valid That's why it is not called "checkout" but rather "clone", therefore proper statement would read "every cloned copy of the repository [...]". "Checkout" means something somewhat different in git terminology. > , and works like an insurance if the free-as-in-beer service of the closed-source GitHub goes away. For a good example. > I should also find out if there are any usable svn-to-git gateways. I would prefer to keep my own repositories in svn fsfs format, because it is very rsync-friendly for making backups: each commit is 2 new files with understandable names (svn revision is the number of commits since the start). The git repository format with lots of files named by some hash values is totally opaque to me. It is definitely possible. For example Spiro here is also involved with cc65, where a big transition from SVN to git has taken place some time ago. To my understanding he participated in the process. -- SD!Received on 2018-03-15 12:04:29
Archive generated by hypermail 2.2.0.