Merge branch 'master' into sqlite
This commit is contained in:
Joey Hess
commit
6147130e86
26 changed files with 355 additions and 37 deletions
|
|
@ -109,7 +109,7 @@ initialize' mversion = checkCanInitialize $ do
|
|||
setVersion (fromMaybe defaultVersion mversion)
|
||||
configureSmudgeFilter
|
||||
showSideAction "scanning for unlocked files"
|
||||
scanUnlockedFiles True
|
||||
scanUnlockedFiles
|
||||
unlessM isBareRepo $ do
|
||||
hookWrite postCheckoutHook
|
||||
hookWrite postMergeHook
|
||||
|
|
|
|||
|
|
@ -69,11 +69,12 @@ ifAnnexed file yes no = maybe no yes =<< lookupFile file
|
|||
- when initializing/upgrading a v6+ mode repository.
|
||||
-
|
||||
- Also, the content for the unlocked file may already be present as
|
||||
- an annex object. If so, make the unlocked file use that content
|
||||
- when replacefiles is True.
|
||||
- an annex object. If so, populate the pointer file with it.
|
||||
- But if worktree file does not have a pointer file's content, it is left
|
||||
- as-is.
|
||||
-}
|
||||
scanUnlockedFiles :: Bool -> Annex ()
|
||||
scanUnlockedFiles replacefiles = whenM (inRepo Git.Ref.headExists) $ do
|
||||
scanUnlockedFiles :: Annex ()
|
||||
scanUnlockedFiles = whenM (inRepo Git.Ref.headExists) $ do
|
||||
Database.Keys.runWriter $
|
||||
liftIO . Database.Keys.SQL.dropAllAssociatedFiles
|
||||
(l, cleanup) <- inRepo $ Git.LsTree.lsTree Git.LsTree.LsTreeRecursive Git.Ref.headRef
|
||||
|
|
@ -91,15 +92,18 @@ scanUnlockedFiles replacefiles = whenM (inRepo Git.Ref.headExists) $ do
|
|||
let tf = Git.LsTree.file i
|
||||
Database.Keys.runWriter $
|
||||
liftIO . Database.Keys.SQL.addAssociatedFileFast k tf
|
||||
whenM (pure replacefiles <&&> inAnnex k) $ do
|
||||
whenM (inAnnex k) $ do
|
||||
f <- fromRepo $ fromTopFilePath tf
|
||||
destmode <- liftIO $ catchMaybeIO $ fileMode <$> getFileStatus f
|
||||
ic <- replaceFile f $ \tmp ->
|
||||
linkFromAnnex k tmp destmode >>= \case
|
||||
LinkAnnexOk ->
|
||||
withTSDelta (liftIO . genInodeCache tmp)
|
||||
LinkAnnexNoop -> return Nothing
|
||||
LinkAnnexFailed -> liftIO $ do
|
||||
writePointerFile tmp k destmode
|
||||
return Nothing
|
||||
maybe noop (restagePointerFile (Restage True) f) ic
|
||||
liftIO (isPointerFile f) >>= \case
|
||||
Just k' | k' == k -> do
|
||||
destmode <- liftIO $ catchMaybeIO $ fileMode <$> getFileStatus f
|
||||
ic <- replaceFile f $ \tmp ->
|
||||
linkFromAnnex k tmp destmode >>= \case
|
||||
LinkAnnexOk ->
|
||||
withTSDelta (liftIO . genInodeCache tmp)
|
||||
LinkAnnexNoop -> return Nothing
|
||||
LinkAnnexFailed -> liftIO $ do
|
||||
writePointerFile tmp k destmode
|
||||
return Nothing
|
||||
maybe noop (restagePointerFile (Restage True) f) ic
|
||||
_ -> noop
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
git-annex (7.20191025) UNRELEASED; urgency=medium
|
||||
|
||||
* init: Fix bug that lost modifications to unlocked files when init is
|
||||
re-ran in an already initialized repo.
|
||||
* benchmark: Add --databases to benchmark sqlite databases.
|
||||
* Add some missing indexes to sqlite databases. This will speed up
|
||||
some things involving export and import remotes, and git-annex smudge.
|
||||
|
|
|
|||
|
|
@ -42,13 +42,10 @@ upgrade automatic = flip catchNonAsync (const $ return False) $ do
|
|||
( do
|
||||
checkGitVersionForDirectUpgrade
|
||||
convertDirect
|
||||
-- Worktree files are already populated, so don't
|
||||
-- have this try to populate them again.
|
||||
scanUnlockedFiles False
|
||||
, do
|
||||
checkGitVersionForIndirectUpgrade
|
||||
scanUnlockedFiles True
|
||||
)
|
||||
scanUnlockedFiles
|
||||
configureSmudgeFilter
|
||||
-- Inode sentinal file was only used in direct mode and when
|
||||
-- locking down files as they were added. In v6, it's used more
|
||||
|
|
|
|||
|
|
@ -0,0 +1,43 @@
|
|||
[[!comment format=mdwn
|
||||
username="yarikoptic"
|
||||
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
|
||||
subject="the issue persists"
|
||||
date="2019-11-01T18:12:27Z"
|
||||
content="""
|
||||
Ran into the same problem again, and it is not clear to me either connection caching is enabled or not (and why?):
|
||||
|
||||
[[!format sh \"\"\"
|
||||
[d31548v@discovery7 bids]$ git -c annex.sshcaching=true annex --debug get -J2 --from=origin sub-sid000005
|
||||
[2019-11-01 14:10:56.178577] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
|
||||
[2019-11-01 14:10:56.475956] process done ExitSuccess
|
||||
[2019-11-01 14:10:56.47622] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
|
||||
[2019-11-01 14:10:56.836271] process done ExitSuccess
|
||||
[2019-11-01 14:10:56.865928] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..8a694d5c54eb81b1e5c5446fa63bdcd13daa34b3\",\"--pretty=%H\",\"-n1\"]
|
||||
[2019-11-01 14:10:57.229787] process done ExitSuccess
|
||||
[2019-11-01 14:10:57.234655] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
|
||||
[2019-11-01 14:10:57.23592] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
|
||||
[2019-11-01 14:10:57.546203] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"symbolic-ref\",\"-q\",\"HEAD\"]
|
||||
[2019-11-01 14:10:57.780246] process done ExitSuccess
|
||||
[2019-11-01 14:10:57.780454] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"refs/heads/master\"]
|
||||
[2019-11-01 14:10:58.097345] process done ExitSuccess
|
||||
[2019-11-01 14:10:58.09754] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"sub-sid000005\"]
|
||||
[2019-11-01 14:10:58.298181] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
|
||||
[2019-11-01 14:10:58.29998] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
|
||||
[2019-11-01 14:10:58.305022] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
|
||||
[2019-11-01 14:10:58.306024] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
|
||||
[2019-11-01 14:10:58.62005] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
|
||||
[2019-11-01 14:10:58.621714] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
|
||||
[2019-11-01 14:10:58.632596] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
|
||||
[2019-11-01 14:10:58.6338] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\"]
|
||||
get sub-sid000005/ses-actions1/fmap/sub-sid000005_ses-actions1_acq-25mm_magnitude2.nii.gz get sub-sid000005/ses-actions1/fmap/sub-sid000005_ses-actions1_acq-25mm_magnitude1.nii.gz (from origin...) (from origin...)
|
||||
[2019-11-01 14:10:59.489719] chat: ssh [\"yohtest@rolando.cns.dartmouth.edu\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/Haxby/Sam/1021_actions' '--debug' 'fd3f7af9-cf7d-4d7e-8efd-30e6bedf838d' --uuid d839134c-3afe-4456-920a-e280ce0fdf2a\"]
|
||||
|
||||
[2019-11-01 14:10:59.553029] chat: ssh [\"yohtest@rolando.cns.dartmouth.edu\",\"-T\",\"git-annex-shell 'p2pstdio' '/inbox/BIDS/Haxby/Sam/1021_actions' '--debug' 'fd3f7af9-cf7d-4d7e-8efd-30e6bedf838d' --uuid d839134c-3afe-4456-920a-e280ce0fdf2a\"]
|
||||
yohtest@rolando.cns.dartmouth.edu's password: yohtest@rolando.cns.dartmouth.edu's password:
|
||||
|
||||
|
||||
[d31548v@discovery7 bids]$ git annex version
|
||||
git-annex version: 7.20191024-g6dc2272
|
||||
\"\"\"]]
|
||||
Could you hint me on what/where to dig?
|
||||
"""]]
|
||||
41
doc/bugs/Make_webapp_port_configurable..pl
Normal file
41
doc/bugs/Make_webapp_port_configurable..pl
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
### Please describe the problem.
|
||||
This is more of a feature request then a bug.
|
||||
|
||||
It would be nice and more intuitive if the webapp --listen parameter accepted a port specifier too allowing configuration of the port.
|
||||
|
||||
For my workflow, I thought I would contain all of git annexes dependencies inside a docker image since I'm quite comfortable with docker(and emerge on gentoo took a long time and finally failed). With an unconfigurable dynamic port though, it makes running the webapp subcommand in docker not really viable since I don't want to use docker run's port range mapping feature which will lock all those ports.
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
Dockerfile:
|
||||
ARG DEBIAN_TAG=buster-slim
|
||||
FROM debian:${DEBIAN_TAG}
|
||||
|
||||
RUN set -ex \
|
||||
&& apt-get update \
|
||||
&& apt-get install -y \
|
||||
git \
|
||||
git-annex
|
||||
|
||||
docker build -t git-annex:test .
|
||||
docker run --rm -it git-annex:test git annex webapp --listen 0.0.0.0:8888
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
git-annex version: 7.20190129
|
||||
build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
|
||||
dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
|
||||
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
[[!format sh """
|
||||
# If you can, paste a complete transcript of the problem occurring here.
|
||||
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
|
||||
|
||||
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
|
||||
git annex seems awesome with the little bit of testing I've done. It seems like the perfect tool for what I want to accomplish. Thanks!
|
||||
|
||||
41
doc/bugs/Make_webapp_port_configurable..sh
Normal file
41
doc/bugs/Make_webapp_port_configurable..sh
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
### Please describe the problem.
|
||||
This is more of a feature request then a bug.
|
||||
|
||||
It would be nice and more intuitive if the webapp --listen parameter accepted a port specifier too allowing configuration of the port.
|
||||
|
||||
For my workflow, I thought I would contain all of git annexes dependencies inside a docker image since I'm quite comfortable with docker(and emerge on gentoo took a long time and finally failed). With an unconfigurable dynamic port though, it makes running the webapp subcommand in docker not really viable since I don't want to use docker run's port range mapping feature which will lock all those ports.
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
Dockerfile:
|
||||
ARG DEBIAN_TAG=buster-slim
|
||||
FROM debian:${DEBIAN_TAG}
|
||||
|
||||
RUN set -ex \
|
||||
&& apt-get update \
|
||||
&& apt-get install -y \
|
||||
git \
|
||||
git-annex
|
||||
|
||||
docker build -t git-annex:test .
|
||||
docker run --rm -it git-annex:test git annex webapp --listen 0.0.0.0:8888
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
|
||||
git-annex version: 7.20190129
|
||||
build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
|
||||
dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.0.0 ghc-8.4.4 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
|
||||
|
||||
|
||||
### Please provide any additional information below.
|
||||
|
||||
[[!format sh """
|
||||
# If you can, paste a complete transcript of the problem occurring here.
|
||||
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
|
||||
|
||||
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
|
||||
git annex seems awesome with the little bit of testing I've done. It seems like the perfect tool for what I want to accomplish. Thanks!
|
||||
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
### Please describe the problem.
|
||||
|
||||
Original report: https://github.com/datalad/datalad/issues/3825
|
||||
|
||||
|
||||
[[!format sh """
|
||||
$> git annex addurl --json --json-error-messages s3://hcp-openaccess/HCP_1200/100206/.xdlm/100206_3T_Diffusion_unproc.json
|
||||
Configuration does not allow accessing s3://hcp-openaccess/HCP_1200/100206/.xdlm/100206_3T_Diffusion_unproc.json
|
||||
download failed: Configuration does not allow accessing s3://hcp-openaccess/HCP_1200/100206/.xdlm/100206_3T_Diffusion_unproc.json
|
||||
{"command":"addurl","success":false,"error-messages":[],"file":null}
|
||||
git-annex: addurl: 1 failed
|
||||
|
||||
$> git annex version | head
|
||||
git-annex version: 7.20191009-1~ndall+1
|
||||
...
|
||||
"""]]
|
||||
|
||||
the reason for the failure overall is that `datalad` external special remote is not enabled. So the error message might also be considered misleading -- it is not about "allowing" but rather being "not supported" since AFAIK git-annex doesn't support s3:// urls (see [an existing issue](https://git-annex.branchable.com/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/))
|
||||
|
||||
If user convenience was something to strive for here, it should technically be possible for git annex to "sense" all available external special remotes and inquire them (without enabling) either they would support a given url, and then report to the user a more informative error message ("URL ... is not supported by git-annex. You can initialize one of the available external special remotes which support that url: datalad, somebodies-s3, ...". It could even check if the special remote is configured but not enabled and then replace "initialize" with "enable" in the message above).
|
||||
|
||||
[[!meta author=yoh]]
|
||||
[[!tag projects/datalad]]
|
||||
|
||||
|
|
@ -116,4 +116,4 @@ Shouldn't that URL be recorded in remote.log? (similarly to `type=git` remotes)
|
|||
[[!meta author=yoh]]
|
||||
[[!tag projects/dandi]]
|
||||
|
||||
> [[done]; see my comment --[[Joey]]
|
||||
> [[done]]; see my comment --[[Joey]]
|
||||
|
|
|
|||
|
|
@ -0,0 +1,14 @@
|
|||
[[!comment format=mdwn
|
||||
username="plasmastrike@66c1cae4abae92d03faf344111c446a1908981ff"
|
||||
nickname="plasmastrike"
|
||||
avatar="http://cdn.libravatar.org/avatar/2859d0b6fe78b2252c6fbf46ce02e85b"
|
||||
subject="Yggdrasill"
|
||||
date="2019-11-01T13:34:36Z"
|
||||
content="""
|
||||
You could use Yggdrasil and a Yggdrasil ipv6 address. It would allow you to ssh even if the ssh port is normally blocked. Think of Yggdrasil as dynamic reconfiguring vpn so all traffic goes through one port and encrypted.
|
||||
|
||||
https://yggdrasil-network.github.io/
|
||||
https://yggdrasil-network.github.io/2018/07/15/remote-access.html
|
||||
|
||||
You would still need ssh, rsync or an alternative to move the files but you will get past blocked ports
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="ghen1"
|
||||
avatar="http://cdn.libravatar.org/avatar/efd0e92b6198291138f0cd7aedbf86b6"
|
||||
subject="comment 5"
|
||||
date="2019-10-30T22:51:27Z"
|
||||
content="""
|
||||
I just wanted to report that I've successfully upgraded my repos without any problems. I appreciate everyone's help.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="bremner"
|
||||
avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
|
||||
subject="plz don't annex already committed files"
|
||||
date="2019-10-31T13:50:09Z"
|
||||
content="""
|
||||
I am suffering a bit at the moment from git-annex 7 annexing committed files and replacing them with pseudo symlinks. This breaks the file for v5 clients. What's the best way to disable this? I have annex.largefiles=100k, but a few files just a bit larger than that are commited to git.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="not annexing files already stored in git"
|
||||
date="2019-10-31T16:03:41Z"
|
||||
content="""
|
||||
\"a few files just a bit larger than that are commited to git\" -- if it's just a few, maybe set `annex.largefiles=nothing` explicitly for each of them in .gitattributes? (Also then set `annex.largefiles=(largerthan=100kb)` in .gitattributes rather than in git config, since that overrides .gitattributes). But in general it would be better if files already in git were not annexed even if they match `annex.largefiles`.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="annexing previously non-annexed files, and compatibility with v5"
|
||||
date="2019-10-31T16:19:39Z"
|
||||
content="""
|
||||
\"it would be better if files already in git were not annexed even if they match annex.largefiles\" -- actually not sure: what if a file was in git but gets modified to something _much_ larger? If you have \"a few files just a bit larger\" than your `annex.largefiles` setting, maybe just increase that setting? You could also set `annex.gitaddtoannex=false` to prevent `git add` from annexing previously non-annexed files, and use `git annex add` to annex new files.
|
||||
|
||||
Also, if goal is compatibility with v5, you can lock files after annexing. If [[todo/auto-lock_files_after_one_edit]] gets implemented at some point, that could also help this case.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="re: setkey"
|
||||
date="2019-10-28T22:12:51Z"
|
||||
content="""
|
||||
\"How can I trigger the (recording state in git...) after throwing in files with git -c annex.verify=false -c annex.alwayscommit=false annex setkey ...\" -- [[manpage|git-annex]] says \"You can later commit the data by running git annex merge (or by automatic merges) or git annex sync. You should beware running git gc when using this configuration, since it could garbage collect objects that are staged in git-annex's index but not yet committed.\" I myself was wondering if there is a more lightweight way of doing this.
|
||||
|
||||
\"Can setkey be used on multiple repositories for the same file and then have the file exists in multiple copies after this without an annex copy?\" -- I think setkey *moves* the file into annex? [[git-annex-import]] has a `--duplicate` flag to preserve the original, but setkey doesn't. Check out also [[tips/local_caching_of_annexed_files]] for how to use one annex as backing storage for several repos.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
[[!comment format=mdwn
|
||||
username="irieger"
|
||||
avatar="http://cdn.libravatar.org/avatar/83622f3c2fedea51e69f9a3986f95d73"
|
||||
subject="comment 5"
|
||||
date="2019-11-04T08:30:07Z"
|
||||
content="""
|
||||
Ok, thanks.
|
||||
|
||||
My second question was formulated not quite well. Of course I meant multiple checkouts of this one repository. That in the end is my use case that I have multiple checksum verified copies of all my images/movie clips in one go.
|
||||
|
||||
Did quite a bit of testing over the past weeks and stuff seams working well so far.
|
||||
|
||||
Here is a sample bash script I used to experiment that shows the workflow if anyone is interested. (Just an example, seems to do basically the same as git annex add $FILE as it is):
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
FILE=$1
|
||||
echo \"Adding file '$FILE'\"
|
||||
|
||||
HASH=$(sha256sum \"$FILE\" | sed 's/[^a-fA-F0-9].*//')
|
||||
SIZE=$(stat --printf=\"%s\" \"$FILE\")
|
||||
EXT=$(echo \"${FILE##*.}\" | tr '[:upper:]' '[:lower:]')
|
||||
KEY=\"SHA256E-s${SIZE}--${HASH}.${EXT}\"
|
||||
OBJECT=$(git annex examinekey $KEY --format='.git/annex/objects/${hashdirmixed}${key}/${key}')
|
||||
|
||||
echo \" ext: $EXT\"
|
||||
echo \" sha256: $HASH\"
|
||||
echo \" size: $SIZE\"
|
||||
echo \" KEY: $KEY\"
|
||||
echo \" OBJECT: $OBJECT\"
|
||||
|
||||
git -c annex.verify=false -c annex.alwayscommit=false annex setkey \"$KEY\" \"$FILE\"
|
||||
ln -s \"$OBJECT\" \"$FILE\"
|
||||
git add \"$FILE\"
|
||||
|
||||
Kind regards,
|
||||
Ingmar
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="comment 6"
|
||||
date="2019-11-04T16:40:52Z"
|
||||
content="""
|
||||
Great that it's working.
|
||||
|
||||
Not sure if relevant to your case, but one other way to have multiple checkouts of one repo is [[tips/Using_git-worktree_with_annex]]. Each checkout must be of a different branch though. On the plus side, they all share one annex, so there is only one copy of each annexed file (for locked files).
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="hobbes@b2cacef69071743c3a831e60511062f7e014e52f"
|
||||
nickname="hobbes"
|
||||
avatar="http://cdn.libravatar.org/avatar/44b70169c4d862b3619812c360aa8f1e"
|
||||
subject="Ssh config"
|
||||
date="2019-11-03T23:49:05Z"
|
||||
content="""
|
||||
I would look into `man ssh_config. You can set up hosts and specific identities for those hosts.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
[[!comment format=mdwn
|
||||
username="strmd"
|
||||
avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
|
||||
subject="comment 33"
|
||||
date="2019-10-29T20:01:01Z"
|
||||
content="""
|
||||
@joey,
|
||||
|
||||
Thanks for your reply. I certainly appreciate you giving your perspective and rationale, and you bring up several good points. I never intended for my comment to be hostile or harsh, and I'm sorry if it struck you that way.
|
||||
|
||||
I do believe you acted in the best of intentions, and going back through the devblog and documentation one can follow along and see how this change came about. So the bit about it being casually communicated, as I wrote, is in one sense absolutely false.
|
||||
|
||||
And yet, to me, a somewhat recent user (who still find aspects of git-annex and its inner workings hard to grasp at times), it appeared to happen without warning and came pretty much out of nowhere. As you note, there are several reasons for that, and I'm obviously responsible for making sure I understand the tools I use.
|
||||
|
||||
As you have touched upon on your personal blog, there are probably some lessons to learn here. I hope we can turn it into something constructive. And mostly, I hope we as a community can avoid putting you in this regrettable position again.
|
||||
|
||||
Finally, the solution you have come up with since my post, seems very, very good and should alleviate most, if not all, concerns.
|
||||
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
[[!comment format=mdwn
|
||||
username="Dwk"
|
||||
avatar="http://cdn.libravatar.org/avatar/65fade4f1582ef3f00e9ad6ae27dae56"
|
||||
subject="comment 34"
|
||||
date="2019-10-29T21:04:42Z"
|
||||
content="""
|
||||
@joey
|
||||
|
||||
First, thanks a lot for this solution, which seems to strike a good balance between various use-cases.
|
||||
|
||||
Second, I apologize for concluding my comment (which was intended as constructive…) on a too-strongly-worded disclaimer about how I'd felt when upgrading. I thought it would give you grounds for discarding my opinion (if you felt it wasn't well-founded) as that of a someone unthinkingly annoyed at seeing one's workflow changed. I certainly didn't intend to push you around in any way.
|
||||
"""]]
|
||||
|
|
@ -4,20 +4,27 @@ TODOs for DataLad
|
|||
[[!inline pages="todo/* and !todo/done and !link(todo/done) and
|
||||
(author(yoh) or author(mih) or author(ben) or author(yarikoptic) or author(kyle))" sort=mtime feeds=no actions=yes archive=yes show=0]]
|
||||
|
||||
Done
|
||||
----
|
||||
|
||||
<details>
|
||||
<summary>Done</summary>
|
||||
|
||||
[[!inline pages="todo/* and !todo/done and link(todo/done) and
|
||||
(author(yoh) or author(mih) or author(ben) or author(yarikoptic) or author(kyle))" feeds=no actions=yes archive=yes show=0]]
|
||||
|
||||
</details>
|
||||
|
||||
My bugs
|
||||
=======
|
||||
|
||||
[[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and
|
||||
(author(yoh) or author(mih) or author(ben) or author(yarikoptic) or author(kyle))" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]]
|
||||
|
||||
Fixed
|
||||
-----
|
||||
|
||||
|
||||
<details>
|
||||
<summary>Fixed</summary>
|
||||
|
||||
[[!inline pages="bugs/* and !bugs/done and link(bugs/done) and
|
||||
(author(yoh) or author(mih) or author(ben) or author(yarikoptic) or author(kyle))" feeds=no actions=yes archive=yes show=0 template=buglist]]
|
||||
|
||||
</details>
|
||||
|
|
|
|||
|
|
@ -69,3 +69,4 @@ Marius Konitzer,
|
|||
Ryan Rix,
|
||||
Svenne Krap,
|
||||
Jelmer Vernooij,
|
||||
Rian McGuire,
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
When using [[linked worktrees|tips/Using_git-worktree_with_annex]], the main tree is currently handled differently from the linked trees: "if there is change in the tree then syncing doesn't update git worktrees and their indices, but updates the checked out branches. This is different to the handling of the main working directory as it's either got updated or left behind with its branch if there is a conflict." Is there a reason for this? Could linked worktrees be treated same as main one?
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="yarikoptic"
|
||||
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
|
||||
subject="ACLs keep fighting back"
|
||||
date="2019-10-29T18:03:57Z"
|
||||
content="""
|
||||
I am getting back to tackle a datalad/git-annex usecase on one of such (nfs4 ACL) usecases, so if hooks are still the way to go, I will be ready to test ;-)
|
||||
"""]]
|
||||
|
|
@ -2,6 +2,9 @@ Collection of non-ideal things about git-annex's use of sqlite databases.
|
|||
Would be good to improve these sometime, but it would need a migration
|
||||
process.
|
||||
|
||||
The `sqlite` branch changes the databases, updating annex.version to 8.
|
||||
This todo documents the state of that branch.
|
||||
|
||||
* Database.Keys.SQL.isInodeKnown has some really ugly SQL LIKE queries.
|
||||
Probably an index would not speed them up. They're only needed when
|
||||
git-annex detects inodes are not stable, eg on fat or probably windows.
|
||||
|
|
@ -107,16 +110,10 @@ remaining todo:
|
|||
> situations, the next time an export is run, so should be ok.
|
||||
> But it might result in already exported files being re-uploaded,
|
||||
> or other unncessary work.
|
||||
> Keys (IKey, SFilePath)
|
||||
> rebuild with scanUnlockedFiles
|
||||
> Keys (IKey, SFilePath, SInodeCache)
|
||||
> Use scanUnlockedFiles to repopulate the Associated table.
|
||||
>
|
||||
> does that update the Content table with the InodeCache?
|
||||
>
|
||||
> But after such a transition, how to communicate to the old git-annex
|
||||
> that it can't use the databases any longer? Moving the databases
|
||||
> out of the way won't do; old git-annex will just recreate them and
|
||||
> start with missing data!
|
||||
>
|
||||
> And, what about users who use a mix of old and new git-annex versions?
|
||||
>
|
||||
> Seems this needs an annex.version bump from v7 to v8.
|
||||
> But that does not repopulate the Content table. Doing so needs
|
||||
to iterate over the unlocked files, filter out any that are modified,
|
||||
and record the InodeCaches of the unmodified ones. Seems that it would
|
||||
have to use git's index to know which files are modified.
|
||||
|
|
|
|||
|
|
@ -1 +1,7 @@
|
|||
When git introduces a breaking change, it prints a warning describing the change and saying "to turn off this warning set advice.warnaboutthis=false". This adds the hassle of setting the config (once, globally), but the reduced confusion might be worth it.
|
||||
|
||||
git also uses this mechanism to start warning of upcoming breaking changes in future versions, before these versions become current.
|
||||
|
||||
Another way to signal breaking changes can be to use some form of [semantic versioning](https://semver.org/) for git-annex versions, bumping the major version number to indicate incompatible changes. [[7.20190912|news/version_7.20190912]] would then be 8.20190912 . This would help when specifying [package dependencies](https://docs.conda.io/projects/conda-build/en/latest/resources/package-spec.html#package-match-specifications).
|
||||
|
||||
Of course, best is to avoid breaking changes, as @joeyh ultimately [[managed to do with v7|news/version_7.20191024]]. But they'll happen, and some people miss the [[current scheme for announcing them|forum/lets_discuss_git_add_behavior/#comment-727918fd9abda5445891f2022ac225c8]], so low-cost ways to extend the scheme might help.
|
||||
|
|
|
|||
Loading…
Reference in a new issue