From 4f373503f27356e02eea796407509cc10e49d930 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 7 Nov 2013 15:02:11 -0400 Subject: [PATCH] sync: When there are merge conflicts that get automatically resolved, exit nonzero at the end. --- Command/Sync.hs | 2 +- debian/changelog | 2 ++ doc/todo/wishlist:_detection_of_merge_conflicts.mdwn | 10 ++++++++++ 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/Command/Sync.hs b/Command/Sync.hs index a37fcab984..beb1e1a39f 100644 --- a/Command/Sync.hs +++ b/Command/Sync.hs @@ -276,7 +276,7 @@ mergeFrom branch = do return r runmerge a = ifM a ( return True - , resolveMerge + , void resolveMerge >> return False ) {- Resolves a conflicted merge. It's important that any conflicts be diff --git a/debian/changelog b/debian/changelog index 3682cc3b51..6b50b697fa 100644 --- a/debian/changelog +++ b/debian/changelog @@ -11,6 +11,8 @@ git-annex (5.20131102) UNRELEASED; urgency=low "git status" won't work in them. * The -c option now not only modifies the git configuration seen by git-annex, but it is passed along to every git command git-annex runs. + * sync: When there are merge conflicts that get automatically resolved, + exit nonzero at the end. -- Joey Hess Sat, 02 Nov 2013 14:54:36 -0400 diff --git a/doc/todo/wishlist:_detection_of_merge_conflicts.mdwn b/doc/todo/wishlist:_detection_of_merge_conflicts.mdwn index 1824a91ee5..1b4caeff0e 100644 --- a/doc/todo/wishlist:_detection_of_merge_conflicts.mdwn +++ b/doc/todo/wishlist:_detection_of_merge_conflicts.mdwn @@ -1,3 +1,13 @@ A conflict during sync or merge is something that requires user intervention, or at least notification. For that reason it would be nice if git annex returned a nonzero exit status when such a conflict happened during a sync or a merge. This is what git does after a conflicting pull, and would make it easier to spot a conflict in automated syncs without having to parse annex output or the logs. +> Good idea, [[done]]. --[[Joey]] + Also, it would be nice if your new `git annex status` were able to inform about remaining conflicts in the repo, for instance by reporting files with variant-XXX suffix. + +> Hmm, that would need a separate pass through the whole tree, since +> currently it can use `git ls-files` to find only modified/deleted/new +> files. I would rather not make the new `git annex status` slower for +> this. +> +> It would be possible to add it to `git annex info` (old `status`) +> which already has to look through the entire work tree.