On Sun Nov 30 2014 at 8:25:25 PM Guido van Rossum <gu...@python.org> wrote:
> 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. > +1 from me as well. I view this as a discussion of platforms and not DVCSs. > > 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." :-) > You do one or two nice things for python-dev and you end up being saddled with them for life. ;) Sure, I can handle the devguide and devinabox decisions since someone has to and it isn't going to be more "fun" for someone else compared to me. > > 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. > "Perk" of all those packaging PEPs. > > 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. > :-) > And based on how Nick has been talking, will continue to be at least in the medium term. =) -Brett > > On Sun, Nov 30, 2014 at 4:50 PM, Donald Stufft <don...@stufft.io> wrote: > >> >> > On Nov 30, 2014, at 7:43 PM, Ben Finney <ben+pyt...@benfinney.id.au> >> wrote: >> > >> > Donald Stufft <don...@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 >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > -- > --Guido van Rossum (python.org/~guido) >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
