Recent comments posted to this site:
Dug a little into implementing this.
One problem is that things like git annex dead look up a name
in the remote list, and then use the uuid of the returned remote.
But if remote foo has sameas=bar-uuid, then the remote in the remote
list that it looks up will have that uuid, and so the uuid that will
be marked as dead is almost certianly not the one that the user expected.
And the user can't pass the masked uuid of the sameas remote to git-annex
dead, because there will be no remote in the list with that uuid.
And for that matter, the user is not likely to know the masked uuid,
because things like git annex info won't display it..
Another gotcha is that the user might make remote B with sameas=A-uuid, and remote C with sameas=B-uuid. Which really needs to resolve to A-uuid, so it needs to do multiple lookups, but then a sameas loop becomes a problem.
Thanks for your reply.
One example is when working with scanned images and digitized sound recordings:
The original file names [unmodified] are needed to source which analog original they are paired with in an archival system beyond my control, but as I manually work with these files, the structure changes to [modified], which I'd like to be the repo's default state. So when new data arrives (via a remote) new files should be checked into the [unmodified] state with their original file names, and then be worked on in the [modified] state. I'd like this [unmodified] state to be singular, as opposed to checking out a specific commit for a specific subset of files.
Another, perhaps simpler, example is music files:
They come in various combinations of file and folder names as they are ripped from CD or downloaded. I'd like an external program (beets) to handle organizing these files (the symlinks, really) into a folder structure, as I need them to be presented in a particular way to an indexer/player, i.e. as [modified]. So again, I'd like to ingest (from a remote) into git-annex using the original file names (if needed at a later point) while still letting beets move things around structurally. At some point in time, I'd like to be able to easily hop back to my music library in its [unmodified] state without having to find the particular point in time when I added that particular subset.
I'm trying to achieve this with as little manual massaging as possible.
Metadata and views are a great option to have, but from what I understand not the right fit here.
This was long but I hope it made some sense.
Depends on how often and what "work" is done with the original filenames. Can you explain more what you are trying to do?
Perhaps you can use metadata/metadata views.. though this would give you the original filename as a directory, containing a file with the current filename. e.g. ~/annex/originalfilename.txt/currentfilename.txt
git add and git annex add do both behave the same on symlinks (at least, in indirect annexes).
They are just staged (then fixed on commit, if required).
curl -v shows the problem response
< Server: openresty/1.7.10.1
< Date: Wed, 10 Apr 2019 13:57:10 GMT
< Content-Type: application/octet-stream
< Content-Length: 773788987
< Connection: keep-alive
< Last-Modified: Mon, 11 Mar 2019 16:35:02 GMT
< ETag: "5c868e36-2e1f153b"
< Accept-Ranges: bytes
< Strict-Transport-Security: max-age=15768000; includeSubdomains;
< preload
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
It looks like the server is sending "preload" on its own line rather than being part of the Strict-Transport-Security header.
Just in case, I found another url that uses HSTS preload, and git-annex can download that:
joey@darkstar:~>curl -v -o foo https://www.torproject.org/ 2>&1 | grep preload
< Strict-Transport-Security: max-age=15768000; preload
joey@darkstar:~/tmp/c>git annex addurl https://www.torproject.org/
addurl https://www.torproject.org/
(to www.torproject.org_) ok
The web server is probably violating standard HTTP to some extent with that response. Of course, it's possible to parse the response less strictly and not fail on the malformed header. Still, fixing the web server is probably the fastest way to fix the immediate problem (as well as make HSTS preloading actually be used).
Issue filed on http-client, https://github.com/snoyberg/http-client/issues/398 with a prospective patch.
I don't see any changes to git-annex that can help with the problem, so I'll close this bug report.
Each - is matched against the set of refs accu‐
mulated so far. Any matching refs are removed
from the set.
It matches against the literal text of the ref that was added, so if you use "+*", it adds refs/heads/master, and then to remove that, you need "-refs/heads/master" not "-master". On the other hand, "+master:-master" results in "master" being added and then removed.
Clarified to mention that it matches by name; I suppose perhaps you were thinking it matches based on what sha1 the ref name resolves to. The reason it doesn't do that is that it would be surprising for "+foo:-master" to not include ref foo just because it happens to currently have the same sha1 as master does.
So I ran:
Which is fine, then:
And that is strange.
And that's what I expected. I'm lost as to what happened.