e213ef310f
* Fix minor FD leak in journal code. Closes: #754608 * direct: Fix handling of case where a work tree subdirectory cannot be written to due to permissions. * migrate: Avoid re-checksumming when migrating from hashE to hash backend. * uninit: Avoid failing final removal in some direct mode repositories due to file modes. * S3: Deal with AWS ACL configurations that do not allow creating or checking the location of a bucket, but only reading and writing content to it. * resolvemerge: New plumbing command that runs the automatic merge conflict resolver. * Deal with change in git 2.0 that made indirect mode merge conflict resolution leave behind old files. * sync: Fix git sync with local git remotes even when they don't have an annex.uuid set. (The assistant already did so.) * Set gcrypt-publish-participants when setting up a gcrypt repository, to avoid unncessary passphrase prompts. This is a security/usability tradeoff. To avoid exposing the gpg key ids who can decrypt the repository, users can unset gcrypt-publish-participants. * Install nautilus hooks even when ~/.local/share/nautilus/ does not yet exist, since it is not automatically created for Gnome 3 users. * Windows: Move .vbs files out of git\bin, to avoid that being in the PATH, which caused some weird breakage. (Thanks, divB) * Windows: Fix locking issue that prevented the webapp starting (since 5.20140707). # imported from the archive
29 lines
1.6 KiB
Markdown
29 lines
1.6 KiB
Markdown
I've been investigating ways to implement a [[/todo/direct_mode_guard]].
|
|
Preventing a stray `git commit -a` or `git add` doing bad things in a
|
|
direct mode repository seems increasingly important.
|
|
|
|
First, considered moving `.git`, so git won't know it's a git repository.
|
|
This doesn't seem *too* hard to do, but there will certainly be unexpected
|
|
places that assume `.git` is the directory name.
|
|
|
|
I dislike it more and more as I think about it though, because it moves
|
|
direct mode git-annex toward being entirely separate from git, and I don't
|
|
want to write my own version control system. Nor do I want to complicate
|
|
the git ecosystem with tools needing to know about git-annex to work in
|
|
such a repository.
|
|
|
|
So, I'm happy that one of the other ideas I tried today seems quite
|
|
promising. Just set core.bare=true in a direct mode repository. This nicely
|
|
blocks all git commands that operate on the working tree from doing
|
|
anything, which is just what's needed in direct mode, since they don't know
|
|
how to handle the direct mode files. But it lets all git commands and other
|
|
tools that don't touch the working tree continue to be used. You can even
|
|
run `git log file` in such a repository (surprisingly!)
|
|
|
|
It also gives an easy out for anyone who really wants to use git commands
|
|
that operate on the work tree of their direct mode repository, by just
|
|
passing `-c core.bare=false`. And it's really easy to implement in
|
|
git-annex too -- it can just notice if a repo has core.bare and
|
|
annex.direct both set, and pass that parameter to every git command it
|
|
runs. I should be able to get by with only modifying 2 functions to
|
|
implement this.
|