Re: [Monotone-devel] mtn2git issues

[Felipe Contreras]

On Sun, Aug 31, 2008 at 4:19 PM, Felipe Contreras
<address@hidden> wrote:
> On Sun, Aug 31, 2008 at 3:55 PM, Stephen Leake
> <address@hidden> wrote:
>> "Felipe Contreras" <address@hidden> writes:
>>
>>> On Sun, Aug 31, 2008 at 9:24 AM, Patrick Georgi <address@hidden> 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.
>
> Yes, I'm trying your suggestion right now.
>
> Good idea.
>
>> 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>
>
> Right now I'm fetching the whole contents of the file anyway, git
> would check if the file has changed or not.
>
> In order compare the file ids of a revision to the parents I would
> have to either a) keep the whole tree of every revision, or b) use
> get_file_id for the revision and both parents. I assume it would be
> more efficient to do b), but would 3 calls to get_file_id be more
> efficient than just grabbing the whole file contents?
>
> Maybe a get_revision_changes command would make sense; it does the 3
> get_file_id gets, makes the comparison and generates a stripped down
> version.

Ok, instead of generating the "right output" I modified git
fast-import to drop bad changes. It seems to work fine.

Best regards.

-- 
Felipe Contreras