Merge branch 'master' of ssh://git-annex.branchable.com

doc/todo/Support___40__globally_configured__41_____34__annex_init__34___hooks.mdwn

@@ -0,0 +1,5 @@
+The idea is stemmed from discussions/problems with using freeze/thaw hooks, and in particular [line of thinking in the comment on specify_freeze__47__thaw_scripts_relative_to_topdir](https://git-annex.branchable.com/todo/specify_freeze__47__thaw_scripts_relative_to_topdir/#comment-c71b25bbd0e3f018e07812965bd6a5b1).  ATM `git-annex` does analysis of either repository needs any special handling (adjusted branch, pidlock, etc) during `annex init` and otherwise does not bother.  It would make sense to make it possible for a user to also be able similarly to 
+
+- test e.g. if custom freeze/thaw are needed (before even git annex decides to switch to adjusted branches mode) and setup that repo accordingly for git-annex to proceed without flipping out into adjusted branch mode
+- may be improved/custom pidlock detection (on one of my servers I remember needing to just hardcode in ~/.gitconfig to use pidlock although that was relevant only for some paths).
+- similarly do some other testing which could allow or disallow some git-annex decision such as e.g. use of adjusted unlocked branch

doc/todo/Support___40__globally_configured__41_____34__annex_init__34___hooks/comment_1_60c69b1e48aba5afa6fd81f285321e89._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2025-01-07T16:09:31Z"
+ content="""
+I even wonder if there could be some easy way to setup overall hook for `git-annex` invocation within a repo (hence within `.git/` of a repo) to e.g. safe-guard invocations of git-annex and prevent use within container environments (we often run into various problems).  So smells to me like developing some kind of `.git/annex/hooks/` support analog to `.git/hooks`.  Then whatever global `annex init` hook would setup for a repo within its `.git/annex/hooks` would be in effect for subsequent `annex` invocations within containers or natively.
+
+Other desired use-cases could be to prevent invocation of git-annex with known critical for that deployment defects/absent features (e.g. absent support of freeze/thaw scripts or some other recent feature).
+"""]]

doc/todo/git-annex-cat/comment_6_6d6fd092fd58c59d633b9ee381264328._comment

@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Doable8234"
+ avatar="http://cdn.libravatar.org/avatar/b0d5fea745f92c3b8cc8ecc3dafa6278"
+ subject="comment 6"
+ date="2025-01-07T02:11:33Z"
+ content="""
+Joey, I recently came across this same usecase. There are some intermediate files I store using git annex safely in the cloud and I want to fetch it. 
+
+Doing a `git annex get` and a drop seems like the wrong solution. Why am I unnecessarily adding risk when I know I don't care about whether the file currently exists in my repo? I then have to think about various cases like if I already had the file in my repo or not and be very careful. I can't just do a `git annex get; cat; git annex drop`.
+
+I could use a pull-only-clone of my git annex repo, but that comes with many issues and usage hassles like reconfiguring everything. On top of this, I'd sometimes need to do a `git annex drop --force` in my clones since they may not have access to everything that the main repo does which is even more scary.
+
+Your concerns [here](http://git-annex.branchable.com/todo/git-annex-cat/#comment-8ca717fcdeadb1c2413da1f82d3659c6) make sense to me. However, streaming vs downloading is just an optimization. I'm HAPPY to pay the performance cost which is much better than the safety cost I'm currently facing with my hacky solutions to this problem. All we need (from my meager understanding of git annex internals) is to have the `git annex cat` command download the contents on to a temporary file (in the literal `/tmp` directory) instead of the `annex/objects` directory, and then `cat` that at the end. That's pretty much all I (we?) am asking for. 
+
+I do know that you like to do things perfectly and I'm sure there'll be lots of issues with the proposal here that you can see that the rest of us cannot. But that's true of solutions too. Really really hoping you can figure out a solution for this. I'm happy to try and help with the code changes too if that helps. I have never used haskell before but very happy to take that challenge if we can settle on a design.
+"""]]

doc/todo/specify_freeze__47__thaw_scripts_relative_to_topdir/comment_3_389e75ae6df3a379f0ae79f38ff444f9._comment

@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="may be %dotgit?"
+ date="2025-01-06T23:38:39Z"
+ content="""
+Original line of my thought was expressed in [this issue on github](https://github.com/dbic/handbook/issues/27).  
+One of the recent cases which made git-annex \"flip out\" into adjusted branch mode (yet to try to reproduce and follow up on [add_config_var_preventing_adjusted_branch_mode](https://git-annex.branchable.com/projects/datalad/bugs-done/add_config_var_preventing_adjusted_branch_mode/)), which happened when user executed datalad with git-annex inside a singularity container.
+To facilitate reproducibility etc, we are aiming to minimize effects of outside elements on execution within container so bind mount only current dataset and transfer only some [git / git-annex settings](https://github.com/ReproNim/containers/blob/master/scripts/singularity_cmd#L88).
+We could also check on paths for those scripts and bind mount them too. Also if relying on PATH, we would need somehow to ensure that inside the container PATH would point to them too (might be overridden by container's startup script since after all outside PATH might have little to do with inside -- think about running docker container on OSX).
+
+I think it would have been clean(er) if some initial invocation of current global git-annex freeze/thaw script which would potentially determine either it is needed or not at all (since some partitions might not need it, some need one kind, another - some other one), would instantiate in a given repository a copy of the specific freeze/thaw scripts tandem. But inability to specify relative path hinders that.  May be similarly to `%path` , it could have some `%dotgit` or alike variable to point to location of `.git` folder, and our \"freeze/thaw\" installation script populating values like `thawcontent-command = %dotgit/bin-annex/thaw-content %path`? I guess also could simply add treatment of leading `./` to signal being relative to `.git/` folder.  Such susbstitution would need to be done once upon reading that config setting per repo, there is no need to sense if script is there or not.  Since if not -- it better error out instead of proceeding forward with \"default\" behavior (which seems to be \"switch to adjusted branch\").
+
+
+"""]]