mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

reject

Browse source
This commit is contained in:
Joey Hess 2023-06-05 15:00:39 -04:00
parent 07db8e234a
commit 4c9326dab5
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 21 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/todo/Extend_merge_conflict_resolution_to_git_conflicts.mdwn
View file

@ -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]]

19
doc/todo/Extend_merge_conflict_resolution_to_git_conflicts/comment_1_c08e7f51503f103c447064a01b085783._comment Normal file
View file

@ -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.
"""]]