| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
| |
Making the name look too much like the adjusted branch was ambiguous.
|
| |
|
|
| |
basis ref
|
| | |
|
| |
|
|
|
|
| |
This is how direct mode does it too, and somehow, for reasons that
currently escape me, this makes git merge not care if it's run with an
empty work tree.
|
| |
|
|
| |
branch
|
| |
|
|
|
|
| |
merge conflicts
Still needs work when there are actual merge conflicts.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
unlocked branch.
This makes the direct mode to v6 upgrade able to be performed in one clone
of a repository without affecting other clones, which can continue using v5
and direct mode.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Closing the lock manually caused a later exception when the bracket tried
to close it again.
|
| |
|
|
| |
a filesystem not supporting symlinks.
|
| |
|
|
|
| |
Cached the current branch lookup just because it seems unnecessary overhead
to run an extra git command per add to query the current branch.
|
| |
|
|
|
| |
no longer needed now that hashPointerFile uses a long-running git
hash-object handle
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Only reverse adjust the changes in the commit, which means that adjustments
do not need to be generally cleanly reversable.
For example, an adjustment can unlock all locked files, but does not need
to worry about files that were originally unlocked when reversing, because
it will only ever be run on files that have been changed. So, it's ok
if it locks all files when reversed, or even leaves all files as-is when
reversed.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Using adjusted/unlocked/master made lots of git stuff dealing with "master"
complain that it was ambiguous. This new appoach is more like view branch
names, and shows the adjustment right there in the branch display even if
only the basename of the branch is shown.
|
| | |
|
| |
|
|
|
|
|
| |
There's a race here, but entering an adjusted branch for the first time is
not something to do when a commit is being made at the same time. Although,
may want to prevent the assistant from committing while entering the
adjusted branch.
|
| | |
|
| |
|
|
|
| |
Avoids race with another git commit at the same time adjusted branch is
being updated.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
So, it will pull and push the original branch, not the adjusted one.
And, for merging, it will use updateAdjustedBranch (not implemented yet).
Note that remaining uses of Git.Branch.current need to be checked too;
for things that should act on the original branch, and not the adjusted
branch.
|
| |
|
|
| |
Allows it to be recovered easily.
|
|
|
"git annex adjust" may be a temporary interface, but works for a proof of
concept.
It is pretty fast at creating the adjusted branch. The main overhead is
injecting pointer files. It might be worth optimising that by reusing the
symlink target as the pointer file content. When I tried to do that,
the problem was that the clean filter doesn't use that same format, and so
git thought files had changed. Could be dealt with, perhaps make the clean
filter use symlink format for pointer files when on an adjusted branch?
But the real overhead is in checking out the branch, when git runs the
smudge filter once per file. That is perhaps too slow to be usable,
although it may only affect initial checkout of the branch, and not
updates. TBD.
|
Joey Hess