"Felipe Contreras" <[EMAIL PROTECTED]> writes: > On Sun, Aug 31, 2008 at 9:24 AM, Patrick Georgi <[EMAIL PROTECTED]> wrote: > > The only difference is that in git the changes in both branches of a > merge are 'already done' so you can't do them again. So I guess what > fast-import is doing is taking the changes strictly of the merge, and > then the rest of the files are taken from the parents.
The problem is defining what files were changed "strictly by the merge". I suspect this means files that were modified from the common ancestor in both parents, and thus needed "file merging" during the revision merge. You can identify such files in the output of get_revision; they are the ones that appear in both changesets. However, if the result of the file merge is identical to one of the parents (due to user choices during the file merge), then maybe it's not considered modified during the merge? So you have to look at the file ids, and compare them to the file ids in the parent revisions. I don't see an operation for that in mtn automate; it would be something like: mtn automate get_file_id <revision> <filename> or maybe (slightly faster): mtn automate get_corresponding_file_id <current_revision> <file_id> <revision> -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel