| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
something so that reinject --known will work.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
* map: Hide dead repositories that are not connected to the graph.
* map: Changed colors; red is used for untrusted repositories and grey
for dead.
|
|
|
|
| |
its input, which resulted in git add bypassing git-annex.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
default
git 2.8.1 (or perhaps 2.9.0) is going to prevent git merge from merging in
unrelated branches. Since the webapp's pairing etc features often combine
together repositories with unrelated histories, work around this behavior
change by setting GIT_MERGE_ALLOW_UNRELATED_HISTORIES when the assistant
merges.
Note though that this is not done for git annex sync's merges, so
it will follow git's default or configured behavior.
|
|
|
|
| |
For example: git-annex reinject --known /mnt/backup/*
|
|
|
|
|
|
| |
When git-annex is used with a git version older than 2.2.0, disable support for
adjusted branches, since GIT_COMMON_DIR is needed to update them and was first
added in that version of git.
|
|
|
|
| |
refer to a file
|
|
|
|
| |
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.
|
|
|
|
| |
git-annex, opening the webapp went ahead and ran the assistant there, annexing all files. Since this is almost certianly not desirable, especially when the user is just opening the webapp from a dekstop menu which happens to run it in $HOME, the webapp will now not treat such a $HOME git repository as a git-annex repository.
|
|
|
|
| |
does not allow honoring that configuration.
|
| |
|
| |
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
| |
Rationalle: User might have hook scripts whose output they want to see.
Also, git commit output may tell the user they forgot to add a file.
The output is not too ugly when there's nothing to commit.
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Also cleaned up ugliness with zombies.
|
| | |
|
| |
| |
| |
| | |
a filesystem not supporting symlinks.
|
| |
| |
| |
| | |
doesn't work in v5
|
| | |
|
| |\
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |\
| |/
|/| |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |\
| |_|/
|/| | |
|
| | | |
|