| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, disabled trying to update the git-annex branch on the remote,
since that data is never used by operations that act on such remotes.
Also, when copying content to such a remote, skip committing the presence
information changes to its git-annex branch. Leaving it in the journal there
is ok: Any command run on the remote that needs the info will flush the
journal.
This may partially solve this bug:
http://git-annex.branchable.com/bugs/fails_to_handle_lot_of_files/
Although I still see unreaped git processes piling up when doing a copy --to.
|
| | |
|
| | |
|
| |
|
|
| |
no code changes
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Another process may stage journalled files before the lock is
taken, so need to get the list of journalled files afterwards.
It's unfortunate this means getting the directory contents twice,
but it seems better to do that than sometimes take the lock
unnecessarily.
|
| |
|
|
|
| |
And a theoretical fix to branchstate cache invalidation, but not a bug
that could actually happen.
|
| |
|
|
|
| |
It was checking if it needed to merge on every branch access, fix it to
only check once.
|
| |
|
|
| |
avoids git warning "error: duplicate parent xxx ignored"
|
| |
|
|
| |
only write index once
|
| | |
|
| | |
|
| |
|
Joey Hess