Recent comments posted to this site:

comment 17 360caa8972c2daa94044cc95188306e9
[[!comment Error: unsupported page format sh]]
Tue Feb 27 17:02:17 2024
comment 23 70dcb7e7ffdd14351adaf4c40ee7fdd0
[[!comment Error: unsupported page format hs]]
Tue Feb 27 17:02:17 2024
comment 3 e6ce9bb92c973350852c9498b7ffb50f
[[!comment Error: unsupported page format sh]]
Tue Feb 27 17:02:17 2024

@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.

Comment by joey Thu Feb 22 16:50:34 2024

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.

Comment by TTTTAAAx Thu Feb 22 08:34:47 2024

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.

Comment by beryllium Thu Feb 22 02:55:25 2024

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.

Comment by matrss Wed Feb 21 12:29:14 2024

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" ```

Comment by yarikoptic Thu Feb 15 22:05:12 2024

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.

Comment by joey Mon Feb 12 17:01:13 2024

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 $privatefiles 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.

Comment by yarikoptic Sun Feb 11 18:54:45 2024