Re: Storing state in $GIT_DIR

[ Junio, the fact that you can't script the initial commit with "git 
  commit" is _really_ irritating. ]

On Thu, 25 Aug 2005, Martin Langhoff wrote:

There's no convention, but I have a suggestion.

Git won't care, so it will work, but things like clone/pull etc also won't actually ever look there, so it will only work for that one repo.

Now, I have what I consider a clever idea (I've mentioned variations on it before), but it's entirely possible that people hate it.

The thing is, I think you _do_ want to revision-control the git-commit-id mappings, but at the same time, you do _not_ want to mess up the resulting git commit history with arch information.

The reason you want to revision-control them is that that way you get them on clones, and you can use push/pull to update them. And the reason you don't want to mess up the commit history is that it's just wrong and ugly.

The git solution to this (which nobody has ever _used_, but which technically is wonderful) is to have a "side branch" that does not share any commits (or files, for that matter) in common with the "real branch", and which is used to track any metadata. In fact, you can obviously have any number of side branches.

So that "metadata branch" is a real git branch in its own right, but it doesn't share the same root as the "normal" branch, and it's really totally independent: you can pull just the main branch (ie somebody who isn't arch-aware and has no reason to want the arch mappings), or you could pull just the metadata branch (for example, somebody who doesn't want to use git, but is trying to match up a git commit ID to whatever ID's arch uses).

The way to maintain a metadata branch is to have not only a different branch name (obviously), but also use a totally different index file, so that you can index both branches in parallell, and you don't actually need to check out one or the other.

Now, your arch import tools would then use the raw git commands explicitly to maintain the metadata branch. Every time you do an incremental import from an arch project, your import scripts would save away the mapping information into the metadata branch.

I'll make a _really_ stupid example for you, just to make this a bit more concrete:

	mkdir silly-example
	cd silly-example

	#
	# The normal "main branch": use regular git
	# infrastructure
	#
	git init-db
	echo "Hello" > file
	git update-cache --add file
	git commit -m "Main branch"

	#
	# The metadata branch: magic, very special stuff
	#
	echo "initial commit:" $(git-rev-parse HEAD) > .archdata
	GIT_INDEX_FILE=.git/archindex git-update-cache --add .archdata
	arch_index_tree=$(GIT_INDEX_FILE=.git/archindex git-write-tree)
	echo "arch index" | git-commit-tree $arch_index_tree > .git/refs/heads/arch-index

(Btw, the above example shows that the initial "git commit" won't take a "-m" flag, which is really irritating for scripts.)

Then do a "gitk --all", see the two different branches, and realize that the "arch-index" branch can now contain all the tracking information necessary to go back-and-forth.

		Linus