On Tue, Feb 10, 2009 at 8:27 AM, Derek Scherger <[email protected]> wrote: > > On Mon, Feb 9, 2009 at 11:14 PM, Felipe Contreras > <[email protected]> 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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
