git (split from New Engine Please)

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
User avatar
kyle
Reverse Outside Corner Grinder
Posts: 1866
Joined: Thu Jun 08, 2006 3:33 pm
Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
Contact:

git (split from New Engine Please)

Post by kyle »

Z-Man wrote:
Word wrote:Would it speed things up if you do that?
Probably not. How the project is shared is of very little importance. I'd just throw it all into git.
It would be nice to convert our launchpad bazzar to git
Image

User avatar
/dev/null
Shutout Match Winner
Posts: 820
Joined: Sat Sep 04, 2004 6:28 pm
Location: Chicago-ish

Re: New engine please

Post by /dev/null »

kyle wrote:
Z-Man wrote:
Word wrote:Would it speed things up if you do that?
Probably not. How the project is shared is of very little importance. I'd just throw it all into git.
It would be nice to convert our launchpad bazzar to git
WAY TO GO KYLE YOU WOULD POST ON 9/11!

(If you take this seriously I will giggle forever.)

User avatar
kyle
Reverse Outside Corner Grinder
Posts: 1866
Joined: Thu Jun 08, 2006 3:33 pm
Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
Contact:

Re: New engine please

Post by kyle »

what about migrating the SVN on sourceforge (or is that corrupt) to git, and then any subprojects would just have to be reimplemented from their parent?
Image

User avatar
Z-Man
God & Project Admin
Posts: 11424
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: New engine please

Post by Z-Man »

That's another possibility; it has its own downsides. On the upside, we'd get mergeable 0.4 and 0.2.8 with probably full history. How much the move operations Luke-Jr did back then affect things is unknown, but I started the process (aborted it because it took too long) and it did not seem to have fundamental problems with it.
The downsides I know about: It's a one way trip; you can't really sync git back to svn. If you have a change in git, push that to svn and pull it back to git, it has changed signature. So everyone would have to switch to git at once. Again, I would not object to that. But it would affect the foreign branches; bzr 0.2.8 would no longer get updates, so the stys would go stale and would have to somehow migrate to git. I have not investigated whether there may be a clean path for them. Maybe bzr->git conversion and some sledgehammer work gets them into a state where they can pull future changes from git.

So the procedure there would be: Set up a one-way sync from svn to an otherwise readonly git repository, see how that goes, give everyone who cares a bit of time to adapt their private branches to git, and then at some later time disable the syncing, declare bzr and svn dead and have everyone switch.

Tiny problem for us: 0.2.8.3 security updates still need to be built from svn. But those things need heavy manual care that fixes merge correctly anyway, I can use diff and patch to manually haul them over to git just fine.

User avatar
Z-Man
God & Project Admin
Posts: 11424
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: git (split from New Engine Please)

Post by Z-Man »

Right. FOR EXPERIMENTS ONLY, I let the whole process as described in kyle's link run through on my server. Worked like a charm. Results are here:
http://vps-zman.armagetronad.org/~manue ... tronad.git
Clone it with

Code: Select all

git clone http://vps-zman.armagetronad.org/~manuel/git/armagetronad.git armagetronad
Code is then in armagetronad/armagetronad.
This is certainly not something we will keep. The email addresses are wrong because I screwed that bit up, an update is running. (Edit: That bit is done now) It's almost certainly going to change once again, because
Poll: For those who committed directly to SVN, how would you like your name to appear in git should we make the switch? Right now, you're all "user <[email protected]>".

The basic structure of the repository is final, though, at least if I should be our migration manager. Anything but the standard import from svn, keeping its structure, is just going to cause massive headaches. So, for those who don't want to clone the repository to check it out:
It's ALL of our stuff related to the game itself. All branches, all subprojects. So, you'll be getting winlibs whether you need them or not. It's not as bad as it sounds, the revision data is just a tad over 60 Mb.

I don't know whether I'll bother setting up automated updates to current SVN revisions.

The question, of course, is: would there be demand for a switch? I'm generally content with bzr in itself, my gripe is just that we can't merge from 0.2.8 to 0.4 and the corruption on 0.4 I don't know how to repair. And I like the increased flexibility I have when combining bzr braches, that made tasks like building 0.2.8.3 builds for zeroinstall a lot easier.

User avatar
Jip
Round Winner
Posts: 397
Joined: Sat Sep 26, 2009 5:32 pm

Re: git (split from New Engine Please)

Post by Jip »

Z-Man wrote:The question, of course, is: would there be demand for a switch? I'm generally content with bzr in itself, my gripe is just that we can't merge from 0.2.8 to 0.4 and the corruption on 0.4 I don't know how to repair.
I find it much more comfortable to work with git (or with a decentralized version control system in general). I like doing my commits locally first and push everything when things are working.
Z-Man wrote:And I like the increased flexibility I have when combining bzr braches, that made tasks like building 0.2.8.3 builds for zeroinstall a lot easier.
What do you mean exactly with combining? Like resolving dpendencies for external libs? Would git submodules work for that?

