Unexpected merge error in a git svn system?

Question

I have a somewhat convoluted setup (as in git svn dcommit committing wrong file?) that looks something like this (produced in Dia, testrepo.dia, posted in this gist) - and i

Answer 1

So, I think I got somewhere - but I'm really not sure if this will work for all edge cases, so an eventual more erudite answer will be appreciated.

First, a note: you can obtain the logs with bash testrepo.sh 2>&1 | tee testrepo_MARK.log; and you can remove the control characters inserted by git remote from the logs with: sed -i 's/\x1b\[\x4b//g' testrepo*.log.

Anyways - apparently when doing git fetch, it adds a so-called local remote-tracking branch, which can be deleted as per How do I delete a Git branch both locally and remotely? (to not add that "local remote-tracking branch", one should apparently call git fetch <remote> --prune instead). But that is not enough if doing a recovery from a broken state; the broken state apparently means there is a record of an unsuccessful merge, that should be removed (for which git rebase --abort can be used, as the program itself recommends). So in short, the fix would be:

cd /tmp/myrepo_gitsvn
git branch --delete --remotes origingit/master
git rebase --abort

Here is a modification of the above script, that will allow for simulating the break and the recovery (just replace the respective parts in the OP script):

# ...
cd /tmp
cat > /tmp/myrepo_git_LS.git/hooks/post-update <<EOF
#!/usr/bin/env bash
export SSHPASS=${SSHPASS}
#export GIT_DIR="."
git update-server-info
export GIT_DIR=".git"
echo "post-update kicking in"
cd /tmp/myrepo_gitsvn
git svn info | grep Rev
git pull --rebase origingit master
git svn info | grep Rev
git log --graph --decorate --pretty=oneline --abbrev-commit --all --date-order
sshpass -e git svn rebase
sshpass -e git svn dcommit
sshpass -e git svn rebase
git log --graph --decorate --pretty=oneline --abbrev-commit --all --date-order
git svn info | grep Rev
EOF
chmod +x /tmp/myrepo_git_LS.git/hooks/post-update

# ...

echo "Simulating svn server back online; git wc commits get added"
mv /tmp/.myrepo_svn_WS /tmp/myrepo_svn_WS

DOCONFLICT=true
if [ "${DOCONFLICT}" = "true" ] ; then
echo "Simulating merge conflict via git fetch"
(cd /tmp/myrepo_gitsvn; git fetch origingit)
fi

echo lll >> folder/file.txt
git add folder/file.txt
git commit -m "5th git commit"
sshpass -e git push origin master

echo mmm >> folder/file.txt
git add folder/file.txt
git commit -m "6th git commit"
sshpass -e git push origin master

DOFIX=true
if [ "${DOCONFLICT}" = "true" ] ; then
if [ "${DOFIX}" = "true" ] ; then
  # https://stackoverflow.com/questions/2003505/delete-a-git-branch-both-locally-and-remotely/23961231#23961231
  (cd /tmp/myrepo_gitsvn;
  git branch --delete --remotes origingit/master;
  git rebase --abort;
  )
fi
fi

echo nnn >> folder/file.txt
git add folder/file.txt
git commit -m "7th git commit"
sshpass -e git push origin master

echo ooo >> folder/file.txt
git add folder/file.txt
git commit -m "8th git commit"
sshpass -e git push origin master

There are a few more commits, to test if the recovery holds; seemingly it does, because for the last commit, now this can be seen in the logs comparison:

... so apart from a slight rearrangement, the log graph looks nearly the same. Also, note that as the added git svn info tells up, every time there is a "rewinding head to replay your work on top of it", git-svn actually brings the repository to commit 5 (which is the last one that was done solely in Subversion, before migrating to git-svn); not sure why this is. And at end, when the compacted log graph is shown after the final commit, all seems to look good:

Well, I hope this will help me get my actual repository fixed ...