unannex: Commit staged changes at end
to avoid some confusing behavior with the pre-commit hook, which would see some types of commits after an unannex as checking in of an unlocked file.
This commit is contained in:
parent
9aecf4110a
commit
c77ac11acc
5 changed files with 23 additions and 6 deletions
|
@ -55,5 +55,10 @@ cleanup file key = do
|
|||
|
||||
fromAnnex key file
|
||||
logStatus key ValueMissing
|
||||
|
||||
|
||||
-- Commit staged changes at end to avoid confusing the
|
||||
-- pre-commit hook if this file is later added back to
|
||||
-- git as a normal, non-annexed file.
|
||||
Annex.queue "commit" ["-m", "content removed from git annex"] "--"
|
||||
|
||||
return True
|
||||
|
|
3
debian/changelog
vendored
3
debian/changelog
vendored
|
@ -3,6 +3,9 @@ git-annex (0.20) UNRELEASED; urgency=low
|
|||
* Preserve specified file ordering when instructed to act on multiple
|
||||
files or directories. For example, "git annex get a b" will now always
|
||||
get "a" before "b". Previously it could operate in either order.
|
||||
* unannex: Commit staged changes at end, to avoid some confusing behavior
|
||||
with the pre-commit hook, which would see some types of commits after
|
||||
an unannex as checking in of an unlocked file.
|
||||
|
||||
-- Joey Hess <joeyh@debian.org> Mon, 31 Jan 2011 20:06:02 -0400
|
||||
|
||||
|
|
|
@ -11,3 +11,5 @@ and has been re-added as a normal file, vs an unlocked file? --[[Joey||
|
|||
> Hmm, not really. An unannexed file's content will have been dropped from
|
||||
> the backend, but that's about the only difference. Perhaps unannex should
|
||||
> just commit the removal of the file itself? --[[Joey]]
|
||||
|
||||
> [[done]], staged changes committed at end.
|
||||
|
|
|
@ -8,5 +8,9 @@ Sorry for all the followups, but I see now that if you unannex, then add the fil
|
|||
|
||||
This seems to be a bug. git-annex's hook thinks that you have used git annex unlock (or \"git annex edit\") on the file and are now committing a changed version, and the right thing to do there is to add the new content to the annex and update the symlink accordingly. I'll track this bug over at [[bugs/unannex_vs_unlock_hook_confusion]].
|
||||
|
||||
So, committing after unannex, and before checking the file into git in the usual way, is a workaround.
|
||||
So, committing after unannex, and before checking the file into git in the
|
||||
usual way, is a workaround. But only if you do a "git commit" to commit
|
||||
staged changes.
|
||||
|
||||
Anyway, this confusing point is fixed in git now!
|
||||
"""]]
|
||||
|
|
|
@ -156,10 +156,13 @@ Many git-annex commands will stage changes for later `git commit` by you.
|
|||
|
||||
* unannex [path ...]
|
||||
|
||||
Use this to undo an accidental add command. This is not the command you
|
||||
should use if you intentionally annexed a file and don't want its contents
|
||||
any more. In that case you should use `git annex drop` instead, and you
|
||||
can also `git rm` the file.
|
||||
Use this to undo an accidental `git annex add` command. You can use
|
||||
`git annex unannex` to move content out of the annex at any point,
|
||||
even if you've already committed it.
|
||||
|
||||
This is not the command you should use if you intentionally annexed a
|
||||
file and don't want its contents any more. In that case you should use
|
||||
`git annex drop` instead, and you can also `git rm` the file.
|
||||
|
||||
* uninit
|
||||
|
||||
|
|
Loading…
Reference in a new issue