comment and close
This commit is contained in:
parent
26511c3166
commit
e701f69ac4
2 changed files with 29 additions and 0 deletions
|
@ -1 +1,3 @@
|
|||
Small files might also be used for performance reasons, so there should be an option to also automatically fix merge conflicts for small files in git-annex-sync.
|
||||
|
||||
> [[wontfix|done]] --[[Joey]]
|
||||
|
|
|
@ -0,0 +1,27 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2021-06-23T16:43:34Z"
|
||||
content="""
|
||||
There's a reason people don't want git to automatically resolve merge
|
||||
conflicts of code, and for all git-annex knows small files are code.
|
||||
|
||||
Or looking at it from the other perspective, non-technical git-annex
|
||||
assistant users need an automatic merge conflict resolution of annexed
|
||||
files, since the assistant commits changes to those files and otherwise
|
||||
they could end up with a conflict they don't understand how to resolve.
|
||||
|
||||
And, git-annex sync inherited that from the assistant. Which may or may not
|
||||
have been the best decision. One thing in favor of it being a reasonable
|
||||
decision is that a conflict in an annexed file will mostly be resolved by
|
||||
picking one version of the file or the other, unlike conflicts in source
|
||||
code which are often resolved by using brain sweat. Large and often binary
|
||||
files not being very possible for human brains to deal with directly. Or
|
||||
perhaps by a tool that combines the two versions in some way, in which case
|
||||
the conflict resolution leaves both versions easily accessible for such a
|
||||
tool.
|
||||
|
||||
So git-annex does know, or can make some reasonable assumptions, about
|
||||
annexed files, but generalizing those assumptions to small files would not
|
||||
make sense.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue