Re: Storing state in $GIT_DIR

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Aug 26, 2005, 07:08 UTC
Message-ID: <46a038f90508260008d1013ea@mail.gmail.com>
In-Reply-To: <m17je9tcj0.fsf@ebiederm.dsl.xmission.com>

On 8/26/05, Eric W. Biederman <ebiederm@xmission.com> wrote:

> Thinking about it going from arch to git should be just a matter
> of checking sha1 hashes, possibly back to the beginning of the
> arch tree.

Yup, though actually replaying the tree to compute the hashes is something I just _won't_ do ;)

> Going from git to arch is the trickier mapping, because you
> need to know the full repo--category--branch--version--patch
> mapping.

My plan doesn't include git->arch support... yet...

> Hmm.  Thinking about arch from a git perspective arch tags every
> commit.  So the really sane thing to do (I think) is to create
> a git tag object for every arch commit.

Now I like that interesting idea. It doesn't solve all my problems, but is a reasonable mapping point. Will probably do it.

> With patch trading (Martin I think I know what you are refering to)
> arch does seem to have a concept that does not map very well to git,
> and this I think is a failing in git.

I won't get into _that_ flamewar ;)

My plan for merges is to detect when two branches up until what point branches are fully merged, and mark that in git -- because that is what git considers a merge. The rest will be known to the importer, but nothing else.

cheers,

martin