| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that direct mode sets core.bare=true, git's normal prohibition about
pushing into the currently checked out branch doesn't work.
A simple fix for this would be an update hook which blocks the pushes..
but git hooks must be executable, and git-annex needs to be usable on eg,
FAT, which lacks x bits.
Instead, enabling direct mode switches the branch (eg master) to a special
purpose branch (eg annex/direct/master). This branch is not pushed when
syncing; instead any changes that git annex sync commits get written to
master, and it's pushed (along with synced/master) to the remote.
Note that initialization has been changed to always call setDirect,
even if it's just setDirect False for indirect mode. This is needed because
if the user has just cloned a direct mode repo, that nothing has synced
with before, it may have no master branch, and only a annex/direct/master.
Resulting in that branch being checked out locally too. Calling setDirect False
for indirect mode moves back out of this branch, to a new master branch,
and ensures that a manual "git push" doesn't push changes directly to
the annex/direct/master of the remote. (It's possible that the user
makes a commit w/o using git-annex and pushes it, but nothing I can do
about that really.)
This commit was sponsored by Jonathan Harrington.
|
| |
|
|
|
| |
This includes storing the current state of the HEAD ref, which git annex
sync is going to need, but does not make sync use it.
|
| | |
|
| | |
|
| |
|
|
|
| |
Sigh, git is so *fragile*. Or rather, across the set of systems that use
git-annex, where are no many horribly broken systems..
|
| | |
|
| |
|
|
| |
do not support hard links, but do support symlinks and other POSIX filesystem features.
|
| | |
|
| |
|
|
| |
content
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
Needed to make git annex drop work on cygwin, where git keeps it enabled.
I think git can indeed make symlinks on Cygwin, due to being linked to
the library. git-annex, however, cannot.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
| |
on server
|
| | |
|
| |
|
|
| |
connection caching.
|
| | |
|
| |
|
|
|
|
|
| |
To avoid old versions of git-annex getting confused.
There is no upgrade required though.
We switch back to 3 when going from direct to indirect.
|
| | |
|
| | |
|
| |
|
|
|
| |
Gets the direct mode mapping set up correctly. Maybe other stuff, but
probably not, since this is probably a new repo.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
git annex init probes for crippled filesystems, and sets direct mode, as
well as `annex.crippledfilesystem`.
Avoid manipulating permissions of files on crippled filesystems.
That would likely cause an exception to be thrown.
Very basic support in Command.Add for cripped filesystems; avoids the lock
down entirely since doing it needs both permissions and hard links.
Will make this better soon.
|
| |
|
|
|
|
| |
This is so gratutious and pointless. It's a shame that everything we
learned about Unix portability and the importance of standards has been
thrown out the window by these guys.
|
| | |
|
| | |
|
| |
|
|
| |
which doesn't work with LDAP or NIS.
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
automatically be generated, like "joey@gnu:~/foo"
|
| |/
|
|
| |
My $HOME is in git, let's make it work :)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
|
| | |
|
| | |
|
| |
|
|
| |
no behavior changes
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Many functions took the repo as their first parameter. Changing it
consistently to be the last parameter allows doing some useful things with
currying, that reduce boilerplate.
In particular, g <- gitRepo is almost never needed now, instead
use inRepo to run an IO action in the repo, and fromRepo to get
a value from the repo.
This also provides more opportunities to use monadic and applicative
combinators.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
no code changes
|
| | |
|
| | |
|
Joey Hess
Joey Hess