Use Git version control on Launchpad
#1
Posted 26 November 2015 - 01:36 PM
Blueprint: https://blueprints.l...it-on-launchpad
I think it's high time we kicked off the discussion about using distributed version control, and it seems Launchpad's support for Git is now good enough for us to start doing that. Because of the nature of distributed version control, we can have a "mirror" of the code repository on e.g. GitHub if people want, but I don't want to split the bug/feature tracking into multiple places so Launchpad will continue to be the only place to report bugs/log features.
#2
Posted 27 November 2015 - 08:04 AM
#3
Posted 27 November 2015 - 02:07 PM
#4
Posted 28 November 2015 - 03:46 AM
So, please forgive me if I am not immediately jumping and dancing for joy at the idea of this switch. But who am I to keep you from your holy grail?
Just a word of warning, though. When I first joined OR I was told to submit code in SVN - like that, without any further information as to how or what. So I did - and made mistakes, and even if I did not make mistakes I did not do it the way I was supposed to. It took some time to find out what that way actually was.
So, if you want this change to go smoothly, my advice is to provide very clear and short guidelines on what to do - half a page of single-line steps should do the trick, one set for developers, one for users. Don't just send us a link to the documentation - that usually starts with a lot of giberish on how good and easy the tool is, and then gives you 784 alternatives for just the first command. And anyway, documentation is for dummies - we, the experts, can do things by intuition, we don't need a manual. Until the whole thing collapses right in front of our eyes - but that's not our fault, just shabby software.
Half a page of clear rules might just tempt us to read it. Otherwise, you could well be surprised (and not pleasantly) by the daft errors people can make. Don't think the software will prevent such errors. I spend my working live in the software test department, our job was to show that software did not meet its requirements, including protection against incorrect input. We rarely failed.
Just remember Murphy.
Regards,
Rob Roeterdink
#5
Posted 28 November 2015 - 04:23 AM
roeter, on 28 November 2015 - 03:46 AM, said:
That's understandable; one of the key things we can enable by using distributed version control is anyone can publish their changes without much effort (certainly compared to Subversion). A bit like branches in Subversion could be, but aren't due to access controls and in our case a weirdly set up Subversion server. That's another thing we can remove - the weirdness of our Subversion server set-up and the delays in adjusting access controls due to having to go via a 3rd party.
This means that, for example, both you and I can publish our own experiments, changes and improvements on our own terms - with or without any intention of them going in to the main OR program. And if they do want to go in to the main OR program, merging them in is easier to do because this is actually supported by Git (rather than just a .patch file and praying it works).
roeter, on 28 November 2015 - 03:46 AM, said:
Don't worry, I've experience teaching Git to people at work and I am more than aware of the need for a good intro - the documentation for Git can be terrifying, but there is a good alternative, the Git Book, which is definitely recommended reading and I'll produce an intro that includes how the Git commands relate to Subversion, and obviously answer any questions.
#6
Posted 30 November 2015 - 12:07 AM
It came about after the main Linux devloper Linus Torvadis (the guy the originally wrote the Linux kenel and still looks after it) changed its version control system to a commercial product. As Linux is all open source, this created a real serious howl of protest. After a long and _________VERY___________ heated debate, Git was produced and as there is a number of major LInux kernel developers each with his own version of the kernel support for such things was included from the beginning.
For info on Git see,https://git-scm.com/about
Lindsay
#7
Posted 30 November 2015 - 12:28 AM
#8
Posted 30 November 2015 - 01:06 AM
I would just let you know, that the .gitattributes line
* text=auto
causes all sort of problems for me, both with my long standing own git OR repository, and with a fresh clone of your https://git.launchpad.net/~twpol/or one. I have to comment this line out, otherwise git recognizes many files as modified, that were not; these files cannot be committed, because at commit time git filters them out as unmodified ones, but afterwards they are still listed as modified; rebasing a branch onto other doesn't work because of this, since git denies doing that with existing working tree modifications, but these mods are false positive, no stashing or committing is possible. Etc... No matter how I set autocrlf option, I couldn't find a working configuration other than commenting this line out.
#9
Posted 30 November 2015 - 02:12 AM
gpz, on 30 November 2015 - 01:06 AM, said:
* text=auto
causes all sort of problems for me, both with my long standing own git OR repository, and with a fresh clone of your https://git.launchpad.net/~twpol/or one.
Yes, this is a problem with the git-svn plugin, which puts everything in to Git exactly as it is in Subversion, which means you have your repository full of CRLF even though Git prefers just LF. The .gitattributes files are going to be great when we actually convert the repository properly instead of using the plugin though. For now, the way you use the git-svn repositories is to put "* -text" in to .git\info\attributes which overrides .gitattributes.