| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
| |
instead of deleting it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
write bit is not set and cannot be set due to the file being owned by a different user.
Made all Annex.Perms file mode changing functions ignore errors when
core.sharedRepository is set, because the file might be owned by someone
else. I don't fancy getting bug reports about crashes due to set modes in
this configuration, which is a very foot-shooty configuration in the first
place.
The fsck warning is necessary because old repos kept files mode 444, which
doesn't allow locking them, and so if the mode remains 444 due to the file
being owned by someone else, the user should be told about it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When annex.thin is set, adding an object will add the execute bits to the
work tree file, and this does mean that the annex object file ends up
executable.
This doesn't add any complexity that wasn't already present, because git
annex add of an executable file has always ingested it so that the annex
object ends up executable.
But, since an annex object file can be executable or not, when populating
an unlocked file from one, the executable bit is always added or removed
to match the mode of the pointer file.
|
| | |
|
| |
|
|
| |
Making the name look too much like the adjusted branch was ambiguous.
|
| |
|
|
| |
basis ref
|
| |
|
|
|
| |
* annex.thin and annex.hardlink are now supported on Windows.
* unannex --fast now makes hard links on Windows.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Was using L.readFile, so the Handle would remain open until the garbage
collector got around to it. Changed to explicit open and close, so we know
it's always closed when the function returns.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
doesn't work in v5
|
| |
|
|
|
| |
no longer needed now that hashPointerFile uses a long-running git
hash-object handle
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This does mean that it has to write out temp files containing updated
objects for the merge. So may use more disk space, and disk IO, but that
should generally win out over needing to launch N separate
git hash-object processes.
|
| | |
| |
| |
| | |
Handle was plumbed through, but not used.
|
| | |
| |
| |
| | |
Speeds up hashSymlink and hashPointerFile.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An unlocked present file does not have a pointer file in the worktree, so
info skipped counting it.
It may be that unused was also affected by the problem, but it seemed not
to be in my tests. I think because of the use of the associatedFilesFilter.
This fix slows down both info and unused a little bit, since they have to
query the contents of files from git, but only when handling unlocked files.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | | |
|
| | | | |
|
Joey Hess