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

rethink and Q

Browse source
This commit is contained in:
Joey Hess 2018-08-09 13:06:25 -04:00
parent 78ade9e6cf
commit 42fcf59921
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 34 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

45
doc/bugs/cannot_commit___34__annex_add__34__ed_modified_file_which_switched_its_largefile_status_to_be_committed_to_git_now/comment_3_92b71940fe9d00bf58ee08b327f4a991._comment
View file

@ -14,17 +14,40 @@ to tell that this file is not supposed to be treated as an unlocked file.
I don't think we want `git annex add` to commit the file. That would be I don't think we want `git annex add` to commit the file. That would be
very surprising behavior! very surprising behavior!
Instead, let's improve the pre-commit hook. It What git-annex could do is have the pre-commit hook notice that the file
currently looks for typechanged files and adds them as annexed files. doesn't match annex.largefiles and not re-annex it, allowing the typechange to
Why not make it check annex.largefiles? All it has to do is, if the file get committed to git. Then the user would only need to unlock the file,
doesn't match annex.largefiles, leave it typechanged. Git will then commit modify it to make it non-large, and commit it to get it checked into git.
its contents to git.
With that, all the user has to do is unlock the file, modify it to make it In a way, this is *too* easy, because if the user sees that working, they may
small, and commit, and it will automatically be converted to an in-git file. expect to be able to turn a small file back into an annexed file by
making the content large and running git commit on it w/o git-annex add.
Which would be bad because that would commit a large file to git.
I suppose the pre-commit could handle that too, but imagine that replacing
eg a `configure` script that's expected to be shipped in the git repository
with an annex symlink, which would be surprising.
(Since the pre-commit hook has that partial commit blocking So it may be better to keep the conversion from annexed to in-git file
when there are typechanged files, that will need to be changed to and back explicit. This could be done by `git annex add` detecting
not block partial commits when none of typechanged files match this situation and erroring out with a message that suggests running
annex.largefiles.) `git commit -n` if the user wants to change the annexed file to a in-git
file. That bypasses the pre-commit hook, so the typechange gets committed
to git as they desire.
Which is better, the implicit conversion of the explicit? I am not
sure, but lean toward the explicit since it doesn't have this potential
to confuse users.
The explicit paths would be:
# annex to git # git to annex
git annex unlock file
largen file smallen file
git add file git annex add file
git commit -n git commit
Seems worth documenting somewhere. Or making a command that handles these
conversions, but the largen and smallen steps being manual, and the
possibility to combine multiple of these into a single commit argues
against a conversion command.
"""]] """]]