| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
| |
was set to the empty string and the other set to some expression, this bug caused all files to be wanted, instead of only files matching the expression.
Avoid: MAny `MOr` otherexpression
Which matches anything.
|
|
|
|
| |
enabled when git-annex init is run.
|
|
|
|
|
|
|
|
|
| |
appropriate places.
Not necessarily everywhere, but a lot of the most often used places.
Re the use of .Internal, see
https://github.com/pcapriotti/optparse-applicative/issues/155
|
|
|
|
|
|
|
| |
repository to a remote.
Also, it used to only check that one of the repos was not in direct mode;
now when either repo is direct mode, annex.hardlink won't have an effect.
|
|
|
|
| |
sync process, as well as supporting --commit, --pull, --push, and --no-content options to specify the (current) default behavior.
|
|
|
|
|
| |
The vbs launchers now are passed the path where git-annex was installed to,
so they will work when it's not in path.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is pretty complicated, but I have both "git-annex" and "git annex"
working both in the git bash shell even with git not added to path.
And, when git's added to path, both work from MS-DOS prompt window too.
I think that the webapp startup does still need git in path, so
instructions will keep saying to do that. But, users often disregard them,
and hopefully this will reduce support traffic.
Also, switched the wget from the cygwin one to the msys2 one, avoiding the
complication of needing to bundle any cygwin dlls.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using msysgit with git-annex is no longer supported.
At the same time, I'm updating the rsync.exe in my downloads repository
with the one from msys2.
Note that rsync is currently still being ldded and installed in Git/cmd/
like the other cygwin programs. The ldd fails and this failure is ignored.
It would be better to special case it to go in Git/usr/bin/, so that the
user can't run rsync in a dos prompt window, which doesn't work, as it needs
additional libs. However, as far as git-annex running rsync running ssh,
it works ok in this location.
Removed the ssh.cmd and ssh-keygen.cmd; these are not needed with git for
windows. Keeping them would let ssh be run manually from a dos prompt
window, but that's not really a goal.
|
|
|
|
|
|
| |
When gpg.program is configured, it's used to get the command to run for
gpg. Useful on systems that have only a gpg2 command or want to use it
instead of the gpg command.
|
|
|
|
| |
encoded filenames on stderr when using --incremental.
|
|
|
|
| |
displayed for commands that require a git repo, etc.
|
|
|
|
| |
--unused-refspec option. Thanks, Øyvind A. Holm.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was failing at link time, some problem with terminatePID.
Re-implemented that to not use a C wrapper function, which cleared up the
problem. Removed old EvilLinker hack with must have been related to the
same problem.
Note that I have not tested this with older ghc's. In
4f59f9439687cccfb7aac6aca62dbe97038179bf I mention having tried this
approach before, and getting segfaults.. So, who knows. It seems to work
fine with ghc 7.10 at least.
|
| |
|
|
|
|
|
|
|
|
| |
Ben Boeckel had a patch, but..
Actually, that was not the only place that used ScheduleIncremental when
built w/o database. Since the data type doesn't need database stuff,
I've instead fixed this build problem by exposing the
ScheduleIncremental constructor to database-less builds.
|
|
|
|
| |
Alan Dorman.
|
|
|
|
|
|
|
|
| |
and cpp.
As a result of the Makefile changes, the Debian package is built
with various hardening options. Although their benefit to a largely
haskell program is unknown.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
yet implemented in git-annex for the hurd.
Note that https://github.com/haskell/hackage-server/issues/269 is fixed, so
hopefully I can upload this to hackage this time.
|
| |
|
|
|
|
|
| |
Currently, ghc has issues getting reproducible builds with parallel
building. https://ghc.haskell.org/trac/ghc/ticket/4012
|
| |
|
| |
|
|
|
|
|
|
| |
* sync: Support --jobs
* sync --content: Avoid unnecessary second pull from remotes when
no file transfers are made.
|
| |
|
| |
|
|
|
|
| |
overhead 6x.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
characters, when in a non-unicode locale.
Oh boy, not again. So, another place that the filesystem encoding needs to
be applied. Yay.
In passing, I changed decodeBS so if a NUL is embedded in the input, the
resulting FilePath doesn't get truncated at that NUL. This was needed to
make prop_b64_roundtrips pass, and on reviewing the callers of decodeBS, I
didn't see any where this wouldn't make sense. When a FilePath is used to
operate on the filesystem, it'll get truncated at a NUL anyway, whereas if
a String is being used for something else, it might conceivably have a NUL
in it, and we wouldn't want it to get truncated when going through
decodeBS.
(NB: There may be a speed impact from this change.)
|
|
|
|
| |
metadata to not work.
|
| |
|
|
|
|
| |
Magnus_Therning.
|
|
|
|
|
|
|
|
| |
using the cryptonite library.
While cryptohash has SHA3 support, it has not been updated for the final
version of the spec. Note that cryptonite has not been ported to all arches
that cryptohash builds on yet.
|
|
|
|
|
|
|
|
|
|
| |
mode.
This was potentially a hole in the readonly mode armor even before my last
commit. If the user could push a git-annex branch to a repo, they could get
git-annex-shell to initialize the repo. After my last commit, the user
didn't even need to be allowed to push a branch to init the repo, so
this hole certianly needs to be closed now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now it suffices to run git remote add, followed by git-annex sync. Now the
remote is automatically initialized for use by git-annex, where before the
git-annex branch had to manually be pushed before using git-annex sync.
Note that this involved changes to git-annex-shell, so if the remote is
using an old version, the manual push is still needed.
Implementation required git-annex-shell be changed, so configlist can
autoinit a repository even when no git-annex branch has been pushed yet.
Unfortunate because we'll have to wait for it to get deployed to servers
before being able to rely on this change in the documentation.
Did consider making git-annex sync push the git-annex branch to repos that
didn't have a uuid, but this seemed difficult to do without complicating it
in messy ways.
It would be cleaner to split a command out from configlist to handle
the initialization. But this is difficult without sacrificing backwards
compatability, for users of old git-annex versions which would not use the
new command.
|
|
|
|
| |
properly if unpacked into a directory that contains ":" or ";" in its name.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
environment variable.
I think that the problem was caused by windows not having a concept of an
env var that is set, but to the empty string. So, GIT_ANNEX_SSHOPTION
got set to "" and was not seen as set at all.
Easy fix, which also makes git-annex sync a little faster is to not set
GIT_SSH, when GIT_ANNEX_SSHOPTION has no options. Might as well let git use
ssh per usual in this case, no need to run git-annex as the proxy ssh
command..
|
|
|
|
|
|
|
|
|
| |
This fixes a reversion introduced by relative path changes back last winter.
The root cause is simplifyPath "../foo" was incorrectly yielding "foo".
absPathFrom seems quite horrible. Probably most things that use it should
use </> instead.
|
|
|
|
|
|
|
| |
Git.Ref.headSha doesn't really work in direct mode as there's not a head,
so it was actually diffing against the empty tree and so not removing any
deleted files. Get the sha of the current branch instead, which is the same
thing Command.Sync does.
|
|
|
|
|
|
|
| |
* proxy: Fix proxy git commit of non-annexed files in direct mode.
* proxy: If a non-proxied git command, such as git revert
would normally fail because of unstaged files in the work tree,
make the proxied command fail the same way.
|
| |
|
| |
|
|
|
|
| |
Type of str changed in 0.11.
|