sync: Avoid an ugly error message when nothing has been committed to master yet and there is a synced master branch to merge from

Now the warning gets displayed, which is better than an arcane git error.

The warning is still kind of ugly, especially when the pull later in the
sync will clear up what it warns about. But, this is an unusual situation
not likely to happen, and if there is no remote to pull from, the warning
message is needed or the sync will seem to succeed despite not merging the
synced master branch.

Would still be better if it could merge the synced master branch in this
situation, making an empty commit to master to do it seems wrong, and
otherwise it would need a whole separate code path, and would bypass using
git merge in favor of say, setting master to the syned branch. Which would
bypass git configs like arguably merge.ff and certianly
merge.verifySignatures. So don't want to do that.

doc/bugs/git_config_merge.ff__61__only_breaks_sync.mdwn

@@ -445,3 +445,6 @@ fatal: Not possible to fast-forward, aborting.
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 Sure! Using git-annex to keep artifacts in development repos works great usually :)
+
+> Closing as I don't think this behavior is actually a bug. [[done]]
+> --[[Joey]]

doc/bugs/git_config_merge.ff__61__only_breaks_sync/comment_3_3f78dd62e99f55388e415a2e2fb86a3f._comment

@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-05-05T17:05:32Z"
+ content="""
+The sync man page does mention fetching and merging:
+
+	The sync process involves first committing any local changes to files
+	that have previously been added to the repository,
+	then fetching and merging the current branch
+
+Not that I really buy the argument that not mentioning use of some specific git
+command means that it should bypass git configurations that apply to that
+command. git commands often don't document other git commands that they use
+as plumbing, for example.
+
+The output with this configuration is essentially:
+
+	pull repo-b
+	fatal: Not possible to fast-forward, aborting.
+	failed
+
+So the user is told right there that sync tried to pull.
+And the pull failed. Why? Something to do with fast-forward. While this would
+be clearer if git mentioned the config that is making it require a fast-forward,
+it does not seem an indecipherable behavior.
+
+And also, you have to have *globally* configured an option that prevents fast forwarding.
+That is a major, massive change to git's behavior. git is going to be falling over on
+pull all the time in many circumstances with the same error message.
+
+Similarly, if you had configured merge.verifySignatures globally, git-annex
+sync would be likely to fail. All your arguments would seem to require I also
+override that option. But that could be a big security hole.
+"""]]

doc/bugs/git_config_merge.ff__61__only_breaks_sync/comment_4_1b7133c5915baabb3076e95f0ac9807a._comment

@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-05-05T17:27:31Z"
+ content="""
+As to the "fatal: ambiguous argument" message, it happens in the same test
+case w/o that global git config.
+
+	[2020-05-05 13:28:27.204706608] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/heads/synced/master","--pretty=%H","-n1"]
+	fatal: ambiguous argument 'refs/heads/master..refs/heads/synced/master': unknown revision or path not in the working tree.
+
+It's caused by sync being run with no master branch yet, and nothing to commit
+to create one. refs/heads/synced/master does exist; it was synced from the
+other repo. Fixed that message.
+"""]]