Recent comments posted to this site:
@TTTTAAAx kindly posted a full example of their problem, which I've moved to detect and handle submodules after path changed by mv.
I do think that using git mv
to rename directories that contain
submodules is the right way to avoid that kind of problem.
Note that renaming such a directory without using git followed by running
git add
on the new directory has the same behavior as running
git-annex assist
does. This is not a git-annex problem, but I think it
could be considered a git problem; git could make git add
of a moved
submodule do the right thing.
Sounds like you might want to use datalad, which is built around git annex and where submodules are a first-class citizen.
Datalad handles submodules as subdatasets and add python code layers on it to handle datasets(e.g. dedup submodules). But it doesn't detect the submodules path changed like git.
So, it doesn't do my needs sadly.
Is it possible to add git-lfs capabilities to a git-annex, without using a special remote?
I guess what I want is, are there any reasonable instructions to graft the hooks so that this is possible:
$ git init
$ git-lfs install
$ git-annex init
And you can alternate between something like below:
$ git-lfs track "*.exif_thumbnail.*"
$ git-annex add IMG_0001.jpg
$ git add IMG_0001.exif_thumbnail.jpg
Obviously this betrays the scenario of extracting thumbnails from the EXIF header and storing them alongside, as another form of metadata. If there's a better workflow to this, that would be appreciated too.
Is it possible to somehow make git annex whereis
show the response of the special remote to WHEREIS
over multiple lines? Just including newlines obviously results in an error, since that ends the WHEREIS-SUCCESS message.
I am implementing a special remote for which the data is fully described by what is essentially a json-encoded request to a third-party API, and I would like to show this json string pretty-printed over multiple lines in the whereis output, instead of as a single line.
Here is a script I crafted to use to make it easy and reuse current tree object for new "squashed history" commit
```bash
!/bin/bash
#
A helper to establish an alternative history to hide commits which could have
leaked personal data etc.
#
More information on motivation etc and another implementation could be
found at https://git-annex.branchable.com/tips/redacting_history_by_converting_git_files_to_annexed/
#
set -eu
BRANCH=$(git rev-parse --abbrev-ref HEAD) : "${SECRET_BRANCH:=unredacted-$BRANCH}" SAFE_BASE="$1"
git branch "${SECRET_BRANCH}"
rm -f .git/COMBINED_COMMIT_MESSAGE echo -e "Combined commits to hide away sensitive data\n" >> .git/COMBINED_COMMIT_MESSAGE git log --format=%B "$SAFE_BASE..HEAD" >> .git/COMBINED_COMMIT_MESSAGE
the tree we are on ATM
TREE_HASH=$(git log -1 --format=%T HEAD) NEW_COMMIT=$(git commit-tree $TREE_HASH -p "$SAFE_BASE" -F .git/COMBINED_COMMIT_MESSAGE) rm -f .git/COMBINED_COMMIT_MESSAGE git reset --hard $NEW_COMMIT
git replace "$BRANCH" "$SECRET_BRANCH" ```
Another note worthwhile making IMHO is that AFAIK those
git replace
markers are local only, and whoever has unredacted-master later on might need to set them up as well for their local clones to make such a "collapse" of histories
Right, any repository you fetch unredacted-master into, you will also want to fetch refs/redacted/ to as well, and run git replace there, as shown in the last code block of the tip above.
Thank you! In my case, since safe commit is too far in the past, what I had in mind is a little different: I wanted to have a completely disconnected history with a commit which had $privatefile
s moved to annex, but I think the approach is "the same" in effect.
The only thing I would do differently is to first convert files to git-annex in master
(to become unredacted-master
), so I end up with the same tree in unredacted-master
and master
happen that later I would need to cherry-pick some changes accidentally committed (e.g. by collaborators) on top of unredacted-master
.
Another note worthwhile making IMHO is that AFAIK those git replace
markers are local only, and whoever has unredacted-master later on might need to set them up as well for their local clones to make such a "collapse" of histories.