idea

doc/todo/force_star_topology_on_a_repository/comment_6_8bb1f37233055c53d98c73fed4224b50._comment

@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-03-29T21:23:09Z"
+ content="""
+An alternative way to get the same result would be for your centralized git
+repository to have a hook that filters unwanted uuids out of git-annex
+branch pushes.
+
+To do the filtering, you could use git-annex filter-branch.
+
+	git-annex filter-branch --all --include-key-information-for=$uuid \
+		--include-global-config --include-repo-config-for=$uuid
+
+That reads the current git-annex branch and outputs the hash of a filtered
+commit.
+
+For example, as a post-receive hook:
+
+	#!/bin/sh
+	uuid=06ba602a-afa8-11ec-a6b9-87c2c2ae9296
+	ref=$(git-annex filter-branch --all --include-key-information-for=$uuid \
+		--include-global-config --include-repo-config-for=$uuid)
+	git update-ref refs/heads/git-annex $ref
+	# Necessary since the git-annex branch has been changed
+	rm .git/annex/index
+
+This post-receive hook is suboptimal because there is a period of time
+before it finishes filtering where a pull will see the unfiltered git-annex
+branch. Although maybe that would be ok, since a later push of that
+information back would get filtered again.
+
+It would be better to use a git hook that let the information be filtered
+before it became active. Looking at githooks(5), the proc-receive hook may
+be able to do that. Not sure. To be used by such a hook, git-annex
+filter-branch would still need to see the information in a git-annex
+branch, so it might need to be run in a lightweight clone of the
+repository. Or, it might be possible to improve git-annex filter-branch
+to be able to filter a ref other than the git-annex branch.
+"""]]

doc/todo/force_star_topology_on_a_repository/comment_7_6b08f09f690f7791f59cb90db01c4cf0._comment

@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-03-29T21:49:26Z"
+ content="""
+But.. Using filter-branch like that seems like it would lead to a series of
+commits when no changes are really being made. 
+
+Consider a clone that has a git-annex branch with commit A.
+It pushes it to origin, which runs it through filter-branch,
+yeilding B. Then the clone pulls B, and git-annex merges B into A,
+yielding A'. If A contained nothing that got filtered out, A' and A
+have the same tree, but in any case they will be different commits.
+Then A' gets pushed, yielding B', and the clone pulls B', resulting in A'',
+and so on.
+
+A solution to that would be to check, after filtering, if the tree
+sha is the same as the local git-annex branch currently has, or had
+at a point in the recent past. If so, it can avoid updating the git-annex 
+branch at all, since no new information was received. 
+
+I think that would work both when there was nothing that got filtered out,
+and when there was. The only problem with it might be that since
+origin/git-annex would not be updated after a push, a subsequent push would
+waste a little bandwidth re-sending the local git-annex branch again.
+"""]]