[ANN] pidgin git import v5

[Felipe Contreras]

On Wed, May 23, 2012 at 7:43 PM, Richard Laager <rlaager at wiktel.com> wrote:
> On Wed, 2012-05-23 at 14:28 +0200, Felipe Contreras wrote:
>> Since you skipped the relevant part, I'm just going to state it for
>> the record: the Pidgin project does *not* plan to have a publicly
>> available analysis for the rationale to moving to mercurial like other
>> projects have[1][2][3][4].
>
> This has been discussed publicly on the mailing list.

Discussed yes, analyzed in detail and carefully list the pros and cons
of each option--no.

> I think this thread has most to all of the points raised:
> http://pidgin.im/pipermail/devel/2011-January/010062.html

I have read that thread yet again, and these are all the points I see:

 * Adium uses hg
 * Instantbird used hg
 X hg supports subrepo (libpurple won't be splitted)
 X git branches are braindead (not substantaited)
 * git supports committer
 X TortoiseHg (TortoiseGit)
 X I prefer X (that's not an analysis)

These points are not summarized anywhere, and the closest thing to a
summary is this:
http://pidgin.im/pipermail/devel/2011-January/010083.html

Of course, there's no real summary of the points, just basically counting votes.

> Summary:
>
> We don't see huge differences between the two and would like to provide
> both repositories to accommodate the preferences of patch submitters.

So in summary there's no *real reason* for choosing mercurial, other
than more people like it.

> Given that, there's really only a question of which one is the
> "official" trunk. That decision affects "developers" (upstream
> committers) only, and most prefer Mercurial for some combination of A)
> it's what they're used to, B) they like its history model (especially
> branching) better, and/or C) they like the human interface with the tool
> better.

The "developers" have changed since the last voting, and would
continue to change, which is why it's important to come with a better
reason than "we liked monotone".

You can certainly leave that as your reason, I'm merely pointing out
that it's not a strong one, and many newcomers would find that easy to
criticize.

> Also (and this is a small advantage), both Adium and Instantbird use
> Mercurial. Adium, at least, has a copy of libpurple in their tree, so
> using the same repository format gives them the option to either rebase
> against our repository or, more likely, easily use it as a subrepo (what
> git calls a submodule). To be fair, if the "official" repository was
> git, they could use the hg mirror. But there is overlap in the sets of
> committers (at least Evan), so using the same format means that subset
> could immediately commit upstream.

You think they would use the *whole* pidgin repo as a subrepo
(including finch and whatnot?), I don't think so.

Moreover, Evan doesn't have to touch a git command, hg-git can keep an
internal git repository hidden from him, but even if Evan wants for
some reason to work in git for Pidgin, and hg for Adium, he could
easily do 'hg pull pidgin-git', 'hg push adium-hg' (using hg-git) so
really, getting rid of an extra command (hg pull), which he might end
up doing anyway if Pidgin was in hg, is a very very weak reason,
specially considering we are talking about a single person, and
specially considering that they most likely they are *not* going to
use a subrepo, so he would have to do a rebase of some kind anyway,
and specially since hg-git does it for him if he wants to.

And specially since in the past year Evan has done 3 commits, all in
the 'adium.1-4' branch, and basically just removing files, and one
tweak. I think it's fair to say his work is the other way around;
pushing Pidgin releases to Adium, and for that he doesn't need the
extra 'hg pull pidgin-git' command, he can just clone the official hg
mirror, and never touch git.

Both Adium and Instantbird could just use the official hg mirror as well.

>From any point of view this is not really a small advantage.

> In closing, again, the intention is to have a git mirror, so anyone who
> wants to use git can do so without needing to care that official commits
> go into Mercurial first.

The same applies to Mercurial users.

But lets see how the development would look like from the point of
view of a developer using the opposite mirror:

== hg ==

I clone the official hg mirror of git, I do some work, and I want to
push to the official repository; I just do 'hg push' as if it was an
hg repo.

Then I create a bookmark (hg "branches" don't make sense in git) I do
some work, and then I decide (along with Pidgin developers) that this
would make sense to keep as a branch in the official repo as well (say
'gtk3' branch); I just do 'hg push' as if it was an hg repo.

They would have absolutely no problems interacting with git, in fact,
they would probably never have to touch a git command, or have an
intermediary repo (hg-git hides it).

== git ==

I clone the official git mirror of hg, I do some work, and I want to
push; well, I have to go to my intermediary repo, if I don't have one
then I have to either clone my git repo with hg-git, or download the
official one. Then, I can pull from my git repo, and then I can do 'hg
push'.

But oh, wait, there's an extra head that I didn't see from git (git
doesn't have such concept, and I don't know what hg-git does in these
cases, but must likely just shows one head); well, now I have to merge
and push, even though I'm not familiar with hg, I would have to learn
some basic stuff at least.

Then I create a branch, I do some work, an then I decide to push this
branch to the official repo as well; well, now I'm in a bit of a
problem because I have to somehow mark all my commits with the special
'--HG--' mark to say all these commits are from the 'gtk3' branch (or
whatever). This can be easily done with 'git format-branch' but I
would need to write a the script that modifies the commit message, and
then make sure that these labels conform to what should be seen in
mercurial as branches, and I'm not wrecking havoc in the hg database.
And then if I want to continue working on that branch it would be a
nightmare.

Maybe it would be possible to write a script that tries to figure all
this out based on the topology of the graph, but such a script is
bound to have limitations and probably bugs.

I would be essentially forced to never create branches. Bookmarks
would probably be OK.

They would have all sorts of problems interacting with mercurial, and
they will have to do hg commands, and be familiar with mercurial no
matter what.

Go ahead, install hg-git, clone a git repo, and interact with it in
any way you want (other than "branches" and tags), push, pull,
whatever.

This is alone would be a much more strong advantage than any of the
ones I've heard in favor of mercurial, that, and the support for
committer. Plus it has better performance, smaller footprint, faster
cloning time (even through the network). And I said; support for
grafts, so you would be able to fix the old commits any time you want.

These are the kinds of things a true analysis would expose.

Cheers.

-- 
Felipe Contreras