From 4c9326dab5d3349583fb0ab120af2f7e33f3a4ca Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 5 Jun 2023 15:00:39 -0400 Subject: [PATCH] reject --- ..._conflict_resolution_to_git_conflicts.mdwn | 2 ++ ..._c08e7f51503f103c447064a01b085783._comment | 19 +++++++++++++++++++ 2 files changed, 21 insertions(+) create mode 100644 doc/todo/Extend_merge_conflict_resolution_to_git_conflicts/comment_1_c08e7f51503f103c447064a01b085783._comment diff --git a/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts.mdwn b/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts.mdwn index 4487ae032b..67e95edaa7 100644 --- a/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts.mdwn +++ b/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts.mdwn @@ -9,3 +9,5 @@ To not confuse users, it could be opt-in (`git annex --set annex.resolvegitmerge On conflict, it would remove the conflicting file and instead create two versions with suffixes either like annexed files or better the commit hash and/or date. Submodule conflicts can't be resolved like this, in that case I would use the most recent commit of the two in question. + +> [[rejected|done]] --[[Joey]] diff --git a/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts/comment_1_c08e7f51503f103c447064a01b085783._comment b/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts/comment_1_c08e7f51503f103c447064a01b085783._comment new file mode 100644 index 0000000000..887b4d7111 --- /dev/null +++ b/doc/todo/Extend_merge_conflict_resolution_to_git_conflicts/comment_1_c08e7f51503f103c447064a01b085783._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2023-06-05T18:49:43Z" + content=""" +I think this would violate least surprise. Users expect git-annex +to behave like git, and that means merge conflicts like git handles them, +when the files are text files tracked by git. + +Consider that, if the file is a config file, applying git-annex's +resolvemerge to it would make 2 files with different names be in the +repository. So the config file would stop taking effect for whatever it was +supposed to configure. It would be easy for the user to miss that, because +the repository would not be left in a conflicted state. + +When you check a file into git rather than git-annex, you are +choosing to have git manage that file normally. If you want the git-annex +behavior, you can check the file into git-annex. +"""]]