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.
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.
> 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.