User avatar
Z-Man
God & Project Admin
Posts: 11424
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: git (split from New Engine Please)

Post by Z-Man »

Jip wrote:What do you mean exactly with combining? Like resolving dpendencies for external libs? Would git submodules work for that?
Combining outside of the source control. I'd get a clone of the bzr branch 0.2.8-armagetronad-work and 0.2.8-build-work, side by side. Then I can use 0.2.8-build-work to make a release build of 0.2.8-armagetronad-work. So far, so normal; I can do that in git simply in the subdirectory 'build'. But with the bzr branches, I also combined 0.2.8-build-work with ap or ctsty and make builds of that. Or svn checkouts of 0.2.8.3.3. I guess the 'combining' is less the thing I use here, more lightweight checkouts of parts of a project. Natively possible in svn, made possible by our branch structure in bzr.
Of course, that's all basically a 'me' problem :) And I could solve it by putting the build/release stuff in a separate repository.

User avatar
kyle
Reverse Outside Corner Grinder
Posts: 1866
Joined: Thu Jun 08, 2006 3:33 pm
Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
Contact:

Re: git (split from New Engine Please)

Post by kyle »

Yes, you could fork it for those :P, and then set 2 remote "origins" to merge in stuff as needed from the main origin. That's how i would intend on having sty+ct set up, In theory it should work anyway. I was thinking you could use this git repository on launchpad, then you could still sync with the svn on sourceforge? But before you do anything too major, I'd like to see if it is simple to fix the broken branch. since that would be much cleaner for the current forks

EDIT: also need a .gitignore
Image

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: git (split from New Engine Please)

Post by Lucifer »

I don't know anything about git except that it's a different program that soves the same problems bzr solves.

To ake the migration, I'd need a lot more than "it's more comfortable to me" or "I like it better". I need real reasons besides "it's better than bzr." There are a lot of ways at looking at things, so I need solid facts that show that git is better for what we do than bzr.

In much the same way that you, Z-man, needed solid facts that showed that bzr was better than svn. There will be a cost to it that we don't know about right now (same as with the svn to bzr change), and we need something that will show that the cost is worth spending because the benefit we get is so awesome.

My current understanding of git vs bzr is that they're so similar and they solve all the same problems in such a way that there's likely no cost that's worth absorbing. If you're already on bzr, there's no point moving to git, and vice versa.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

User avatar
sinewav
Graphic Artist
Posts: 6333
Joined: Wed Jan 23, 2008 3:37 am
Contact:

Re: git (split from New Engine Please)

Post by sinewav »

A couple years ago I watched Linus Torvolds give a Google Talk on GIT and thought it was really interesting.

User avatar
Z-Man
God & Project Admin
Posts: 11424
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: git (split from New Engine Please)

Post by Z-Man »

Well, I'm not the right person to convince Lucifer. I'm not sold on it myself. "I would not object" is really as far as my enthusiasm goes :) Here is my score breakdown:
+ git: has 'git rebase'. 'bzr rebase' was killed.
+ git: faster.
- git: bzr uses less disk space.
+ git: multiple branches in one working directory (repository) allow more workflows.
- git: that makes the interface for common operations more complicated and it's harder to know what the actual state of your working directory is.
- git: does not properly track file renames
+ git: isn't anal about merging two commits that add the same file and can track content moves from file to file. That bzr assigns each file a unique ID is what prevents merges from 0.2.8 to 0.4.
+ git: merges seem to make more sense.

User avatar
kyle
Reverse Outside Corner Grinder
Posts: 1866
Joined: Thu Jun 08, 2006 3:33 pm
Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
Contact:

Re: git (split from New Engine Please)

Post by kyle »

I pretty much so agree with what z-man said except, this one
Z-Man wrote:- git: does not properly track file renames
Still maybe annoying, but I believe it tracks it properly is you use git mv
then I addition from what I have used it for
+git, cherrypick merging a little more sane and user friendly
+git staging files to commit (You can save your debug statements or partially implemented code for a latter commit)
-git, learning curve for complexities
+/-git a few different GUI's can help with the more complex features
Image

User avatar
compguygene
Adjust Outside Corner Grinder
Posts: 2337
Joined: Thu Aug 21, 2008 12:09 pm
Location: Cleveland, Ohio
Contact:

Re: git (split from New Engine Please)

Post by compguygene »

I was curious to see what a google search would yield up comparing the two CVS systems and came up with these two intriguiging articles.

bzr is dying; Emacs needs to move

and

BAZAAR-NG: 7 YEARS OF HACKING ON A DISTRIBUTED VERSION CONTROL SYSTEM

