[ 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:
>
> Is there a convention of where/how it is safe to store additional
> (non-git) data in $GIT_DIR?
There's no convention, but I have a suggestion.
> The arch import needs to keep a cache with arch-commit-id =
> git-commit-id mappings, and some notes about what patch-trading Arch
> recorded. It'd be great to be able to store those in
> $GIT_DIR/archimport/ . Is that supported?
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
