<div dir="ltr"><div><div><div><div>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.<br><br>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.<br><br></div>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.<br><br></div>Next, two of the three repos mentioned in Donald's PEP 481 are owned by Brett Cannon, according to the Contact column listed on <a href="http://hg.python.org">hg.python.org</a>. I propose to let Brett choose whether to keep these on <a href="http://hg.python.org">hg.python.org</a>, move to BitBucket, or move to GitHub. @Brett, what say you? (Apart from "I'm tired of the whole thread." :-)<br><br></div>The third one is the peps repo, which has <a href="mailto:python-dev@python.org">python-dev@python.org</a> 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.<br><br></div>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. :-)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 30, 2014 at 4:50 PM, Donald Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Nov 30, 2014, at 7:43 PM, Ben Finney <<a href="mailto:ben%2Bpython@benfinney.id.au">ben+python@benfinney.id.au</a>> wrote:<br>
><br>
> Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> writes:<br>
><br>
>> It’s not lost, [… a long, presumably-accurate discourse of the many<br>
>> conditions that must be met before …] you can restore it.<br>
><br>
> This isn't the place to discuss the details of Git's internals, I think.<br>
> I'm merely pointing out that:<br>
><br>
>> The important thing to realize is that a “branch” isn’t anything<br>
>> special in git.<br>
><br>
> Because of that, Ethan's impression – that Git's default behaviour<br>
> encourages losing history (by re-writing the history of commits to be<br>
> other than what they were) is true, and “Git never loses history” simply<br>
> isn't true.<br>
><br>
> Whether that is a *problem* is a matter of debate, but the fact that<br>
> Git's common workflow commonly discards information that some consider<br>
> valuable, is a simple fact.<br>
><br>
> If Ethan chooses to make that a factor in his decisions about Git, the<br>
> facts are on his side.<br>
<br>
</span>Except it’s not true at all.<br>
<br>
That data is all still there if you want it to exist and it’s not a real<br>
differentiator between Mercurial and git because Mercurial has the ability<br>
to do the same thing. Never mind the fact that “lose” your history makes it<br>
sound accidental instead of on purpose. It’s like saying that ``rm foo.txt``<br>
will “lose” the data in foo.txt. So either it was a misunderstanding in<br>
which case I wanted to point out that those operations don’t magically lose<br>
information or it’s a purposely FUDish statement in which case I want to<br>
point out that the statement is inaccurate.<br>
<br>
The only thing that is true is that git users are more likely to use the<br>
ability to rewrite history than Mercurial users are, but you’ll typically<br>
find that people generally don’t do this on public branches, only on private<br>
branches. Which again doesn’t make much sense in this context since generally<br>
currently the way people are using Mercurial with CPython you’re using<br>
patches to transfer the changes from the contributor to the committer so you’re<br>
“losing” that history regardless.<br>
<span class="im HOEnZb"><br>
---<br>
Donald Stufft<br>
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div>