Augie Fackler writes:
> There is no sacrifice [for git users moving to Mercurial] other
> than familiarity--and because Mercurial indeed has as simpler UI,
> closing the familiarity gap from Git to Mercurial is much easier
> than the other way around.
AFAIK it is still much easier to do the k
Mercurial is easier to use (for cases outside linux kernel development). It's
too bad the gravity of GitHub tends to override that.
-Mike
On 09/15/2015 05:20 PM, Chris Angelico wrote:
Looks like it's time I spun up my own hg, rather than using the 3.1.2
that ships with Debian.
＞ sudo pip i
On Sep 16 2015, Chris Angelico wrote:
> On Wed, Sep 16, 2015 at 5:44 AM, Augie Fackler wrote:
>>> but git is still better at it: ``git add -p``
>>> allows me to review and edit patches before commit while ``hg record``
>>> commits immediately.
>>
>> FWIW, I totally *get* wanting a staging area. T
Chris Angelico gmail.com> writes:
>
> On Wed, Sep 16, 2015 at 5:44 AM, Augie Fackler durin42.com> wrote:
> >> but git is still better at it: ``git add -p``
> >> allows me to review and edit patches before commit while ``hg record``
> >> commits immediately.
> >
> > FWIW, I totally *get* wanting
On 16 Sep 2015 7:43 am, "Larry Hastings" wrote:
>
>
> I don't follow. Because you're an advocate of Python switching to git
and GitHub, we should have a git tutorial committed as a Python Enhancement
Proposal?
>
> I'm not attempting to stir up a conversation about git vs hg. I only
question the
On Wed, Sep 16, 2015 at 5:44 AM, Augie Fackler wrote:
>> but git is still better at it: ``git add -p``
>> allows me to review and edit patches before commit while ``hg record``
>> commits immediately.
>
> FWIW, I totally *get* wanting a staging area. That said, other than the
> staging area, recor
On Tue, Sep 15, 2015 at 10:41:54PM +0100, Larry Hastings
wrote:
>
> I don't follow. Because you're an advocate of Python switching to
> git and GitHub, we should have a git tutorial committed as a Python
> Enhancement Proposal?
>
> I'm not attempting to stir up a conversation about git vs hg.
I don't follow. Because you're an advocate of Python switching to git
and GitHub, we should have a git tutorial committed as a Python
Enhancement Proposal?
I'm not attempting to stir up a conversation about git vs hg. I only
question the idea that a git tutorial should be a PEP, when it ha
Oleg Broytman phdru.name> writes:
>
> Hi!
Hi! I work on Mercurial. I’ve got some inline responses, but I want to
summarize and put this in context for those without much energy for the topic.
There are a lot of reasons to prefer one tool over another. Common ones are
familiarity, simplicity, a
On Tue, 15 Sep 2015 20:32:33 +0200, Georg Brandl wrote:
> On 09/15/2015 08:22 PM, Guido van Rossum wrote:
> > For one, because *I* have been a (moderate) advocate for switching to git
> > and
> > GitHub.
>
> Fair enough. Still strange to read this PEP with the explicit caveat of
> "The author of
On Tue, Sep 15, 2015 at 08:32:33PM +0200, Georg Brandl wrote:
> Fair enough. Still strange to read this PEP with the explicit caveat of
> "The author of the PEP doesn't currently plan to write a Process PEP on
> migration Python development from Mercurial to git."
I am not a member of the core
Fair enough. Still strange to read this PEP with the explicit caveat of
"The author of the PEP doesn't currently plan to write a Process PEP on
migration Python development from Mercurial to git."
Georg
On 09/15/2015 08:22 PM, Guido van Rossum wrote:
> For one, because *I* have been a (moderate)
For one, because *I* have been a (moderate) advocate for switching to git
and GitHub.
On Tue, Sep 15, 2015 at 11:19 AM, Georg Brandl wrote:
> On 09/15/2015 08:02 PM, Oleg Broytman wrote:
> > On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson <
> benja...@python.org> wrote:
> >> This loo
On 09/15/2015 08:02 PM, Oleg Broytman wrote:
> On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson
> wrote:
>> This looks like good information, but why is it a PEP? If anything, the
>> devguide was probably be more appropriate. But even that's strange
>> considering we don't use git at t
I am used to looking in
HKLM:\SOFTWARE\Python\PythonCore\%(py_maj)d.%(py_min)d\InstallPath
to find out where python is installed so that my installation kit can add
itself to site-packages.
I just found that the registry key used for 32 bit python 3.5 on windows
changed to be '3.5-32',
which I
On Tue, Sep 15, 2015, at 11:02, Oleg Broytman wrote:
> On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson
> wrote:
> > This looks like good information, but why is it a PEP? If anything, the
> > devguide was probably be more appropriate. But even that's strange
> > considering we don't
On Tue, Sep 15, 2015 at 09:46:55AM -0700, Benjamin Peterson
wrote:
> This looks like good information, but why is it a PEP? If anything, the
> devguide was probably be more appropriate. But even that's strange
> considering we don't use git at the moment.
Exactly because the core team doesn't
This looks like good information, but why is it a PEP? If anything, the
devguide was probably be more appropriate. But even that's strange
considering we don't use git at the moment.
On Sat, Sep 12, 2015, at 06:56, Oleg Broytman wrote:
> On Sat, Sep 12, 2015 at 03:54:51PM +0200, Oleg Broytman
> w
Hello!
On Sat, Sep 12, 2015 at 03:54:51PM +0200, Oleg Broytman wrote:
> Title: Collecting information about git
The PEP is assigned number 103:
https://www.python.org/dev/peps/pep-0103/
I added a section "Branching models".
Oleg.
--
Oleg Broytmanhttp://phdru.name/
On Tue, Sep 15, 2015 at 12:17:00PM +0300, Serhiy Storchaka
wrote:
> On 15.09.15 04:21, barry.warsaw wrote:
> >https://hg.python.org/peps/rev/e275c4cd4b44
> >changeset: 6059:e275c4cd4b44
> >user:Barry Warsaw
> >date:Mon Sep 14 21:21:40 2015 -0400
> >summary:
> > Move 13 -> 103
On 15.09.15 04:21, barry.warsaw wrote:
https://hg.python.org/peps/rev/e275c4cd4b44
changeset: 6059:e275c4cd4b44
user:Barry Warsaw
date:Mon Sep 14 21:21:40 2015 -0400
summary:
Move 13 -> 103
files:
pep-0103.rst | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
21 matches
Mail list logo
