Martin Langhoff <[EMAIL PROTECTED]> writes: > 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 ;)
I guess if you have the tla branch names it won't be necessary. If you are careful how you do the import you can have two parallel imports of the same data and produce exactly the same git tree. That is largely why I care about a stable algorithm for the hashes. >> 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... One of my interests, and if I get the time to worry about it is to get a scm that is a sufficient superset of what other scms do so it can serve as a bidirectional gateway. git is fairly close to what is needed to implement that. Hmm. I wonder if a git metadata branch in general is sufficient to store information that does not map to git natively? >> 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 ;) <pouts> No flamewar </pouts> > 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. I looked at least back to the StGit announcement and it helped to clarify my thinking. A patch is equivalent to a branch with just one change. This makes cherry picking a single patch roughly equivalent to describing that patch as a single commit branch at the fork point from the common ancestor of the two branches, and then having the single commit merged. The fact that the original branch that was cherry picked from can really only be represented as a an graft. Like the original linux kernel history. The shortcoming I see in git-applypatch is that it doesn't attempt to find the original base of a patch and instead simply assumes it is against the current tree. There is a similar short coming in git-diff-tree where it reports the commit that you are on when take the diff, but it does not report the commit the diff is against. ...... Thinking a little more there is also a connection with reverting patches. Cherry picking changes from a branch may also be thought of as reverting all of the other changes from a branch and then merging the branch. The practical impact of all of these things is there a form that will allow future merges to realize the same change has already been applied so it can skip it the second time. Inter-operating with darcs, tla, quilt, and raw diff/patch brings up these issues. So my practical questions are: - What information can a current git merge algorithms and more sophisticated merge algorithms use to avoid having conflicts when the same changes are merged into the same branch multiple times? - Is the git meta data sufficient to represent the history sophisticated merge algorithms can use. - Is the git meta data sufficient to represent the result of sufficient meta data operations. - Is the current representation of a reverted change sufficient for the merge algorithms, or could they do a better job if they new a change was revert of a previous change. I'm just trying to think through the issues that working with patch based systems bring up. 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
