monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] git fast-export


From: Felipe Contreras
Subject: Re: [Monotone-devel] git fast-export
Date: Wed, 25 Feb 2009 21:37:18 +0200

On Tue, Feb 10, 2009 at 8:27 AM, Derek Scherger <address@hidden> wrote:
>
> On Mon, Feb 9, 2009 at 11:14 PM, Felipe Contreras
> <address@hidden> wrote:
>>
>> It's just that I don't like that behavior. It doesn't matter how smart
>> is the algorithm, it will always look like two messages instead of
>> one, which might be ok for some people, but not for other.
>
> What I was trying to do was to only use *one* of the two messages if they
> were identical so it shouldn't look like two messages at all.

But they are not identical.

>> In any case, the first error I got was with a revision that had a
>> change like this [merge 0123...] and another one like [merge
>> '0123...].
>
> In the case of merges it should be catching the fact that they have the same
> message and only including one of them. I guess if one of them has a quote
> and one doesn't it will fail though. It seems odd that you would be getting
> this and makes me wonder whether different monotone versions have had
> different automated messages in these cases. Can you post the *exact*
> contents of the message you're getting please?
>
> If it is the case that you have two slightly different automatically
> generated merge messages then this isn't going to handle that and I think
> the best thing to do in that case is keep all of the messages in the
> exported data, rather than losing information. If you don't like specific
> messages there's always the option of removing some things from the exported
> data before importing it which seems like it would generally be easier than
> adding things to the exported data that it doesn't contain.

I think it should be an option. Otherwise the people that want a
single message would have trouble running a git filter-branch command
to strip the message out. It would be much easier to do that in the
mtn export.

I don't know the exact commit id in the Pidgin repo, but I can assure
you, it's there.

>> > Yes. Git doesn't like authors without a email address wrapped in < and >
>> > so
>> > you need to put these in the --authors-file mappings.
>>
>> Why not? I thought '<unknown>' was ok.
>
> '<unknown>' is only used when there are no author certs, not when some
> author cert is not found in the author map. If there is an author cert with
> no <email> then git won't like it. Another option would be to require these
> values to exist in the author map or replace them with <unknown> as you seem
> to be suggesting.

I'm sorry, I can't recall what specifically we where discussing but I
think it should work this way:

no author cert: '<unknown>'
user_id not mapped: '<user_id>'
user_id mapped: obvious

Anyway, I've been able to reach a little further and now I've finally
found a difference in the trees between your and my method. In
Pidigin's repo there's a commit
'3f1b3854a77850131531d1d6f19c44a0b9174107' that in my method some
files have exec flag off, and with your method it has the exec flag
on. Can you take a look?

Now I'm using a bit different method so I'll be able to test faster.

Cheers.

-- 
Felipe Contreras




reply via email to

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