monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] mtn2git issues


From: Felipe Contreras
Subject: Re: [Monotone-devel] mtn2git issues
Date: Sun, 31 Aug 2008 16:19:52 +0300

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.

-- 
Felipe Contreras




reply via email to

[Prev in Thread] Current Thread [Next in Thread]