diff options
| -rw-r--r-- | doc/bugs/Assistant_merge_loop/comment_2_afcbf3f8575e1a967c79693b94ef055c._comment | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/doc/bugs/Assistant_merge_loop/comment_2_afcbf3f8575e1a967c79693b94ef055c._comment b/doc/bugs/Assistant_merge_loop/comment_2_afcbf3f8575e1a967c79693b94ef055c._comment new file mode 100644 index 000000000..eb3deb2ee --- /dev/null +++ b/doc/bugs/Assistant_merge_loop/comment_2_afcbf3f8575e1a967c79693b94ef055c._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.55" + subject="comment 2" + date="2014-07-05T21:17:17Z" + content=""" +Well, it looks like this is as simple as the assistant trying to merge refs/remotes/$foo/synced/master into the current branch, when that ref is behind or the same as the current branch. Nothing to merge, so it does some pointless work and then the fastForwardable check runs -- and that check looks for refs between the \"old\" and \"new\" refs. Since the \"new\" is behind the \"old\", there are no such commits, and the unnecessary empty commit results. + +The reason only the assistant is affected is because `git-annex sync` already checked Git.Branch.changed before trying to do any merging, which avoids the problem. + +Fix committed. +"""]] |