Re: Storing state in $GIT_DIR

[ebiederm@xmission.com (Eric W. Biederman)]

Martin Langhoff <martin.langhoff@gmail.com> writes:

> Hmmm. That repo is in sync, but there are no guarantees that they will
> travel together to a different repo. In fact, the push/pull
> infrastructure wants to push/pull one head at a time.
>
> And if they are not in sync, I have no way of knowing. Hmpf. I lie:
> the arch metadata could keep track of what it expects the last head
> commits to be, and complain bitterly if something smells rotten.
>
> let me think about it ;)


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.  

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

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.

With that structure you would just need to create a git-arch-rev-list
so you can get a list of which arch branches you already have.
And then a git-arch-push and a git-arch-pull should be just a matter
of finding the common ancestor and continuing along the branch until
you reach the head.  Handling all heads in an arch repository is a
little trickier but should not be too bad.

On the push side you can just treat git as an arch working directory 
and push changsets into the appropriate branch.  For branches that
do not have tla as the ancestor you can do the equivalent of
tla archive-mirror.

Changes can be merged on whichever side make sense.

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.  Arch can record that just the
changes from a single changset/patch were merged.  This happens all
of the time in the kernel tree when patches are merged.  The
interesting case for merge algorithms is when two maintainers merge
the same patches into separate branches and then the branches are
merged.  Does git have a good way of coping with that case?

On the simple side it for patch trading it might just be worth
treating them as a special git merge with just one parent in
the parents line and the real parent listed in the merge comment,
along with the original parents commit comment.  But that just
might be too ugly to think about.

How does StGit handle this?

Eric