Both of these articles are stating that bzr has had very little development since 2013.
< ddaa> There are two kinds of dscms... the obsolete ones and the experimental ones
Both articles are also pointing out that at this time most of the big open source projects have moved to git. But, the biggest thing that I see as an advantage to consider is this:
In practice, I judge that sticking with bzr would have social and
signaling effects damaging to Emacs's prospects. Sticking to a
moribund version-control system will compound and exacerbate the
project's difficulty in attracting new talent.

The uncomfortable truth is that many younger hackers already think
Emacs is a dinosaur - difficult, bulky, armor-plated, and generally
stuck in the last century. If we're going to fight off that image, we
cannot afford to make or adhere to choices that further cast the
project as crusty, insular, and backward-looking.

As of right about now, continuing with bzr is such a choice. We'll
lose potential recruits, not merely because bzr has a learning cost
but because crusty, insular, etc. The opportunity cost of not getting
out will only rise with time.

git won the mindshare war. I regret this - I would have preferred
Mercurial, but it too is not looking real healthy these days. I have
made my peace with git's victory and switched. I urge the Emacs
project to do likewise.
To me, if git is going to make it more likely that we can attract new talent to contribute to the project, that is huge.
Armagetron: It's a video game that people should just play and enjoy :)
https://bit.ly/2KBGYjvCheck out the simple site about TheServerPharm

User avatar
kyle
Reverse Outside Corner Grinder
Posts: 1866
Joined: Thu Jun 08, 2006 3:33 pm
Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
Contact:

Re: git (split from New Engine Please)

Post by kyle »

compguygene wrote:To me, if git is going to make it more likely that we can attract new talent to contribute to the project, that is huge.
Git alone may not, moving off of sourceforge to github, most likely will, but small steps :) Most projects have left soruceforge because it's become an adware distributor, I think they have reverted some of this, but the damage was already done.
Image

User avatar
Z-Man
God & Project Admin
Posts: 11424
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: git (split from New Engine Please)

Post by Z-Man »

kyle wrote:I pretty much so agree with what z-man said except, this one
Z-Man wrote:- git: does not properly track file renames
Still maybe annoying, but I believe it tracks it properly is you use git mv
Ah? Ok!
kyle wrote:+git, cherrypick merging a little more sane and user friendly
A little more sane may not be quite enough :) They don't track the revisions that were merged. Of course, with git's lenient merges, that does not matter much.

compguygene: Yeah, those reports of emacs switching were what triggered my investigation.
kyle wrote:Most projects have left soruceforge because it's become an adware distributor, I think they have reverted some of this, but the damage was already done.
We're essentially only using sf for downloads; but that may actually be our biggest legacy system problem. The adblocker I use here COMPLETELY blocks sourceforge by default.

I managed to repair our broken 0.4 branch! The defect is only in one revision on the mainline. Here are the commands:

Code: Select all

# fetch 0.4
bzr branch lp:armagetronad/0.4 || exit

# branch last good revision
bzr branch 0.4 0.4_stitched -r 795 || exit

# stitch merge: merge broken revision, but just the content.
pushd 0.4_stitched || exit
bzr merge ../0.4 -r 796 || exit
# forget merge details
bzr revert --forget-merges || exit
bzr commit -m "Re-doing merge of utf8 branch, forgetting about broken details"

# export the history up to that point, storing marks
bzr fast-export --export-marks=../marks > ../0.4_stitched.bzr || exit

# switch to full branch
popd || exit
pushd 0.4 || exit

# export rest of history, taking care not to recycle old marks
bzr fast-export --import-marks=../marks -r 796.. >> ../0.4_stitched.bzr || exit

# create import
popd || exit
mkdir import || exit
pushd import || exit
bzr fast-import ../0.4_stitched.bzr || exit
popd
I'm not publishing the results because... problems:
1. The result is not merge compatible with 0.4.
2. The result is not sync-compatible with svn.
3. The result is still not merge-compatible with 0.2.8.
1 and 2 were to be expected, the history is broken. I looked everywhere for the missing data and could not find it, so we will have to rewrite history, and that goes with breaking merges. So we need to fix 3. It's of course possible to mash 0.2.8 and 0.4 together, but the history from 0.4 then only exists for historic value and has no practical application. I'll experiment a bit more with fastimport.
On the plus side, it should be possible to continuously pull progress from the broken 0.4 branch into the so-fixed branch. So we would not automatically lose our 0.2.8 to 0.4 merge path, it just gets two steps more complicated. bzr 0.2.8 -> 0.2.8 svn -> 0.4 svn -> 0.4 bzr (corrupt) -> 0.4 bzr (fixed) -> 0.4 (what we work with). No, I don't like it either. Or, of course, we could try importing both 0.2.8 bzr and fixed 0.4 bzr into git and then use the two-way git sync to merge.

Post Reply