Can we please stop the hg-vs-git discussion? We've established earlier that the capabilities of the DVCS itself (hg or git) are not a differentiator, and further he-said-she-said isn't going to change anybody's opinion.

What's left is preferences of core developers, possibly capabilities of the popular websites (though BitBucket vs. GitHub seems to be a wash as well), and preferences of contributors who aren't core developers (using popularity as a proxy). It seems the preferences of the core developers are mixed, while the preferences of non-core contributors are pretty clear, so we have a problem weighing these two appropriately.

Also, let's not get distracted by the needs of the CPython repo, issue tracker, and code review tool. Arguments about core developers vs. contributors for CPython shouldn't affect the current discussion.

Next, two of the three repos mentioned in Donald's PEP 481 are owned by Brett Cannon, according to the Contact column listed on hg.python.org. I propose to let Brett choose whether to keep these on hg.python.org, move to BitBucket, or move to GitHub. @Brett, what say you? (Apart from "I'm tired of the whole thread." :-)

The third one is the peps repo, which has python-dev@python.org as Contact. It turns out that Nick is by far the largest contributor (he committed 215 of the most recent 1000 changes) so I'll let him choose.

Finally, I'd like to get a few more volunteers for the PEP editors list, preferably non-core devs: the core devs are already spread too thinly, and I really shouldn't be the one who picks new PEP numbers and checks that PEPs are well-formed according to the rules of PEP 1. A PEP editor shouldn't have to pass judgment on the contents of a PEP (though they may choose to correct spelling and grammar). Knowledge of Mercurial is a plus. :-)

On Sun, Nov 30, 2014 at 4:50 PM, Donald Stufft <donald@stufft.io> wrote:

> On Nov 30, 2014, at 7:43 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
>
> Donald Stufft <donald@stufft.io> writes:
>
>> It’s not lost, [… a long, presumably-accurate discourse of the many
>> conditions that must be met before …] you can restore it.
>
> This isn't the place to discuss the details of Git's internals, I think.
> I'm merely pointing out that:
>
>> The important thing to realize is that a “branch” isn’t anything
>> special in git.
>
> Because of that, Ethan's impression – that Git's default behaviour
> encourages losing history (by re-writing the history of commits to be
> other than what they were) is true, and “Git never loses history” simply
> isn't true.
>
> Whether that is a *problem* is a matter of debate, but the fact that
> Git's common workflow commonly discards information that some consider
> valuable, is a simple fact.
>
> If Ethan chooses to make that a factor in his decisions about Git, the
> facts are on his side.

Except it’s not true at all.

That data is all still there if you want it to exist and it’s not a real
differentiator between Mercurial and git because Mercurial has the ability
to do the same thing. Never mind the fact that “lose” your history makes it
sound accidental instead of on purpose. It’s like saying that ``rm foo.txt``
will “lose” the data in foo.txt. So either it was a misunderstanding in
which case I wanted to point out that those operations don’t magically lose
information or it’s a purposely FUDish statement in which case I want to
point out that the statement is inaccurate.

The only thing that is true is that git users are more likely to use the
ability to rewrite history than Mercurial users are, but you’ll typically
find that people generally don’t do this on public branches, only on private
branches. Which again doesn’t make much sense in this context since generally
currently the way people are using Mercurial with CPython you’re using
patches to transfer the changes from the contributor to the committer so you’re
“losing” that history regardless.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA




--
--Guido van Rossum (python.org/~guido)