Re: [Monotone-devel] git fast-export

[Felipe Contreras]

On Fri, Feb 27, 2009 at 7:58 AM, Derek Scherger <address@hidden> wrote:
>
> On Wed, Feb 25, 2009 at 12:37 PM, Felipe Contreras
> <address@hidden> wrote:
>>
>> 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.
>
> Looking through the pidgin repo that I have here, there are several commits
> with multiple changelog's some of which consist of a single 'a' character.
> Selecting one of these arbitrarily is going to select the 'a' changelogs
> sometimes which I suspect is also not what you want, unless you're thinking
> of a different option that I am. As I recall what you wanted was an option
> to just grab one changelog and use that right? Maybe the longest changelog
> would be the best one to use? I see several other revisions with multiple
> distinct changelogs that seem like they would be good to preserve as well.
>
> I'm somewhat reluctant to add an option that does this because it does not
> seem like a general thing that anyone else will want and it seems like it
> will just move your problem around a bit. Instead of getting changelogs you
> don't want you'll be missing changelogs you do want.
>
> The other options here are to (1) filter the exported data and remove the
> messages you don't want or (2) delete the unwanted changelog certs from a
> copy of your monotone database and export from that. Both of these should be
> scriptable without too much trouble although Identifying the specific
> changelogs to drop will probably be rather tedious.

As I said, my objective is to generate git clone for people to
develop/follow/maintain instead of the mtn repo, in this case there no
need to have every single bit of information since the mtn repo would
still be available.

On the other hand, when a project moves away from mtn to git, then
your method makes more sense.

That's why I think it should be an option.

>> I don't know the exact commit id in the Pidgin repo, but I can assure
>> you, it's there.
>
> Oh I beleive you, but it still might be useful to see the actual real data
> and do something based on that. So, if you do come across the revision id,
> I'd still like to see it.

Sure, if I find it I'll let you know.

>> no author cert: '<unknown>'
>> user_id not mapped: '<user_id>'
>> user_id mapped: obvious
>
> The current code works mostly like this. In the unmapped case it only adds
> '<' and '>' when neither is present. There are monotone users who have their
> keys named like "User Name <address@hidden>" and adding another set of '<'
> and '>' around these wouldn't make much sense.

Ahh, right. In Pidgin all the userids are 'address@hidden' or just 'user'
so far but I think maybe in the latest commits they are doing as you
say. So yeah, your code makes sense.

>> 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?
>
> Good catch. The monotone checkout of this revision has execute bits on some
> files that the git checkout does not. I'll have to do some digging to see
> what's going wrong here.

I'm not exactly sure what you mean with this, but there's a bug in
'mtn update' that sometimes doesn't pick the correct exec flag. That's
why I'm doing a full 'mtn checkout'.

>> Now I'm using a bit different method so I'll be able to test faster.
>
> The latest monotone git_export code runs quite a bit faster as well. I can
> export the pidgin repo I have here in a little over an hour instead of the 5
> hours it was taking previously.

The problem is not your method, the problem is mine, which is
painfully slow, but it's needed for a bit-exact comparison. It's
tedious but hopefully the comparisons will soon be done.

Cheers.

-- 
Felipe Contreras