| Commit message (Collapse) | Author | Age |
|
|
|
| |
dotfile in its root.
|
| |
|
|
|
|
|
|
|
|
| |
subdirectory of the repository.
This affected git annex view. It turns out that some other places
that use GIT_INDEX_FILE were already working around the bug. I removed the
workaround from Annex.Branch since the new workaround will do.
|
| |
|
| |
|
|
|
|
|
|
| |
In commit 07b1aa343b6d82e8f75de606a5647b0a789f76e0 I accidentially
made gitAnnexLocation do more work, checking content locations,
when used in a regular repo.
|
|
|
|
| |
nonstandard place.
|
|
|
|
|
|
| |
added to git as-is.
(git add of a pointer file already did the right thing)
|
|
|
|
|
| |
This makes git-annex sync also do it, which makes sure that the keys db
info is fresh when doing a sync --content.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a potential race where the smudge filter is run at the same time an
object is being downloaded. If the download finished after the inAnnex
check, and before the keys db was updated, the associated file would not
get updated with the downloaded content.
I'm not sure this closes the race; it may only narrow the window. Problem
is, the keys database needs to communicate between two different processes.
In the case of the assistant, the transferkeys command is the other
process, and it closes the db handle after getting the file. So, it should
re-open the database and so see the update that the smudge filter has
written to it. But, what if the smudge filter takes a while to update the
database?
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
sometimes not replace pointer files.
The keys database handle needs to be closed after merging, because the
smudge filter, in another process, updates the database. Old cached info
can be read for a while from the open database handle; closing it ensures
that the info written by the smudge filter is available.
This is pretty horribly ad-hoc, and it's especially nasty that the
transferrer closes the database every time.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it might contain changes that have not yet been propigated to the original branch.
Could not think of a foolproof way to detect if the old adjusted branch was
just behind the current branch. It's possible that the user amended the
adjusting commit at the head of the adjusted branch, for example.
I decided to bail in this situation, instead of just entering the old
branch, so that if git annex adjust succeeds the user is always in a
*current* adjusted branch, not some old and out of date one.
What could perhaps be done is enter the old branch and then update it. But
that seems too magical; the user may have rebased master or something or
may not want to propigate the changes from the old branch. Best to error
out.
|
| |
|
|\ |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
access"
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\ |
|
| |
| |
| |
| | |
what's used in initremote.
|
| |
| |
| |
| |
| |
| |
| | |
In particular, specifying multiple keyid= in enableremote/initremote
doesn't work, and never has AFAICS, so don't suggest using it.
Also, there was some public/private key wording confusion.
|
|/ |
|
| |
|
| |
|