[ANN] pidgin git import v5

[Felipe Contreras]

Hi,

On Mon, May 21, 2012 at 8:17 PM, Richard Laager <rlaager at wiktel.com> wrote:
> On Mon, 2012-05-21 at 18:02 +0200, Felipe Contreras wrote:
>> Some of these might be useless, and might make sense to strip them,
>> but they are there now.
>
> I see no harm in keeping them, and more data seems better than less.

In general yes, but Monotone-Date is useless for example (unless you
think 'mtn git_export' would have a bug regarding dates, but this was
tested quite extensively and would be very unlikely).

But in any case, I didn't notice any increase in the repository size,
so shouldn't be a problem.

>> In addition to that, I've used 'hg-git'[1] with a few hacks to convert
>> the repository to mercurial, preserving all the information (except
>> renames, but that shouldn't be hard to add).
>
> Nice!

The hack was quite easy; simply adding the branches by parsing the
first 'Monotone-Branch' text found. Since hg-git already has the
functionality of parsing extra data from git commits by reading a
'--HG--' section.

Probably a bigger hack would be needed to convert mtn/git ids to hg
ids, so I'm thinking on having the whole thing in a separate branch
with hacks and everything so it's easy to run. But to be honest, I'm
not willing to spend a lot of time on making the git->hg conversion
production ready, I mostly did that as a proof of concept.

>> convert the mtn ids in the commit messages to the relevant git ids.
>
> If you can finish those two items up, I see no reason we can't do the
> final migration.*

There's a few new authors that need mapping. Looks like nobody
followed my advice to keep author names consistent for the conversion.
I could probably do that quickly.

But since I haven't heard anything, I guess the conversion would be to
mercurial.

I want to reiterate that *there has not been any analysis* (or at
least any public one). Many projects have done these kinds of analysis
*on record*:

http://trac.adium.im/wiki/DistributedVersionControl
http://www.python.org/dev/peps/pep-0374/
http://code.google.com/p/support/wiki/DVCSAnalysis
http://blogs.atlassian.com/2011/02/moving_to_mercurial___why_we_did_it/

I don't agree with many points on these analyses, but at least they
are not afraid of making the reasons public and visible for future
reference.

Pidgin can certainly move forward without such analysis, but just
accept that fact (and when people in the future complain, you won't be
able to say you did your due diligence because there is/would be
hardly any proof of it).

> I'd like to finish author mapping the entire history, but if I can't get
> that done in time, let's not hold up the transition. So far, I haven't
> had much incentive to work on that, since other things were holding up
> the transition anyway.

If the switch was to git, this wouldn't be a problem. If it's to
mercurial, it would be unfortunate to not be able to finish this.

> * This is based on a quick read of your email. I haven't yet looked at
> the repositories output by the script.

As I say, the commit messages, authors, and the revision graph are OK,
as I compared them programmatically. I haven't checked the mercurial
branches, nor tags, but I can't foresee how there could be a problem
with them.

The comitters are missing though.

And the author names are mapped to git valid ones "Foo <unknown>" and so on.

== Keep git users in mind ==

Finally, I want to raise the fact that *even* if you switch to
mercurial, there will be people using git instead; there's various
ways in which one can interact with mercurial through git. It would be
best if there was an official git repository, and thus it would be
best to make the conversion as painless as possible; have proper
author names:

John Snow <john at snow.com> # OK
"John Snow <john at snow.com>" # not OK
John Snow # not OK
john at snow.com # not OK

But if you want to make the conversion to git painful, feel free to do so.

If git was chosen, I would expect a mercurial official repository as well.

Cheers.

-- 
Felipe Contreras