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
God & Project Admin
Posts: 11427
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne

Re: git and broken 0.4 bzr branch

Post by Z-Man »

Success! Almost. New script:

Code: Select all

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

# get first revision
bzr branch 0.4 0.4_first -r 1 || exit
rm -rf 0.4_first/.bzr -rf || exit

# prepare shared repository
mkdir import || exit
pushd import || exit
bzr init-repo . || exit

# fetch 0.2.8 into repository so all its revisions are prepared
bzr branch lp:armagetronad/0.2.8 || exit
mv 0.2.8 0.2.8_raw || exit
mkdir 0.2.8 || exit
pushd 0.2.8 || exit

# reproduce the state at the start of 0.4
cp -ax ../0.2.8_raw/.bzr . || exit
cp -ax ../../0.4_first/. . || exit
bzr add || exit
#bzr status
bzr commit -m "First merge from 0.4" || exit

# export
bzr fast-export --export-marks=../../marks_0.2.8 > ../../ || exit

# fake previous aborted fastimport that produced precisely the good 0.2.8 branch
sed -e s,^:,, < ../../marks_0.2.8 > ../.bzr/repository/fastimport-id-map 

# back to root
popd || exit
popd || exit
cp marks_0.2.8 marks

# 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 -r 2.. --marks=../marks > ../ || 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.. >> ../ || exit

# create import
popd || exit

# merge imports
cat >

pushd import || exit
bzr fast-import ../ || exit
Result: ... ad-unified
Compiles almost fine, the build just complains about a missing configuration file.
The basic idea here is that bzr-fastimport is tricked into recreating the history 0.2.8 exactly; this is done by writing the file import/.bzr/repository/fastimport-id-map . In that file, bzr-fastimport usually stores which revision number from the fastimport file corresponds to which revision ID in the shared repository after it imports them. The intention is that you can redo a fastimport and get the same result as before, and faster than a full reimport.
Well, and bzr-fastexport supports storing a very similar mat of revision numbers to revision ids for the purpose of mashing unrelated exports together. We just take that, convert it and plug it into the other thing.

The history of the full branch consists of three sections and two stitching commits:
First, the exact copy of 0.2.8's history. Goes from 1 to 1452 in this first attempt.
Then, revision 1523 crudely overwrites the last state of 0.2.8 with the initial state of 0.4. The ugly bit is that this state is from an earlier time and removes features and bugfixes.
From there to revision 2246, it follows the history of 0.4 until the broken bit.
Revision 2247 is the broken merge, redone as flat merge.
The rest is then the rest of 0.4's history.

As before, merging with regular 0.4 and svn won't work. But now at least technically, merging from 0.2.8 works. I write 'technically' because the reverting back to the start of 0.4 and then replaying all the changes, including merges from 0.2.8, means that many changes from 0.2.8 happen in this branch, get undone and then happen again. This is bound to cause conflicts if the same changed code lines change again. Maybe it helps if we hide away (not destroy) all of 0.4's history with a collapsing merge:

Code: Select all

bzr pull -r 1452 --overwrite
bzr merge
bzr commit -m "merge from 0.4"
I did a small test, changing a line I recently changed on 0.4, and it did not make a difference, there were no conflicts either way.

Import to git should work smoothly from there.

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

Re: git (split from New Engine Please)

Post by Jip »

Well done!

User avatar
Match Winner
Posts: 593
Joined: Wed Oct 22, 2014 10:22 pm

Re: git

Post by aP|Nelg » ... -recommend

Additional information:
"Choosing the system to use highly depends on what the project is in itself.
There are a ton of comparisons online, but one key thing to note is that GIT is offering IDE integration and continues to update, leaving the rest in the dust."

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

Re: git (split from New Engine Please)

Post by /dev/null »

well arent you mr fancy pants.

Also thank you.

Gentoo integrates far better than git.

Post Reply