2022-01-05 14:10:22 +00:00
|
|
|
git-annex (8.20211028) UNRELEASED; urgency=medium
|
|
|
|
|
|
|
|
|
|
This version of git-annex removes support for communicating with git-annex
|
|
|
|
|
remotes that have version 6.20180312 or older installed.
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <id@joeyh.name> Wed, 05 Jan 2022 10:09:11 -0400
|
|
|
|
|
|
2020-09-14 03:27:42 +00:00
|
|
|
git-annex (8.20200523) upstream; urgency=medium
|
2020-05-28 19:55:17 +00:00
|
|
|
|
|
|
|
|
Transition notice: Commands like `git-annex get foo*` silently skip over
|
|
|
|
|
files that are not checked into git. Since that can be surprising in many
|
|
|
|
|
cases, the behavior will change to erroring out when one of the listed
|
|
|
|
|
files is not checked into git. This change is planned for a git-annex
|
|
|
|
|
release in early 2022. If you would like to keep the current
|
|
|
|
|
behavior, use git config to set annex.skipunknown to true.
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <id@joeyh.name> Thu, 28 May 2020 13:23:40 -0400
|
|
|
|
|
|
2020-02-26 22:15:18 +00:00
|
|
|
git-annex (8.20200226) upstream; urgency=medium
|
2019-11-07 17:23:32 +00:00
|
|
|
|
|
|
|
|
This version of git-annex uses repository version 8 for all repositories.
|
|
|
|
|
|
|
|
|
|
Existing repositories will be automatically upgraded by default.
|
|
|
|
|
You can prevent this, by runing: git config annex.autoupgraderepository false
|
|
|
|
|
|
2019-12-26 20:24:40 +00:00
|
|
|
The upgrade process involves regenerating some sqlite databases. There are a
|
|
|
|
|
couple consequences of the upgrade to keep in mind:
|
2019-11-07 17:23:32 +00:00
|
|
|
|
|
|
|
|
* Any incremental fscks that were started in v7 won't resume where
|
|
|
|
|
they left off in v8, but will instead begin again from the first file.
|
|
|
|
|
* An interrupted export that was started in v7 won't resume where it left
|
|
|
|
|
off after upgrade to v8; files will be re-uploaded to the export remote.
|
|
|
|
|
* After the upgrade, git-annex will in some situations have to do extra
|
|
|
|
|
work while it finishes populating its sqlite databases.
|
|
|
|
|
|
2019-12-26 20:24:40 +00:00
|
|
|
Also, there are some behavior changes around adding dotfiles. While before
|
|
|
|
|
git-annex add skipped adding dotfiles when operating on whole directories,
|
|
|
|
|
and added dotfiles that were explicitly listed to the annex, it now adds
|
|
|
|
|
dotfiles to git by default, unless annex.dotfiles is set to true.
|
|
|
|
|
|
2020-02-26 22:15:18 +00:00
|
|
|
-- Joey Hess <id@joeyh.name> Wed, 26 Feb 2020 17:18:16 -0400
|
|
|
|
|
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
git-annex (7.20200226) upstream; urgency=high
|
|
|
|
|
|
|
|
|
|
There was a serious regression in gcrypt and encrypted git-lfs remotes.
|
|
|
|
|
Since version 7.20200202.7, git-annex incorrectly stored content
|
|
|
|
|
on those remotes without encrypting it.
|
|
|
|
|
|
|
|
|
|
If your remotes are affected, you will want to make sure to delete
|
|
|
|
|
any content that git-annex has stored on them that is not encrypted!
|
|
|
|
|
|
|
|
|
|
One way to do so is, before upgrading to this version,
|
|
|
|
|
run git-annex move --from the affected remotes. It will move
|
|
|
|
|
only the content that was not encrypted.
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <id@joeyh.name> Wed, 26 Feb 2020 17:18:16 -0400
|
2019-11-07 17:23:32 +00:00
|
|
|
|
2019-11-07 17:20:28 +00:00
|
|
|
git-annex (7.20191024) upstream; urgency=medium
|
2019-10-24 17:50:44 +00:00
|
|
|
|
|
|
|
|
When annex.largefiles is not configured, `git add` and `git commit -a`
|
|
|
|
|
add files to git, not to the annex. If you have gotten used to `git add`
|
|
|
|
|
adding all files to the annex, you can get that behavior back by running:
|
|
|
|
|
git config annex.largefiles anything
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <id@joeyh.name> Thu, 24 Oct 2019 13:46:52 -0400
|
|
|
|
|
|
2019-09-13 16:53:40 +00:00
|
|
|
git-annex (7.20190912) upstream; urgency=medium
|
2019-09-13 16:26:38 +00:00
|
|
|
|
|
|
|
|
This version of git-annex uses repository version 7 for all repositories.
|
|
|
|
|
|
|
|
|
|
Existing v5 repositories will be automatically upgraded by default.
|
|
|
|
|
You can prevent this, by runing: git config annex.autoupgraderepository false
|
|
|
|
|
|
|
|
|
|
A v7 repository can can have some files locked while other files are
|
|
|
|
|
unlocked, and all git and git-annex commands can be used on both locked and
|
|
|
|
|
unlocked files. It's a good idea to make sure that all users of the
|
|
|
|
|
repository have upgraded git-annex and upgraded their repositories
|
|
|
|
|
to the new version before starting to use that feature, since old
|
|
|
|
|
versions of git-annex will ignore the new unlocked files.
|
|
|
|
|
|
|
|
|
|
The behavior of some commands changes in an upgraded repository:
|
|
|
|
|
|
|
|
|
|
* `git add` will add files to the annex, rather than adding them directly
|
|
|
|
|
to the git repository. To cause some files to be added directly
|
|
|
|
|
to git, you can configure `annex.largefiles`. For example:
|
|
|
|
|
|
|
|
|
|
git config annex.largefiles "largerthan=100kb and not (include=*.c or include=*.h)"
|
|
|
|
|
|
|
|
|
|
* `git annex unlock` and `git annex lock` change how the pointer to
|
|
|
|
|
the annexed content is stored in git. If you commit the change,
|
|
|
|
|
that will impact all clones of the repository.
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <id@joeyh.name> Fri, 13 Sep 2019 12:19:55 -0400
|
|
|
|
|
|
2018-10-31 19:46:57 +00:00
|
|
|
git-annex (7.20181031) upstream; urgency=medium
|
2018-10-26 18:20:05 +00:00
|
|
|
|
|
|
|
|
Repository version 7 is now available. v6 repositories will automatically
|
|
|
|
|
upgrade to v7. v5 repositories are still supported and will not be
|
|
|
|
|
automatically upgraded yet.
|
|
|
|
|
|
|
|
|
|
Direct mode is deprecated, and upgrading direct mode repositories to v7 is
|
|
|
|
|
encouraged, unless they need to remain usable by older versions of git-annex.
|
|
|
|
|
Just run `git annex upgrade`.
|
|
|
|
|
|
|
|
|
|
git-annex will no longer initialize new repositories on crippled filesystems
|
2018-10-31 19:46:57 +00:00
|
|
|
using direct mode, instead it uses v7.
|
2018-10-26 18:20:05 +00:00
|
|
|
|
2018-10-31 19:46:57 +00:00
|
|
|
The git-annex Android app is no longer being updated. Users of the app
|
|
|
|
|
should remove it and install using the new Termux based installation method.
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <id@joeyh.name> Wed, 31 Oct 2018 13:05:48 -0400
|
2018-10-26 18:20:05 +00:00
|
|
|
|
2018-06-21 18:56:04 +00:00
|
|
|
git-annex (6.20180626) upstream; urgency=high
|
limit url downloads to whitelisted schemes
Security fix! Allowing any schemes, particularly file: and
possibly others like scp: allowed file exfiltration by anyone who had
write access to the git repository, since they could add an annexed file
using such an url, or using an url that redirected to such an url,
and wait for the victim to get it into their repository and send them a copy.
* Added annex.security.allowed-url-schemes setting, which defaults
to only allowing http and https URLs. Note especially that file:/
is no longer enabled by default.
* Removed annex.web-download-command, since its interface does not allow
supporting annex.security.allowed-url-schemes across redirects.
If you used this setting, you may want to instead use annex.web-options
to pass options to curl.
With annex.web-download-command removed, nearly all url accesses in
git-annex are made via Utility.Url via http-client or curl. http-client
only supports http and https, so no problem there.
(Disabling one and not the other is not implemented.)
Used curl --proto to limit the allowed url schemes.
Note that this will cause git annex fsck --from web to mark files using
a disallowed url scheme as not being present in the web. That seems
acceptable; fsck --from web also does that when a web server is not available.
youtube-dl already disabled file: itself (probably for similar
reasons). The scheme check was also added to youtube-dl urls for
completeness, although that check won't catch any redirects it might
follow. But youtube-dl goes off and does its own thing with other
protocols anyway, so that's fine.
Special remotes that support other domain-specific url schemes are not
affected by this change. In the bittorrent remote, aria2c can still
download magnet: links. The download of the .torrent file is
otherwise now limited by annex.security.allowed-url-schemes.
This does not address any external special remotes that might download
an url themselves. Current thinking is all external special remotes will
need to be audited for this problem, although many of them will use
http libraries that only support http and not curl's menagarie.
The related problem of accessing private localhost and LAN urls is not
addressed by this commit.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-06-15 20:52:24 +00:00
|
|
|
|
2018-06-21 17:34:11 +00:00
|
|
|
A security fix has changed git-annex to refuse to download content from
|
|
|
|
|
some special remotes when the content cannot be verified with a hash check.
|
|
|
|
|
In particular URL and WORM keys stored on such remotes won't be downloaded.
|
|
|
|
|
See the documentation of the annex.security.allow-unverified-downloads
|
|
|
|
|
configuration for how to deal with this if it affects your files.
|
|
|
|
|
|
2018-06-18 19:36:12 +00:00
|
|
|
A security fix has changed git-annex to only support http, https, and ftp
|
limit url downloads to whitelisted schemes
Security fix! Allowing any schemes, particularly file: and
possibly others like scp: allowed file exfiltration by anyone who had
write access to the git repository, since they could add an annexed file
using such an url, or using an url that redirected to such an url,
and wait for the victim to get it into their repository and send them a copy.
* Added annex.security.allowed-url-schemes setting, which defaults
to only allowing http and https URLs. Note especially that file:/
is no longer enabled by default.
* Removed annex.web-download-command, since its interface does not allow
supporting annex.security.allowed-url-schemes across redirects.
If you used this setting, you may want to instead use annex.web-options
to pass options to curl.
With annex.web-download-command removed, nearly all url accesses in
git-annex are made via Utility.Url via http-client or curl. http-client
only supports http and https, so no problem there.
(Disabling one and not the other is not implemented.)
Used curl --proto to limit the allowed url schemes.
Note that this will cause git annex fsck --from web to mark files using
a disallowed url scheme as not being present in the web. That seems
acceptable; fsck --from web also does that when a web server is not available.
youtube-dl already disabled file: itself (probably for similar
reasons). The scheme check was also added to youtube-dl urls for
completeness, although that check won't catch any redirects it might
follow. But youtube-dl goes off and does its own thing with other
protocols anyway, so that's fine.
Special remotes that support other domain-specific url schemes are not
affected by this change. In the bittorrent remote, aria2c can still
download magnet: links. The download of the .torrent file is
otherwise now limited by annex.security.allowed-url-schemes.
This does not address any external special remotes that might download
an url themselves. Current thinking is all external special remotes will
need to be audited for this problem, although many of them will use
http libraries that only support http and not curl's menagarie.
The related problem of accessing private localhost and LAN urls is not
addressed by this commit.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-06-15 20:52:24 +00:00
|
|
|
URL schemes by default. You can enable other URL schemes, at your own risk,
|
|
|
|
|
using annex.security.allowed-url-schemes.
|
|
|
|
|
|
2018-06-17 17:56:17 +00:00
|
|
|
A related security fix prevents git-annex from connecting to http
|
2018-06-18 17:32:20 +00:00
|
|
|
servers (and proxies) on localhost or private networks. This can
|
|
|
|
|
be overridden, at your own risk, using annex.security.allowed-http-addresses.
|
2018-06-17 18:46:22 +00:00
|
|
|
|
|
|
|
|
Setting annex.web-options no longer is enough to make curl be used,
|
|
|
|
|
and youtube-dl is also no longer used by default. See the
|
|
|
|
|
documentation of annex.security.allowed-http-addresses for
|
|
|
|
|
details and how to enable them.
|
2018-06-17 17:56:17 +00:00
|
|
|
|
limit url downloads to whitelisted schemes
Security fix! Allowing any schemes, particularly file: and
possibly others like scp: allowed file exfiltration by anyone who had
write access to the git repository, since they could add an annexed file
using such an url, or using an url that redirected to such an url,
and wait for the victim to get it into their repository and send them a copy.
* Added annex.security.allowed-url-schemes setting, which defaults
to only allowing http and https URLs. Note especially that file:/
is no longer enabled by default.
* Removed annex.web-download-command, since its interface does not allow
supporting annex.security.allowed-url-schemes across redirects.
If you used this setting, you may want to instead use annex.web-options
to pass options to curl.
With annex.web-download-command removed, nearly all url accesses in
git-annex are made via Utility.Url via http-client or curl. http-client
only supports http and https, so no problem there.
(Disabling one and not the other is not implemented.)
Used curl --proto to limit the allowed url schemes.
Note that this will cause git annex fsck --from web to mark files using
a disallowed url scheme as not being present in the web. That seems
acceptable; fsck --from web also does that when a web server is not available.
youtube-dl already disabled file: itself (probably for similar
reasons). The scheme check was also added to youtube-dl urls for
completeness, although that check won't catch any redirects it might
follow. But youtube-dl goes off and does its own thing with other
protocols anyway, so that's fine.
Special remotes that support other domain-specific url schemes are not
affected by this change. In the bittorrent remote, aria2c can still
download magnet: links. The download of the .torrent file is
otherwise now limited by annex.security.allowed-url-schemes.
This does not address any external special remotes that might download
an url themselves. Current thinking is all external special remotes will
need to be audited for this problem, although many of them will use
http libraries that only support http and not curl's menagarie.
The related problem of accessing private localhost and LAN urls is not
addressed by this commit.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-06-15 20:52:24 +00:00
|
|
|
The annex.web-download-command configuration has been removed,
|
|
|
|
|
use annex.web-options instead.
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <id@joeyh.name> Fri, 15 Jun 2018 17:54:23 -0400
|
|
|
|
|
|
use P2P protocol for checkpresent, retrieve, and store
Note that, due to not using rsync to transfer files to ssh remotes
any longer, permissions and other file metadata of annexed files
will no longer be preserved when copying them to ssh remotes.
Other remotes never supported preserving that information, so
this is not considered a regression. Added NEWS item about this.
Another significant side effect of this is that, even when rsync is run to
retrieve a file, its progress display will no longer be shown, and
instead the native git-annex progress display will appear. It would be
possible to use the rsync process display when rsync is used (old
git-annex-shell and also retrieval from a local repository), but it
would have complicated the code unncessarily, and been inconsistent
behavior.
(I'd been thinking for a while about eliminating the rsync progress
display, since it's got some annoying verbosities, including display of
the key and the "(xfr#1, to-chk=0/1)" bit and was already somewhat
inconsistent.)
retrieveKeyFileCheap still uses rsync, since that ensures that it gets
the actual file content from the remote. Using the P2P protocol would
use the local content, as long as the local and remote size are the
same.
This commit was sponsored by John Pellman on Patreon.
2018-03-09 16:57:32 +00:00
|
|
|
git-annex (6.20180309) upstream; urgency=medium
|
|
|
|
|
|
2018-03-09 17:56:21 +00:00
|
|
|
Note that, due to not using rsync to transfer files over ssh
|
use P2P protocol for checkpresent, retrieve, and store
Note that, due to not using rsync to transfer files to ssh remotes
any longer, permissions and other file metadata of annexed files
will no longer be preserved when copying them to ssh remotes.
Other remotes never supported preserving that information, so
this is not considered a regression. Added NEWS item about this.
Another significant side effect of this is that, even when rsync is run to
retrieve a file, its progress display will no longer be shown, and
instead the native git-annex progress display will appear. It would be
possible to use the rsync process display when rsync is used (old
git-annex-shell and also retrieval from a local repository), but it
would have complicated the code unncessarily, and been inconsistent
behavior.
(I'd been thinking for a while about eliminating the rsync progress
display, since it's got some annoying verbosities, including display of
the key and the "(xfr#1, to-chk=0/1)" bit and was already somewhat
inconsistent.)
retrieveKeyFileCheap still uses rsync, since that ensures that it gets
the actual file content from the remote. Using the P2P protocol would
use the local content, as long as the local and remote size are the
same.
This commit was sponsored by John Pellman on Patreon.
2018-03-09 16:57:32 +00:00
|
|
|
any longer, permissions and other file metadata of annexed files
|
|
|
|
|
will no longer be preserved when copying them to and from ssh remotes.
|
|
|
|
|
Other remotes never supported preserving that information, so
|
|
|
|
|
this is not considered a regression.
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <id@joeyh.name> Fri, 09 Mar 2018 13:22:47 -0400
|
|
|
|
|
|
|
|
|
|
git-annex (6.20170228) upstream; urgency=medium
|
2017-02-28 17:28:34 +00:00
|
|
|
|
|
|
|
|
This version of git-annex has mitigations for SHA1 hash collision
|
|
|
|
|
problems.
|
|
|
|
|
|
|
|
|
|
A new annex.securehashesonly configuration, when used in combination with
|
|
|
|
|
signed git commits, avoids potential hash collision problems in git-annex
|
|
|
|
|
repositories. For details, see this web page:
|
|
|
|
|
<https://git-annex.branchable.com/tips/using_signed_git_commits/>
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <id@joeyh.name> Tue, 28 Feb 2017 13:28:50 -0400
|
|
|
|
|
|
use P2P protocol for checkpresent, retrieve, and store
Note that, due to not using rsync to transfer files to ssh remotes
any longer, permissions and other file metadata of annexed files
will no longer be preserved when copying them to ssh remotes.
Other remotes never supported preserving that information, so
this is not considered a regression. Added NEWS item about this.
Another significant side effect of this is that, even when rsync is run to
retrieve a file, its progress display will no longer be shown, and
instead the native git-annex progress display will appear. It would be
possible to use the rsync process display when rsync is used (old
git-annex-shell and also retrieval from a local repository), but it
would have complicated the code unncessarily, and been inconsistent
behavior.
(I'd been thinking for a while about eliminating the rsync progress
display, since it's got some annoying verbosities, including display of
the key and the "(xfr#1, to-chk=0/1)" bit and was already somewhat
inconsistent.)
retrieveKeyFileCheap still uses rsync, since that ensures that it gets
the actual file content from the remote. Using the P2P protocol would
use the local content, as long as the local and remote size are the
same.
This commit was sponsored by John Pellman on Patreon.
2018-03-09 16:57:32 +00:00
|
|
|
git-annex (6.20170101) upstream; urgency=medium
|
2016-12-27 20:36:05 +00:00
|
|
|
|
|
|
|
|
XMPP support has been removed from the assistant in this release.
|
|
|
|
|
|
|
|
|
|
If your repositories used XMPP to keep in sync, that will no longer
|
|
|
|
|
work, and you should enable some other remote to keep them in sync.
|
|
|
|
|
A ssh server is one way, or use the new Tor pairing feature.
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <id@joeyh.name> Tue, 27 Dec 2016 16:37:46 -0400
|
|
|
|
|
|
use P2P protocol for checkpresent, retrieve, and store
Note that, due to not using rsync to transfer files to ssh remotes
any longer, permissions and other file metadata of annexed files
will no longer be preserved when copying them to ssh remotes.
Other remotes never supported preserving that information, so
this is not considered a regression. Added NEWS item about this.
Another significant side effect of this is that, even when rsync is run to
retrieve a file, its progress display will no longer be shown, and
instead the native git-annex progress display will appear. It would be
possible to use the rsync process display when rsync is used (old
git-annex-shell and also retrieval from a local repository), but it
would have complicated the code unncessarily, and been inconsistent
behavior.
(I'd been thinking for a while about eliminating the rsync progress
display, since it's got some annoying verbosities, including display of
the key and the "(xfr#1, to-chk=0/1)" bit and was already somewhat
inconsistent.)
retrieveKeyFileCheap still uses rsync, since that ensures that it gets
the actual file content from the remote. Using the P2P protocol would
use the local content, as long as the local and remote size are the
same.
This commit was sponsored by John Pellman on Patreon.
2018-03-09 16:57:32 +00:00
|
|
|
git-annex (4.20131002) upstream; urgency=low
|
2016-05-24 05:00:06 +00:00
|
|
|
|
|
|
|
|
The layout of gcrypt repositories has changed, and
|
|
|
|
|
if you created one you must manually upgrade it.
|
|
|
|
|
See /usr/share/doc/git-annex/html/upgrades/gcrypt.html
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <joeyh@debian.org> Tue, 24 Sep 2013 13:55:23 -0400
|
|
|
|
|
|
use P2P protocol for checkpresent, retrieve, and store
Note that, due to not using rsync to transfer files to ssh remotes
any longer, permissions and other file metadata of annexed files
will no longer be preserved when copying them to ssh remotes.
Other remotes never supported preserving that information, so
this is not considered a regression. Added NEWS item about this.
Another significant side effect of this is that, even when rsync is run to
retrieve a file, its progress display will no longer be shown, and
instead the native git-annex progress display will appear. It would be
possible to use the rsync process display when rsync is used (old
git-annex-shell and also retrieval from a local repository), but it
would have complicated the code unncessarily, and been inconsistent
behavior.
(I'd been thinking for a while about eliminating the rsync progress
display, since it's got some annoying verbosities, including display of
the key and the "(xfr#1, to-chk=0/1)" bit and was already somewhat
inconsistent.)
retrieveKeyFileCheap still uses rsync, since that ensures that it gets
the actual file content from the remote. Using the P2P protocol would
use the local content, as long as the local and remote size are the
same.
This commit was sponsored by John Pellman on Patreon.
2018-03-09 16:57:32 +00:00
|
|
|
git-annex (3.20120123) upstream; urgency=low
|
2016-05-24 05:00:06 +00:00
|
|
|
|
|
|
|
|
There was a bug in the handling of directory special remotes that
|
|
|
|
|
could cause partial file contents to be stored in them. If you use
|
|
|
|
|
a directory special remote, you should fsck it, to avoid potential
|
|
|
|
|
data loss.
|
|
|
|
|
|
|
|
|
|
Example: git annex fsck --from mydirectory
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <joeyh@debian.org> Thu, 19 Jan 2012 15:24:23 -0400
|
|
|
|
|
|
use P2P protocol for checkpresent, retrieve, and store
Note that, due to not using rsync to transfer files to ssh remotes
any longer, permissions and other file metadata of annexed files
will no longer be preserved when copying them to ssh remotes.
Other remotes never supported preserving that information, so
this is not considered a regression. Added NEWS item about this.
Another significant side effect of this is that, even when rsync is run to
retrieve a file, its progress display will no longer be shown, and
instead the native git-annex progress display will appear. It would be
possible to use the rsync process display when rsync is used (old
git-annex-shell and also retrieval from a local repository), but it
would have complicated the code unncessarily, and been inconsistent
behavior.
(I'd been thinking for a while about eliminating the rsync progress
display, since it's got some annoying verbosities, including display of
the key and the "(xfr#1, to-chk=0/1)" bit and was already somewhat
inconsistent.)
retrieveKeyFileCheap still uses rsync, since that ensures that it gets
the actual file content from the remote. Using the P2P protocol would
use the local content, as long as the local and remote size are the
same.
This commit was sponsored by John Pellman on Patreon.
2018-03-09 16:57:32 +00:00
|
|
|
git-annex (3.20110624) upstream; urgency=low
|
2016-05-24 05:00:06 +00:00
|
|
|
|
|
|
|
|
There has been another change to the git-annex data store.
|
|
|
|
|
Use `git annex upgrade` to migrate your repositories to the new
|
|
|
|
|
layout. See <http://git-annex.branchable.com/upgrades/> or
|
|
|
|
|
/usr/share/doc/git-annex/html/upgrades.html
|
|
|
|
|
|
|
|
|
|
The significant change this time is that the .git-annex/ directory
|
|
|
|
|
is gone; instead there is a git-annex branch that is automatically
|
|
|
|
|
maintained by git-annex, and encapsulates all its state nicely out
|
|
|
|
|
of your way.
|
|
|
|
|
|
|
|
|
|
You should make sure you include the git-annex branch when
|
|
|
|
|
git pushing and pulling.
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <joeyh@debian.org> Tue, 21 Jun 2011 20:18:00 -0400
|
|
|
|
|
|
use P2P protocol for checkpresent, retrieve, and store
Note that, due to not using rsync to transfer files to ssh remotes
any longer, permissions and other file metadata of annexed files
will no longer be preserved when copying them to ssh remotes.
Other remotes never supported preserving that information, so
this is not considered a regression. Added NEWS item about this.
Another significant side effect of this is that, even when rsync is run to
retrieve a file, its progress display will no longer be shown, and
instead the native git-annex progress display will appear. It would be
possible to use the rsync process display when rsync is used (old
git-annex-shell and also retrieval from a local repository), but it
would have complicated the code unncessarily, and been inconsistent
behavior.
(I'd been thinking for a while about eliminating the rsync progress
display, since it's got some annoying verbosities, including display of
the key and the "(xfr#1, to-chk=0/1)" bit and was already somewhat
inconsistent.)
retrieveKeyFileCheap still uses rsync, since that ensures that it gets
the actual file content from the remote. Using the P2P protocol would
use the local content, as long as the local and remote size are the
same.
This commit was sponsored by John Pellman on Patreon.
2018-03-09 16:57:32 +00:00
|
|
|
git-annex (0.20110316) upstream; urgency=low
|
2016-05-24 05:00:06 +00:00
|
|
|
|
|
|
|
|
This version reorganises the layout of git-annex's files in your repository.
|
|
|
|
|
There is an upgrade process to convert a repository from the old git-annex
|
|
|
|
|
to this version. See <http://git-annex.branchable.com/upgrades/> or
|
|
|
|
|
/usr/share/doc/git-annex/html/upgrades.html
|
|
|
|
|
|
|
|
|
|
-- Joey Hess <joeyh@debian.org> Wed, 16 Mar 2011 15:49:15 -0400
|