| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| |
|
|
| |
git-annex branch to have lines teminated with \r.
|
| |
|
|
|
|
|
|
|
| |
This avoids a collision if different ssh ports are used on the same host
for some reason.
Note that it's ok to change the format of the mangled hostname; unmangling
only extracts the hostname from it, and once ssh is configured for a
mangled hostname, that config is not changed.
|
| |
|
|
|
|
|
|
|
|
| |
This avoids a potential slowdown when using lots of views.
I think that it makes sense for unused to ignore (local) view branches,
since these are by definition supposed to be views of an existing branch,
so looking at the branch should be sufficient (and if the view is out of
date and has files that have since been deleted from the branch, the user's
intent is not to preserve those from unused reaping).
|
| | |
|
| |
|
|
| |
Happened with eg, gcrypt remotes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid stomping on existing group and preferred content settings
when enabling or combining with an already existing remote.
Two level fix. First, use defaultStandardGroup rather than
setStandardGroup, so if there is an existing configuration in the git-annex
branch, it's not overwritten.
To handle pre-existing ssh remotes (including gcrypt), a second level is
needed, because before syncing with the remote, it's configuration won't be
available locally. (And syncing could take a long time.) So, in this case,
keep track of whether the remote is being created or enabled, and only set
configs when creating it.
This commit was sponsored by Anders Lannerback.
|
| |
|
|
|
|
|
|
|
|
| |
adding a local repository (or removable drive repository) that already exists.
This does mean that if the webapp is asked to add a git repository on
a removable drive that already exists, but is not yet a git-annex
repository, it will avoid putting it in any group. That unlikely edge case
is ok; the next step is the edit repository screen, which will show it's
not in any group and the user can pick one.
|
| |
|
|
|
|
|
|
|
| |
and preferred content to be set in the current repository, even when not combining.
There was a tricky bit here, when it does combine, the edit form is shown,
and so the info needs to be committed to the new repository, but then
pulled into the current one. And caches need to be invalidated for it
to be visible in the edit form.
|
| | |
|
| |
|
|
|
| |
This works around a bug in the EvilSplicer; see
http://git-annex.branchable.com/bugs/Bootstrap3_icons_missing_on_Android/
|
| | |
|
| |
|
|
| |
that to foo, since it's in the home directory by default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
characters to 8 bits.
Allow any encoding to be used, as with filenames (but utf8 is the sane
choice). Affects metadata and repository descriptions, and preferred
content expressions.
The question of what's the right encoding for the git-annex branch is a
vexing one. utf-8 would be a nice choice, but this leaves the possibility
of bad data getting into a git-annex branch somehow, and this resulting in
git-annex crashing with encoding errors, which is a failure mode I want to
avoid.
(Also, preferred content expressions can refer to filenames, and filenames
can have any encoding, so limiting to utf-8 would not be ideal.)
The union merge code already took care to not assume any encoding for a
file. Except it assumes that any \n is a literal newline, and not part of
some encoding of a character that happens to contain a newline. (At least
utf-8 avoids using newline for anything except liternal newlines.)
Adapted the git-annex branch code to use this same approach.
Note that there is a potential interop problem with Windows, since
FileSystemEncoding doesn't work there, and instead things are always
decoded as utf-8. If someone uses non-utf8 encoding for data on the
git-annex branch, this can lead to an encoding error on windows. However,
this commit doesn't actually make that any worse, because the union merge
code would similarly fail with an encoding error on windows in that
situation.
This commit was sponsored by Kyle Meyer.
|
| |
|
|
| |
prohibit making hard links.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
can be easily enabled elsewhere.
This is the capstone in making the webapp remember ssh remotes
so they can be easily enabled in other clones of the repository.
Currently, the user will need to enter a password to enable the ssh remote,
but everything else is filled in automatically.
This commit was sponsored by Peter Lloyd.
|
| |
|
|
|
|
|
|
|
|
|
| |
The repository must have been added using initremote.
Turned out to be much much simpler than expected, because I was able to
reuse the existing code for enabling rsync and gcrypt remotes, which
was already sufficiently general that it will also work for ssh remotes.
Total win!
This commit was sponsored by an unknown bitcoin contributor.
|
| |
|
|
|
| |
initremote stores the location of an already existing git remote, and
enableremote setups up a remote using its stored location.
|
| |
|
|
| |
intialized by git-annex.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the same repository, honor remote cost settings and use the cheapest available.
Note that TransferInfo does not always contain the Remote, although
any transfer added to the TransferQueue does have a Remote in its
TransferInfo. The transferkeys command still accepts a UUID, which is
useful to handle upgrades, where an old assistant version runs the new
transferkeys.
This commit was sponsored by Kalle Svensson.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
bundle into PATH.
Unless busybox doesn't support readlink -f, then it just uses readlink and
symlinking won't work. Also, OSX has no readlink -f so not done there.
Thanks, jlebar.
|
| | |
|
| |
|
|
| |
repository.
|
| |
|
|
|
|
|
| |
Broken by cffc5e74129be798801086c612efd099fe7148ac, in November!
I missed this because there's no strong type checking across the AJAX call. :(
Need to switch to Fay to avoid such bugs..
|
| | |
|
| |
|
|
| |
This ensures it's pulled in when building the standalone tarball
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When setting up a remote on a ssh server, prompt for a password inside the
webapp, rather than relying on ssh's own password prompting in the terminal
the webapp was started from, or ssh-askpass.
Avoids double prompting for the ssh password (and triple-prompting on
windows for rsync.net), since the entered password is cached for 10 minutes
and this cached password is reused when setting up the repository, after
the initial probe.
When the user has an existing ssh key set up, they can choose to use it,
rather than entering a password. The webapp used to probe for this case
automatically, so this is a little harder, but it's an advanced user thing.
Note that this commit is known to break enabling existing rsync
repositories. It hs not been tested with gcrypt repositories. It's not been
successfully tested yet on Windows.
This commit was sponsored by Ralph Mayer.
|
| |
|
|
|
| |
Omitted a couple of files what have had significant contributions from
others.
|
| | |
|
| |\
| |
| |
| |
| | |
Conflicts:
debian/changelog
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This commit was sponsored by Melissa Binde.
|
| | |
| |
| |
| | |
always in square brackets after the description.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
the standalone tarball or OSX app, and so does not have git-annex in PATH (and may also not have git or rsync in PATH).
* webapp: Support using git-annex on a remote server, which was installed
from the standalone tarball or OSX app, and so does not have
git-annex in PATH (and may also not have git or rsync in PATH).
* standalone tarball, OSX app: Install a ~/.ssh/git-annex-wrapper, which
can be used to run git-annex, git, rsync, etc.
|
| |
|
|
|
|
|
| |
to work around the problem, also make it set user.name.
I was able to reproduce git failing to commit despite user.email being set,
in a test account on my laptop. The account had no GECOS information.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
~/.config/git-annex/autostart but no longer has a git repository in it.
|
| |
|
|
| |
file system. This is a better approach to fix #700282 while not unncessarily losing file permissions on non-crippled systems.
|
| |
|
|
| |
count.
|
| |
|
|
| |
configuration of a previously known repository. Useful if a repository got deleted and you want to clone it back the way it was.
|
| | |
|
Joey Hess