Martin Langhoff <[EMAIL PROTECTED]> 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 - 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
