On 8/26/05, Eric W. Biederman <[EMAIL PROTECTED]> 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 - 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
