Re: [Python-Dev] congrats on 3.5! Alas, windows 7 users are having problems installing it

[Giampaolo Rodola']

Same here. I get a "0x80240017 error" during installation.

On Sun, Sep 13, 2015 at 10:41 PM, Laura Creighton  wrote:

> webmaster has already heard from 4 people who cannot install it.
> I sent them to the bug tracker or to python-list but they seem
> not to have gone either place.  Is there some guide I should be
> sending them to, 'how to debug installation problems'?
>
> Laura
>
> ___
> 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/g.rodola%40gmail.com
>



-- 
Giampaolo - http://grodola.blogspot.com
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Chris Angelico]

On Wed, Sep 16, 2015 at 7:20 PM, Oleg Broytman  wrote:
>Thanks. I think upstream remote-tracking branches in git are rather
> similar. If one's afraid of rewriting published history she should never
> rebase before @{u}. Just always using ``git rebase -i @{u}`` should be
> good enough.
>The biggest difference here is that git doesn't stop one to rebase
> beyond @{upstream}.

Incidentally, "git rebase -i" with no argument defaults to rebasing
everything unpushed, which is exactly what you're talking about. But
yes, it's perfectly possible to rebase more than that, which I've done
extremely rarely but sufficiently often to appreciate it. Yes, there
are consequences. All magic comes with a price. But sometimes those
consequences are worth accepting.

With git, there are infinite workflows possible - you aren't forced to
have a concept of "central server" and "clients" the way you would
with SVN. Mercurial's called a DVCS too, so presumably it's possible
to operate on a pure-peering model with no central server at all; how
does that tie in with the inability to alter some commits?

ChrisA
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Nick Coghlan]

On 16 Sep 2015 18:48, "Paul Moore"  wrote:
>
> On 16 September 2015 at 06:10, Stephen J. Turnbull 
wrote:
> >   The only thing that hg really lost badly on
> > IMO was "named branches", and that's been fixed with bookmarks.
>
> FWIW, I still find bookmarks confusing to use compared to git
> branches. I don't know whether that's because bitbucket doesn't
> support them well,

It's BitBucket - their PR system for Mercurial primarily relies on named
branches rather than bookmarks. Gory details:
https://bitbucket.org/site/master/issues/6705/cant-create-pull-request-from-hg-bookmark

Regards,
Nick.
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Oleg Broytman]

On Wed, Sep 16, 2015 at 07:27:12PM +1000, Chris Angelico  
wrote:
> On Wed, Sep 16, 2015 at 7:20 PM, Oleg Broytman  wrote:
> >Thanks. I think upstream remote-tracking branches in git are rather
> > similar. If one's afraid of rewriting published history she should never
> > rebase before @{u}. Just always using ``git rebase -i @{u}`` should be
> > good enough.
> >The biggest difference here is that git doesn't stop one to rebase
> > beyond @{upstream}.
> 
> Incidentally, "git rebase -i" with no argument defaults to rebasing
> everything unpushed, which is exactly what you're talking about. But
> yes, it's perfectly possible to rebase more than that, which I've done
> extremely rarely but sufficiently often to appreciate it. Yes, there
> are consequences. All magic comes with a price. But sometimes those
> consequences are worth accepting.

   PEP 103 talks about consequences and price a lot, perhaps too much. :-)

> With git, there are infinite workflows possible - you aren't forced to
> have a concept of "central server" and "clients" the way you would
> with SVN. Mercurial's called a DVCS too, so presumably it's possible
> to operate on a pure-peering model with no central server at all; how
> does that tie in with the inability to alter some commits?

   Good question! In git, when you assign an upstream remote-tracking
branch (manually or automatically when cloning an existing repo) you're
essentially declare that remote the public repository on a per-branch
basis.

   But certainly there are distributed development scenarios where there
are no upstream remote-tracking branches at all. For example, I develop
SQLObject using two private clones (clean backup repo and dirty working
repo) and three public clones at Gitlab, GutHub and SourceForge. They
are all equal, none of them is the upstream. I don't even have
``origin`` remote - the origin was in Subversion.

> ChrisA

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Paul Moore]

On 16 September 2015 at 06:10, Stephen J. Turnbull  wrote:
>   The only thing that hg really lost badly on
> IMO was "named branches", and that's been fixed with bookmarks.

FWIW, I still find bookmarks confusing to use compared to git
branches. I don't know whether that's because bitbucket doesn't
support them well, or whether I don't know all the details of
bookmarks, but they just seem to get me in a muddle.

For example, my usual workflow is

(in a local clone of my fork on github)

git checkout -b featureX
... hack ...
git commit
git push -u origin featureX # Push the local branch to github and set
as remote tracking

# later, on a  different PC
git pull
git checkout featureX # Sets up a remote tracking branch
... hack ...
git commit
git push

# Finally, make a PR via the github UI

# Once the PR is accepted
git branch -d featureX # Remove my local branch, deleting all of the
no longer required changesets

I don't know of an equivalent of remote tracking branches in
Mercurial. Maybe bookmarks work that way by default? I seem to
remember that when I tried out bookmarks, bitbucket either didn't
support them, or did so pretty badly.

Also, my workflow involves 2 separate PCs, and I use my personal
github forks to share work in progress between them. Mercurial makes
it very difficult to edit "published" history, and I can't tell it
that my bitbucket repo doesn't count as "published" (as far as I
know). Git lets me do what I want (with some "are you sure?" prompts
when I force-push a rebased/edited branch, for example).

On the other hand, I *love* Mercurial queues. I'd happily use them for
work-in-progress editing as a replacement for some of my uses of git
branches. But they are essentially local-only, and it's basically not
practical to share them between my 2 PCs via bitbucket, as far as I
can tell. (I know you can version the patch queue, and share patch
queues on bitbucket, but it's under-documented and clumsy, whereas git
branches work exactly the same as they do locally...)

Having said all of this, the main reason I switched from Mercurial to
Git, like many others, was for github. Once I did, I learned how to do
a lot of things in git that I hadn't been able to do in Mercurial (it
was some time back, and they may not even have been possible, like
history editing) and now I find that even if Mercurial does have the
feature these days, the cost of learning how it works puts me off. So
my Mercurial use remains at the very basic "just enough to use it when
I have to" level.

Paul
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Oleg Broytman]

Hi!

On Tue, Sep 15, 2015 at 07:44:28PM +, Augie Fackler  
wrote:
> 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.

   Thank you!

> There are a lot of reasons to prefer one tool over another. Common ones are
> familiarity, simplicity, and power.

   Add here documentation, speed, availability of extensions and
3rd-party tools, hosting options (both locally installable and web
services).

> Oleg Broytman  phdru.name> writes:
> > With git we can have
> > per-directory .gitignore and .gitattributes.

   No per-directory .hgignore? Never? Quite useful in a big project
where subproject live in subdirectories and are developed by separate
teams.

> > tags point exactly to the commits they tag.
> 
> I'm chalking these up to personal taste, but know that the tagging behavior
> of git vs hg is a very complicated tradeoff. Mercurial chose a path that
> makes tags audit-able in the future, whereas in Git a tag could disappear
> and it'd be hard to prove.

   I think signed tags can help.

> >I learned commit editing and found that it was the thing I wanted so
> > badly in hg. When I started Mercurial was at version 1.7 and there was
> > no commit editing at all; there was ``hg rollback`` but it only could
> > undo one transaction.
> 
> Please forget rollback exists. It's dangerous, and we're hiding it from new
> users for a reason. :)

   Sure, I forgot them many years ago. ;-)

> > ``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, record (aka commit --interactive) and git add -p are identical
> functionality-wise.

   Functionality-wise - yes, but staging area still makes the process
much more convenient.

> > ``git log --grep=`` (and all related search options,
> > especially ``-G``)
> 
> Remember how I mentioned revsets replace a lot of Git command line flags?
> This is an example. hg help -r 'grep(foo)'.

$ hg help -r 'grep(foo)'
hg help: option -r not recognized
hg help [-ec] [TOPIC]

> See also `hg help revsets`,
> which are a very rich query system for revision history usable throughout
> mercurial rather than only in log.

   What is the flag for case-insensitive grep()? For git log -Gregex?

> > I don't
> > know what are the equivalent commands for ``git commit -c HEAD~``
> 
> hg commit --amend, or use hg histedit (which is like rebase -i)

   No, they are not the same. AFAIK there are no equivalent options for
``git commit -Cc``.

> >Git has a lot of good documentation.
> 
> Honestly so does Mercurial.

   It is harder to find. Mine installation has bash completion that
doesn't know "revsets" and "templates" though the help pages are there.
Actually it doesn't know much at all:

$ hg help [TAB][TAB]
add cat graft   log record  summary
addremove   clone   grepmanifestrecover tag
annotatecommit  heads   merge   remove  tags
archive config  helpoutgoingrename  tip
backout copyidentifyparents resolve transplant
bisect  diffimport  paths   revert  unbundle
bookmarks   export  incomingphase   rollbackupdate
branch  fetch   initpullrootverify
branchesforget  l5  pushserve   version
bundle  gloglocate  qrecord status

$ git help [TAB][TAB]
Display all 180 possibilities? (y or n)

   Another sign of git complexity. Sigh. :-(

> >As I stopped using Mercurial I do not understand what phases are.
> > they are phases of commit according to what? To the origin (let me
> > borrow the word from git terminology)?
> 
> Commits seen in the main public repository are marked as public, and
> Mercurial refuses to edit them. Most history rewriting woes happen when
> people rewrite widely shared history and force push the new version.
> Disallowing non-fast-forward push on the server prevents the rewriting from
> propagating unintentionally. Phases proactively prevent users from shooting
> themselves in the foot.
> 
> More details here https://www.logilab.org/blogentry/88203

   Thanks. I think upstream remote-tracking branches in git are rather
similar. If one's afraid of rewriting published history she should never
rebase before @{u}. Just always using ``git rebase -i @{u}`` should be
good enough.
   The biggest difference here is that git doesn't stop one to rebase
beyond @{upstream}.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 

Re: [Python-Dev] PEP: Collecting information about git

[Chris Angelico]

On Wed, Sep 16, 2015 at 7:46 PM, Oleg Broytman  wrote:
> For example, I develop
> SQLObject using two private clones (clean backup repo and dirty working
> repo) and three public clones at Gitlab, GutHub and SourceForge. They
> are all equal, none of them is the upstream. I don't even have
> ``origin`` remote - the origin was in Subversion.

Right. And even when you do have an 'origin' remote, you can pull from
anywhere else. (Internet connection's down? Pull from one computer
straight to another over the LAN. Want to quickly compare two messy
branches, without letting anyone else see them yet? Pull one of them
onto the other computer and poke around with fred/master and master.
Etcetera.) Deployment on Heroku can be done by setting up a remote and
then "git push heroku master". Does that make those commits
uneditable, or does "git push origin master" do that? I like the way
git lets you shoot yourself in the foot if you want to, while warning
you "your gun is currently pointing near your foot, please use --force
or --force-with-lease to pull the trigger".

But this is a bit off-topic for python-dev.

ChrisA
___
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

Re: [Python-Dev] PEP: Collecting information about git

[R. David Murray]

On Wed, 16 Sep 2015 19:59:28 +1000, Chris Angelico  wrote:
> On Wed, Sep 16, 2015 at 7:46 PM, Oleg Broytman  wrote:
> > For example, I develop
> > SQLObject using two private clones (clean backup repo and dirty working
> > repo) and three public clones at Gitlab, GutHub and SourceForge. They
> > are all equal, none of them is the upstream. I don't even have
> > ``origin`` remote - the origin was in Subversion.
> 
> Right. And even when you do have an 'origin' remote, you can pull from
> anywhere else. (Internet connection's down? Pull from one computer
> straight to another over the LAN. Want to quickly compare two messy
> branches, without letting anyone else see them yet? Pull one of them
> onto the other computer and poke around with fred/master and master.
> Etcetera.) Deployment on Heroku can be done by setting up a remote and
> then "git push heroku master". Does that make those commits
> uneditable, or does "git push origin master" do that? I like the way
> git lets you shoot yourself in the foot if you want to, while warning
> you "your gun is currently pointing near your foot, please use --force
> or --force-with-lease to pull the trigger".
> 
> But this is a bit off-topic for python-dev.

Yes is it, and no it isn't, if we are even thinking of moving to git.

My experience with DVCS started with bazaar, moved on to hg for the
CPython project, and finally git.  Through all of that I did not
understand the DAG, and had trouble wrapping my mind around what was
going on, despite being able to get things done.  I read a bunch of
documentation about all three systems, but it wasn't until I watched
another instructor teach the git DAG at a Software Carpentry workshop
that it all clicked.  Partially, I had been continually confused by the
concept of a "branch", since git uses that term differently than CVS,
svn, hg, or bazaar.  But once I understood it, suddenly everything
became clear.

The DAG plus git branches-as-labels *fits in my head* in a way that the
DAG plus named-branches-and-other-things does not.

I think that's really the key thing.  Sure, you can do the equivalent in
hg, but hg is not *oriented* toward that simple model.  git has a simple
model that my mind can wrap around and I can *reason about* easily.
Figuring out how feature branches and throwaway branches and remote
branches and pushes and pulls and workflows and whatever is all all just a
matter of reasoning about this simple model[*].

*That* I think is the key to git's success, *despite* its command line
API woes.  Not github, though github has magnified the effect.

The other key concept is what Chris talks about above, Mercurial's
"prevent me from shooting myself in the foot" stance versus git's "shoot
if you really want to" stance.

I think Mercurial is a great product, and has lots of really great
features, and I suspect that phases is a power tool that will enable
certain workflows that git won't support as well if at all.

But, I think Mercurial matches what we might call the "corporate"
mindset (prevent me from shooting myself in the foot) better than the
Python mindset.

Python strives to have a simple mental model you can reason about, and
it is a consenting adults language.  IMO, git matches the Python mindset
better than Mercurial does.

Now, does that mean that *the CPython project* should adopt git?  Not
necessarily.  CPython may be more like a big corporate project, where
centralized tracking of the main lines of development and not shooting
ourselves in the foot are the most important things :)

--David

[*] And then getting confused about how to *do* it in the CLI, but hey,
Google is my friend.
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Barry Warsaw]

On Sep 16, 2015, at 09:34 AM, R. David Murray wrote:

>My experience with DVCS started with bazaar, moved on to hg for the
>CPython project, and finally git.  Through all of that I did not
>understand the DAG, and had trouble wrapping my mind around what was
>going on, despite being able to get things done.  I read a bunch of
>documentation about all three systems, but it wasn't until I watched
>another instructor teach the git DAG at a Software Carpentry workshop
>that it all clicked.  Partially, I had been continually confused by the
>concept of a "branch", since git uses that term differently than CVS,
>svn, hg, or bazaar.  But once I understood it, suddenly everything
>became clear.

The O'Reilly book on Git by Loeliger & McCullough really crystallized the git
model for me.  I have the 2nd edition from 2012.  I struggled quite a bit with
the dvcs model when I first started using bzr *many* years ago now, and even
though I was comfortable with it by the time I mostly switched to git, it
wasn't an entirely smooth transition.  This book had some of the best
descriptions and diagrams about what was going on, and I still find that it's
a great first-stop when trying to do something out of the ordinary with git.
Call me old skool but looking up something in the index can be faster than
using da googles. :)

Cheers,
-Barry
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Augie Fackler]

Oleg Broytman  phdru.name> writes:

> 
> Hi!
> 
> On Tue, Sep 15, 2015 at 07:44:28PM +, Augie Fackler 
durin42.com> wrote:
> > 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.
> 
>Thank you!
> 
> > There are a lot of reasons to prefer one tool over another. Common ones are
> > familiarity, simplicity, and power.
> 
>Add here documentation, speed, availability of extensions and
> 3rd-party tools, hosting options (both locally installable and web
> services).
> 
> > Oleg Broytman  phdru.name> writes:
> > > With git we can have
> > > per-directory .gitignore and .gitattributes.
> 
>No per-directory .hgignore? Never? Quite useful in a big project
> where subproject live in subdirectories and are developed by separate
> teams.

I've honestly never found this a problem. Heck, I don't even know *how* I'd
go about configuring additional ignores in Google's enormous repository[0]
and it's never been a pain point to my knowledge. YMMV.

0: https://youtu.be/W71BTkUbdqE?t=193 for hard numbers that just got released.

> 
> > > tags point exactly to the commits they tag.
> > 
> > I'm chalking these up to personal taste, but know that the tagging behavior
> > of git vs hg is a very complicated tradeoff. Mercurial chose a path that
> > makes tags audit-able in the future, whereas in Git a tag could disappear
> > and it'd be hard to prove.
> 
>I think signed tags can help.

No, actually, they don't. Signed tags let you have a slightly stronger
assertion that the currently-tagged thing is what should be tagged, but it
does *not* provide any way of validating that the thing tagged 1.2 last week
is still the thing tagged 1.2. In Mercurial, you'd have the audit log of
.hgtags being edited in history, or else some hashes changing. In git, a ref
moves (even in the signed tag case!) and that's all. I think tags even move
automatically on fetch, so if you don't notice when you fetch you just lost
the evidence of tampering.

(This is admittedly quite paranoid, but keep in mind that for some projects
"motivated nation-state" is their attacker model, so detecting tampering on
this level might be of value.)

> 
> > > ``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, record (aka commit --interactive) and git add -p are identical
> > functionality-wise.
> 
>Functionality-wise - yes, but staging area still makes the process
> much more convenient.

For you. I find the staging area to merely get in my way. It's really a
matter of taste.

> 
> > > ``git log --grep=`` (and all related search options,
> > > especially ``-G``)
> > 
> > Remember how I mentioned revsets replace a lot of Git command line flags?
> > This is an example. hg help -r 'grep(foo)'.
> 
> $ hg help -r 'grep(foo)'
> hg help: option -r not recognized
> hg help [-ec] [TOPIC]

$ hg help -k grep
Topics:
  
 filesets Specifying File Sets
 revsets  Specifying Revision Sets

Commands:

 diff  diff repository (or selected files)
 files list tracked files
 grep  search for a pattern in specified files and revisions

You want revsets. help -k is your friend.

> 
> > See also `hg help revsets`,
> > which are a very rich query system for revision history usable throughout
> > mercurial rather than only in log.
> 
>What is the flag for case-insensitive grep()? For git log -Gregex?
> 
> > > I don't
> > > know what are the equivalent commands for ``git commit -c HEAD~``
> > 
> > hg commit --amend, or use hg histedit (which is like rebase -i)
> 
>No, they are not the same. AFAIK there are no equivalent options for
> ``git commit -Cc``.
> 
> > >Git has a lot of good documentation.
> > 
> > Honestly so does Mercurial.
> 
>It is harder to find. Mine installation has bash completion that
> doesn't know "revsets" and "templates" though the help pages are there.

Good point. http://bz.selenic.com/show_bug.cgi?id=4828 filed.

> Actually it doesn't know much at all:
> 
> $ hg help [TAB][TAB]
> add cat graft   log record  summary
> addremove   clone   grepmanifestrecover tag
> annotatecommit  heads   merge   remove  tags
> archive config  helpoutgoingrename  tip
> backout copyidentifyparents resolve transplant
> bisect  diffimport  paths   revert  unbundle
> bookmarks   export  incomingphase   rollbackupdate
> branch  fetch   initpullrootverify
> branchesforget  l5  pushserve   version
> bundle  gloglocate  qrecord status
> 
> $ git help [TAB][TAB]
> Display all 180 possibilities? (y or n)
> 
>Another sign of git complexity. Sigh. 
> 
> > 

Re: [Python-Dev] congrats on 3.5! Alas, windows 7 users are having problems installing it

[Brett Cannon]

I don't see any issue opened about Windows 7 installation issues, so if
someone who has had the issue can thus can help Steve diagnose the problem
that would be great (Steve is also currently on vacation so having this all
in a bug that he can read when he gets back would also help).

On Wed, 16 Sep 2015 at 02:27 Giampaolo Rodola'  wrote:

> Same here. I get a "0x80240017 error" during installation.
>
> On Sun, Sep 13, 2015 at 10:41 PM, Laura Creighton  wrote:
>
>> webmaster has already heard from 4 people who cannot install it.
>> I sent them to the bug tracker or to python-list but they seem
>> not to have gone either place.  Is there some guide I should be
>> sending them to, 'how to debug installation problems'?
>>
>> Laura
>>
>> ___
>> 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/g.rodola%40gmail.com
>>
>
>
>
> --
> Giampaolo - http://grodola.blogspot.com
>
> ___
> 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/brett%40python.org
>
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Nikolaus Rath]

On Sep 16 2015, Paul Moore  wrote:
> On 16 September 2015 at 06:10, Stephen J. Turnbull  wrote:
>>   The only thing that hg really lost badly on
>> IMO was "named branches", and that's been fixed with bookmarks.
>
> FWIW, I still find bookmarks confusing to use compared to git
> branches. I don't know whether that's because bitbucket doesn't
> support them well, or whether I don't know all the details of
> bookmarks, but they just seem to get me in a muddle.
>
> For example, my usual workflow is
>
> (in a local clone of my fork on github)
>
> git checkout -b featureX
> ... hack ...
> git commit
> git push -u origin featureX # Push the local branch to github and set
> as remote tracking
>
> # later, on a  different PC
> git pull
> git checkout featureX # Sets up a remote tracking branch
> ... hack ...
> git commit
> git push
>
> # Finally, make a PR via the github UI
>
> # Once the PR is accepted
> git branch -d featureX # Remove my local branch, deleting all of the
> no longer required changesets
>
> I don't know of an equivalent of remote tracking branches in
> Mercurial. Maybe bookmarks work that way by default?

Where exactly did you run into problems? I think you should have gotten
the same result with the following hg commands (if your remote is
non-ancient):

.. hack ..
hg commit
hg bookmark featureX
hg push -B featureX origin

# later
hg pull -B featureX origin
... hack ..
hg commit
hg push


The "remote tracking branch" in Mercurial always exists, but it doesn't
have a special name. In hg, branches do not need to have names, they are
identified by their commit id. Assigning names is pure convenience, this
is why they're called "bookmarks".

> Also, my workflow involves 2 separate PCs, and I use my personal
> github forks to share work in progress between them. Mercurial makes
> it very difficult to edit "published" history, and I can't tell it
> that my bitbucket repo doesn't count as "published" (as far as I
> know).

In general you can do that by configuring the repository with

  [phases]
  publish = False

However, I believe BitBucket doesn't allow you to do that. But that's
not hg's fault.

> Git lets me do what I want (with some "are you sure?" prompts
> when I force-push a rebased/edited branch, for example).

Same with hg. "hg phase -d -f " forces the status of "rev" to
'draft'.


Best,
-Nikolaus


-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Nikolaus Rath]

On Sep 16 2015, Chris Angelico  wrote:
> With git, there are infinite workflows possible - you aren't forced to
> have a concept of "central server" and "clients" the way you would
> with SVN. Mercurial's called a DVCS too, so presumably it's possible
> to operate on a pure-peering model with no central server at all; how
> does that tie in with the inability to alter some commits?

There is no inability to do so in hg either, you just need some --force
flags ("hg phase -f -d " should be enough in almost all cases).


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Nikolaus Rath]

On Sep 16 2015, "R. David Murray"  wrote:
> The DAG plus git branches-as-labels *fits in my head* in a way that the
> DAG plus named-branches-and-other-things does not.

Hmm, that's odd. As far as I know, the difference between the hg and git
DAG model can be summarized like this:

 * In git, leaves of the DAG must be assigned a name. If they don't have
   a name, they will be garbage collected. If they have a name, they are
   called a branch.

 * In hg, leaves of the DAG persist. If you want to remove them, you
   have to do so explicitly (hg strip), if you want them to have a name,
   you must do so explicitly (hg bookmark). A node of the DAG with a
   name is called a bookmark.

 * hg named branches have no equivalent in git. 

Does that help?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Augie Fackler]

Nikolaus Rath  rath.org> writes:

> 
> On Sep 16 2015, Chris Angelico  gmail.com> wrote:
> > With git, there are infinite workflows possible - you aren't forced to
> > have a concept of "central server" and "clients" the way you would
> > with SVN. Mercurial's called a DVCS too, so presumably it's possible
> > to operate on a pure-peering model with no central server at all; how
> > does that tie in with the inability to alter some commits?
> 
> There is no inability to do so in hg either, you just need some --force
> flags ("hg phase -f -d " should be enough in almost all cases).

Actually, part of the value of phases is that it makes a truly decentralized
workflow easier to manage without errors. In Mercurial pre-phases and git,
you have to take some amount of care to avoid rebasing changes that you
pulled from an authoritative server - if you don't, you can end up with
weird history divergence that can be tricky to resolve. The addition of
phases helps the tool prevent accidental history editing.

As a concrete example, I pull from mpm's repo for Mercurial, but I push to a
repo of my own when I've reviewed patches or otherwise have work for him to
push to the authoritative one. More than once phases have prevented me from
rebasing his work onto my own, because I had a brain fart.

Does that help explain how it's a benefit in the decentralized case?

> 
> Best,
> -Nikolaus
> 




___
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

Re: [Python-Dev] congrats on 3.5! Alas, windows 7 users are having problems installing it

[Laura Creighton]

In a message of Wed, 16 Sep 2015 16:56:54 -, Brett Cannon writes:
>I don't see any issue opened about Windows 7 installation issues, so if
>someone who has had the issue can thus can help Steve diagnose the problem
>that would be great (Steve is also currently on vacation so having this all
>in a bug that he can read when he gets back would also help).

>> Same here. I get a "0x80240017 error" during installation.

Wearing my webmaster hat I talked to somebody who had this error with
their windows 8.1 install.  They wrote back that they had found this
on the net and following the sequence of things to do called 'Method
1'in http://wind8apps.com/error-0x80240017-windows/

fixed things  for them.

Laura
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Augie Fackler]

Nikolaus Rath  rath.org> writes:

> 
> On Sep 16 2015, Paul Moore  gmail.com> wrote:
> > On 16 September 2015 at 06:10, Stephen J. Turnbull 
xemacs.org> wrote:
> 
> In general you can do that by configuring the repository with
> 
>   [phases]
>   publish = False
> 
> However, I believe BitBucket doesn't allow you to do that. But that's
> not hg's fault.

Actually, BitBucket *does* support marking a repo as non-publishing. They
don't yet support exchanging the bit of metadata that lets obsolete draft
changes disappear, but I believe they have someone working on that now.

(I don't work for them, so I'm potentially working off of outdated rumors.)




___
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

Re: [Python-Dev] PEP: Collecting information about git

[Paul Moore]

On 16 September 2015 at 17:10, Nikolaus Rath  wrote:
>> I don't know of an equivalent of remote tracking branches in
>> Mercurial. Maybe bookmarks work that way by default?
>
> Where exactly did you run into problems? I think you should have gotten
> the same result with the following hg commands (if your remote is
> non-ancient):

I can't really recall. As I said, it was quite some time ago. And
probably long enough that bitbucket didn't support bookmarks, so your
"if your remote is non-ancient" may well be relevant.

One thing that I think I've got into trouble with:

I'm on revision X, which is at tip (master in git, the default branch
in Mercurial). I do git checkout -b foo (or hg bookmark foo). Now I
check in some changes. In git, I'm on branch foo and I can go back to
master with git checkout master. In Mercurial, I am at bookmark foo,
but where's the place I started from? The main line of development
(the default branch) doesn't have a bookmark, so I have to go hunting
for the revision I first switched to the bookmark at.

Similarly, if I'm at revision X, hg bookmark foo; hg bookmark bar
creates 2 bookmarks. If I then check in a change, I guess *both*
bookmarks move. In git, if I do git checkout -b foo; git checkout -b
bar, I have created two branches, and checkins now only go on bar. The
difference comes from the fact that in git, branches are "real
things", but in hg, bookmarks are names for points on the DAG - and in
this case, the DAG is completely linear so there's no way of capturing
the idea that a bookmark is starting a new branch in the DAG, unless
you actually create two commits based on the branch point.

See what I mean when I say I get confused? ;-)

> The "remote tracking branch" in Mercurial always exists, but it doesn't
> have a special name. In hg, branches do not need to have names, they are
> identified by their commit id. Assigning names is pure convenience, this
> is why they're called "bookmarks".

And yet branches are *not* simply names in git - a branch with no
commits on it is still distinct from its parent branch.

So conceptually, the idea that hg bookmarks and git branches are the
same thing, isn't actually true...

>> Also, my workflow involves 2 separate PCs, and I use my personal
>> github forks to share work in progress between them. Mercurial makes
>> it very difficult to edit "published" history, and I can't tell it
>> that my bitbucket repo doesn't count as "published" (as far as I
>> know).
>
> In general you can do that by configuring the repository with
>
>   [phases]
>   publish = False
>
> However, I believe BitBucket doesn't allow you to do that. But that's
> not hg's fault.

Well, yes and no. The fact that you have to edit the remote repository
before it will allow you to violate its "history is immutable"
principle is a feature of hg. I agree bitbucket limitations are also
relevant here (as I said, github's feature set was a major driver in
my switch, and that's not "the fault" of either tool). But hg is
(deliberately) opinionated on the right way to do things, and I do
find that those opinions get in the way of my preferred ways of
working at times.

>> Git lets me do what I want (with some "are you sure?" prompts
>> when I force-push a rebased/edited branch, for example).
>
> Same with hg. "hg phase -d -f " forces the status of "rev" to
> 'draft'.

My hg knowledge is out of date. I know phases make history editing
more flexible, but I've never learned it.

Paul
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Pierre-Yves David]

On 09/16/2015 02:20 AM, Oleg Broytman wrote:

Hi!

On Tue, Sep 15, 2015 at 07:44:28PM +, Augie Fackler  
wrote:

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.


Thank you!


There are a lot of reasons to prefer one tool over another. Common ones are
familiarity, simplicity, and power.


Add here documentation, speed, availability of extensions and
3rd-party tools, hosting options (both locally installable and web
services).


Oleg Broytman  phdru.name> writes:

With git we can have
per-directory .gitignore and .gitattributes.


No per-directory .hgignore? Never? Quite useful in a big project
where subproject live in subdirectories and are developed by separate
teams.


tags point exactly to the commits they tag.


I'm chalking these up to personal taste, but know that the tagging behavior
of git vs hg is a very complicated tradeoff. Mercurial chose a path that
makes tags audit-able in the future, whereas in Git a tag could disappear
and it'd be hard to prove.


I think signed tags can help.


I learned commit editing and found that it was the thing I wanted so
badly in hg. When I started Mercurial was at version 1.7 and there was
no commit editing at all; there was ``hg rollback`` but it only could
undo one transaction.


Please forget rollback exists. It's dangerous, and we're hiding it from new
users for a reason. :)


Sure, I forgot them many years ago. ;-)


``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, record (aka commit --interactive) and git add -p are identical
functionality-wise.


Functionality-wise - yes, but staging area still makes the process
much more convenient.


Matter of habit probably. I find the staging area a significant 
annoyance for new users. I get the exact same process flexibility by 
amending my last commit over and over, interactively getting new stuff 
in and out of it. And having this extra context of stagging area is just 
a pain to me as you have to remember all this various config flag you 
have to use to see its content. The interactive tool around it are nice 
but they do not really need the staging area concept in itself to exists.



``git log --grep=`` (and all related search options,
especially ``-G``)


Remember how I mentioned revsets replace a lot of Git command line flags?
This is an example. hg help -r 'grep(foo)'.


$ hg help -r 'grep(foo)'
hg help: option -r not recognized
hg help [-ec] [TOPIC]


I think Augie meant: hg log -r 'grep(foo)'


See also `hg help revsets`,
which are a very rich query system for revision history usable throughout
mercurial rather than only in log.


What is the flag for case-insensitive grep()? For git log -Gregex?


All revsets function matching string can have specific behavior. For 
exanple it can be turned into matching regex using "re:" prefix etc. 
This is global and unified.



As I stopped using Mercurial I do not understand what phases are.
they are phases of commit according to what? To the origin (let me
borrow the word from git terminology)?


Commits seen in the main public repository are marked as public, and
Mercurial refuses to edit them. Most history rewriting woes happen when
people rewrite widely shared history and force push the new version.
Disallowing non-fast-forward push on the server prevents the rewriting from
propagating unintentionally. Phases proactively prevent users from shooting
themselves in the foot.

More details here https://www.logilab.org/blogentry/88203


Thanks. I think upstream remote-tracking branches in git are rather
similar. If one's afraid of rewriting published history she should never
rebase before @{u}. Just always using ``git rebase -i @{u}`` should be
good enough.
The biggest difference here is that git doesn't stop one to rebase
beyond @{upstream}.


I've to stop you right there. Mercurial is not forbidding you to do 
anything. You can trivially move phase backward and rewrite these 
changesets anyway.


Hg is not the inflexible corporate tool that limit what use can do while 
git would be the awesome free range developer tool.


Mercurial is just asserting that new users have probably a partial 
understanding of what they are doing and target to be safe by default, 
while still giving access to advance feature and work-flow to advanced 
users. My daily work-flow with mercurial would probably make most 
advance git user head hurts (And yet is nice a smooth down there ☺).


--
Pierre-Yves David
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Pierre-Yves David]

(wonderfully forgot to address the point that triggered reply)

On 09/16/2015 02:20 AM, Oleg Broytman wrote:

Oleg Broytman  phdru.name> writes:

With git we can have
per-directory .gitignore and .gitattributes.


No per-directory .hgignore? Never? Quite useful in a big project
where subproject live in subdirectories and are developed by separate
teams.


We have an inclusion mechanism that allow the top level .hgignore to 
include some other in subdirectory. This gives you the best of both 
world. skipping performance implication of subdirectory walking while 
allowing big enough subproject to have their own hgignore. Used in 
production with great success.


--
Pierre-Yves David
___
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

Re: [Python-Dev] [Numpy-discussion] The process I intend to follow for any proposed changes to NumPy

[Nathaniel Smith]

Hi all,

Thanks, Travis, for the followup. I know some people were confused or
concerned by some points in Travis’s recent emails (as was I,
initially), but after checking in with Travis and the NumPy steering
council, it sounds like the main points of possible confusion are
actually things where we at least are actually on the same page. So to
avoid any uncertainty or miscommunication, I just want to reiterate
some hopefully-uncontroversial points here:

- There is currently no plan whatsoever for NumPy to drop Python 2
support; something like ~80% of our users are still using Python 2,
and we anticipate that both Python 2 and Python 3 will continue to
receive full support for the foreseeable future.

- While it is possible that there will eventually be a
compatibility-breaking “NumPy 2.0” release, it won’t happen without a
community consensus that this is a good idea, and that consensus has
not yet been reached.

- As a clarification on how NumPy governance works: While we all
continue to be grateful to Travis for his past contributions, in terms
of formal authority he stepped down from his leadership role in the
project several years ago, and the project has since switched to a
community-driven governance model [1]. Under this model, all
contributors participate as equal peers, and (outside of specific
exceptional circumstances) all contributors should be assumed to be
speaking only on behalf of themselves, not the project as a whole.

- Discussion about the best way to improve NumPy’s dtype system is
ongoing, and several approaches are under consideration. No proposal
will be accepted without review and consensus by the broader NumPy
community. We welcome anyone who’s interested in these issues to join
us on the mailing list -- the more input we have, the better the
result will be :-).

Apologies for the wide distribution of this message; I suggest any
followups be directed to numpy-discuss...@scipy.org only.

Thanks,
- Nathaniel

[1] http://thread.gmane.org/gmane.comp.python.numeric.general/61106
(we’ll move it into the repository soon, we promise!)

On Sun, Sep 13, 2015 at 3:51 PM, Travis Oliphant  wrote:
> Hey all,
>
> I just wanted to clarify, that I am very excited about a few ideas I have
> --- but I don't have time myself to engage in the community process to get
> these changes into NumPy. However, those are real processes --- I've
> been coaching a few people in those processes for the past several years
> already.
>
> So, rather than do nothing, what I'm looking to do is to work with a few
> people who I can share my ideas with, get excited about the ideas, and then
> who will work with the community to get them implemented.   That's what I
> was announcing and talking about yesterday --- looking for interested people
> who want to work on NumPy *with* the NumPy community.
>
> In my enthusiasm, I realize that some may have mis-understood my intention.
> There is no 'imminent' fork, nor am I planning on doing some crazy amount of
> work that I then try to force on other developers of NumPy.
>
> What I'm planning to do is find people to train on NumPy code base (people
> to increase the diversity of the developers would be ideal -- but hard to
> accomplish).  I plan to train them on NumPy based on my experience, and on
> what I think should be done --- and then have *them* work through the
> community process and engage with others to get consensus (hopefully not
> losing too much in translation in the process --- but instead getting even
> better).
>
> During that process I will engage as a member of the community and help
> write NEPs and other documents and help clarify where it makes sense as I
> can.   I will be filtering for people that actually want to see NumPy get
> better.Until I identify the people and work with them, it will be hard
> to tell how this will best work.   So, stay tuned.
>
> If all goes well, what you should see in a few weeks time are specific
> proposals, a branch or two, and the beginnings of some pull requests.If
> you don't see that, then I will not have found the right people to help me,
> and we will all continue to go back to searching.
>
> While I'm expecting the best, in the worst case, we get additional people
> who know the NumPy code base and can help squash bugs as well as implement
> changes that are desired.Three things are needed if you want to
> participate in this:  1) A willingness to work with the open source
> community, 2) a deep knowledge of C and in-particular CPython's brand of C,
> and 3) a willingness to engage with me, do a mind-meld and dump around the
> NumPy code base, and then improve on what is in my head with the rest of the
> community.
>
> Thanks,
>
> -Travis
>
>
>
> ___
> NumPy-Discussion mailing list
> numpy-discuss...@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Nathaniel J. Smith -- http://vorpus.org

Re: [Python-Dev] PEP: Collecting information about git

[Nikolaus Rath]

On Sep 16 2015, Paul Moore  wrote:
> I'm on revision X, which is at tip (master in git, the default branch
> in Mercurial). I do git checkout -b foo (or hg bookmark foo). Now I
> check in some changes. In git, I'm on branch foo and I can go back to
> master with git checkout master. In Mercurial, I am at bookmark foo,
> but where's the place I started from? The main line of development
> (the default branch) doesn't have a bookmark, so I have to go hunting
> for the revision I first switched to the bookmark at.

Yes - but you could bookmark it before committing, then you don't have
to hunt for it :-).

$ hg pull
$ hg bookmark "my-origin-branch"
$ hg bookmark "my-local-branch"
$ hg update -r my-local-branch
$ hg commit
$ hg update -r my-origin-branch

> Similarly, if I'm at revision X, hg bookmark foo; hg bookmark bar
> creates 2 bookmarks. If I then check in a change, I guess *both*
> bookmarks move.

No, only the active bookmark moves automatically:

$ hg bookmark foo
$ hg bookmark bar
$ hg log -r tip
changeset:   0:d1c121e915b8
bookmark:bar
bookmark:foo
tag: tip
user:Nikolaus Rath 
date:Wed Sep 16 13:31:13 2015 -0700
files:   file
description:
initial commit


$ hg update -r foo
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
(activating bookmark foo)
$ echo barf > file
$ hg commit -m "Barf!"
file
committed changeset 1:ad44f9b935dc
$ hg log -r tip
changeset:   1:ad44f9b935dc
bookmark:foo
tag: tip
user:Nikolaus Rath 
date:Wed Sep 16 13:31:42 2015 -0700
files:   file
description:
Barf!

> In git, if I do git checkout -b foo; git checkout -b
> bar, I have created two branches, and checkins now only go on bar. The
> difference comes from the fact that in git, branches are "real
> things", but in hg, bookmarks are names for points on the DAG

You'll have to elaborate on that. What is it the difference between a
named leaf in the DAG and a branch that makes the branch "real"?

> See what I mean when I say I get confused? ;-)

I think what you mean is that you haven't read the Mercurial
documentation for quite some time :-).

>> The "remote tracking branch" in Mercurial always exists, but it doesn't
>> have a special name. In hg, branches do not need to have names, they are
>> identified by their commit id. Assigning names is pure convenience, this
>> is why they're called "bookmarks".
>
> And yet branches are *not* simply names in git - a branch with no
> commits on it is still distinct from its parent branch.
>
> So conceptually, the idea that hg bookmarks and git branches are the
> same thing, isn't actually true...

Well, the one thing were you thought they were different wasn't actually
the case. Is there another?

>>> Also, my workflow involves 2 separate PCs, and I use my personal
>>> github forks to share work in progress between them. Mercurial makes
>>> it very difficult to edit "published" history, and I can't tell it
>>> that my bitbucket repo doesn't count as "published" (as far as I
>>> know).
>>
>> In general you can do that by configuring the repository with
>>
>>   [phases]
>>   publish = False
>>
>> However, I believe BitBucket doesn't allow you to do that. But that's
>> not hg's fault.
>
> Well, yes and no. The fact that you have to edit the remote repository
> before it will allow you to violate its "history is immutable"

That's not true. You have to edit the remote repository only if you want
to edit history without --force.


Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Nikolaus Rath]

On Sep 17 2015, "Stephen J. Turnbull"  wrote:
> Nikolaus Rath writes:
>
>  > Hmm, that's odd. As far as I know, the difference between the hg and git
>  > DAG model can be summarized like this:
>  > 
>  >  * In git, leaves of the DAG must be assigned a name. If they don't have
>  >a name, they will be garbage collected.
>
> You can turn off automatic garbage collection.  I usually do: it's
> very unusual that I create millions of objects, or even megabytes
> worth of objects, that I'm creating.

Okay... (I don't quite see why this matters here).


>  >If they have a name, they are called a branch.
>
> Tags are also refs, the difference being that committing child of the
> tip of the current branch advances the branch pointer, while that
> won't happen with a tag.

Yeah, it's like that both in hg and git, so I'm not quite sure what
you're trying to say...


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Nikolaus Rath]

On Sep 16 2015, "R. David Murray"  wrote:
> On Wed, 16 Sep 2015 09:17:38 -0700, Nikolaus Rath  wrote:
>> On Sep 16 2015, "R. David Murray"  wrote:
>> > The DAG plus git branches-as-labels *fits in my head* in a way that the
>> > DAG plus named-branches-and-other-things does not.
>> 
>> Hmm, that's odd. As far as I know, the difference between the hg and git
>> DAG model can be summarized like this:
>> 
>>  * In git, leaves of the DAG must be assigned a name. If they don't have
>>a name, they will be garbage collected. If they have a name, they are
>>called a branch.
>> 
>>  * In hg, leaves of the DAG persist. If you want to remove them, you
>>have to do so explicitly (hg strip), if you want them to have a name,
>>you must do so explicitly (hg bookmark). A node of the DAG with a
>>name is called a bookmark.
>> 
>>  * hg named branches have no equivalent in git. 
>> 
>> Does that help?
>
> Well, that last bullet kind of complicates the model, doesn't it?  :)

Not if you come from git and want to use hg. You can just ignore
bookmarks.

But there is an easy explanation if you want one. Think of a named
branch as automatically appending "this went to " to your
commit message.


> Especially when you add the fact that (IIUC) which named branch a commit
> is on is recorded in the commit or something, which means the DAG is
> more complicated than just being a DAG of commits

No, it's just some extra information in the commit. Like author, date,
or commit message.

> The fact that I have to worry about (remember to delete) branches I no
> longer want is also an additional mental load,

Yes, this is a disadvantage of Mercurial.

> especially since
> (again, IIUC) I'd have to figure out which commit I wanted to strip
> *from* in order to get rid of an abandoned branch.

..but this is not. You can easily automate that (though I don't
recommend typing in the expression by hand every time, the idea is to
tel hg to "delete this changeset and all ancestors until you reach an
ancestor that has more than one child").

> This is what I mean by hg not being *oriented* toward the simple model:
> if I end up with extra heads in my cpython repo I treat this as a bug
> that needs to be fixed.

But why?

> In git, it's just a branch I'm working with and
> later do something with...or delete, and git takes care of cleaning up
> the orphaned commits for me.

In hg it's exactly the same, it's just a head you're working with, and
later you can do something with it.. or delete it. If it helps, create a
cronjob that deletes all DAG leaves that don't have bookmarks.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Terry Reedy]

On 9/16/2015 5:20 AM, Oleg Broytman wrote:


On Tue, Sep 15, 2015 at 07:44:28PM +, Augie Fackler  
wrote:



There are a lot of reasons to prefer one tool over another. Common ones are
familiarity, simplicity, and power.


Add here documentation, speed, availability of extensions and
3rd-party tools, hosting options (both locally installable and web
services).


For me, the killer 3rd party tool in favor of hg is TortoiseHg, which I 
use on Windows. As far as I know (I did check a bit), there is no 
equivalent for git on Windows.  For me, the evaluation should be between 
hg+TortoiseHG versus git+???.


For instance, having the DAG nicely displayed is especially important 
given the CPython repository policy of 1 head per branch and all commits 
on maintenance branches merged forward. A week ago, someone left an 
unmerged 3.5 commit. When I opened THG and looked at the graph, it was 
immediately obvious.  About 6 clicks and it was merged forward, 
committed, and pushed. To me, the idea of having to instead type (and 
likely, mistype) 3 commands is unacceptible.


--
Terry Jan Reedy

___
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

Re: [Python-Dev] PEP: Collecting information about git

[Terry Reedy]

On 9/15/2015 10:14 PM, Augie Fackler wrote:


(Note that I'm not subbed to python-devel, so you'll get faster service by
leaving me cc'ed on the thread.)


I am not either, because I read and post (since its beginning) via the 
gmane.comp.python.devel mirror at news.gmane.org.  Choose newsgroup or 
web interface.


--
Terry Jan Reedy

___
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

Re: [Python-Dev] PEP: Collecting information about git

[Nikolaus Rath]

On Sep 16 2015, Terry Reedy  wrote:
> On 9/16/2015 5:20 AM, Oleg Broytman wrote:
>
>> On Tue, Sep 15, 2015 at 07:44:28PM +, Augie Fackler  
>> wrote:
>
>>> There are a lot of reasons to prefer one tool over another. Common ones are
>>> familiarity, simplicity, and power.
>>
>> Add here documentation, speed, availability of extensions and
>> 3rd-party tools, hosting options (both locally installable and web
>> services).
>
> For me, the killer 3rd party tool in favor of hg is TortoiseHg, which
> I use on Windows. As far as I know (I did check a bit), there is no
> equivalent for git on Windows.

.. or elsewhere. Tortoisehg rocks.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Stephen J. Turnbull]

Nikolaus Rath writes:

 > >>  * hg named branches have no equivalent in git. 
 > >> 
 > >> Does that help?
 > >
 > > Well, that last bullet kind of complicates the model, doesn't it?  :)
 > 
 > Not if you come from git and want to use hg. You can just ignore
 > bookmarks.

No, you cannot just ignore bookmarks (but who would want to?) or named
branches (and there's the rub because named branches don't branch,
they are a partition of the set of commits).

The problem is that git and hg are communication tools: between a
developer and himself over time, and between developers at the same
time.  If your project uses named branches, you have to use named
branches.  Bookmarks, ditto.

CPython's use of named branches is very disciplined and "discrete"
because they're widely separated in both commit space and mental
space, so is very unlikely to result in anomolies.  But use of named
branches for feature branches requires some care, especially if you
have long-lived features with individual "milestones" that can be
merge *to* trunk at intervals combined with a project workflow that
emphasizes the mainline.

 > But there is an easy explanation if you want one. Think of a named
 > branch as automatically appending "this went to " to your
 > commit message.

No, that doesn't help the anomolies that occur at branch points and
merges, which can only be on one of the named branches (including the
implicit name).

 > No, it's just some extra information in the commit. Like author, date,
 > or commit message.

True, but it makes certain operations that filter on named branches
behave strangely (at least to me).

 > In hg it's exactly the same, it's just a head you're working with, and
 > later you can do something with it.. or delete it. If it helps, create a
 > cronjob that deletes all DAG leaves that don't have bookmarks.

Ugh.  What if that cron job runs while you're in the middle of merge?


___
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

Re: [Python-Dev] PEP: Collecting information about git

[Stephen J. Turnbull]

Nikolaus Rath writes:
 > On Sep 17 2015, "Stephen J. Turnbull"  wrote:
 > > Nikolaus Rath writes:
 > >
 > >  > Hmm, that's odd. As far as I know, the difference between the hg and git
 > >  > DAG model can be summarized like this:
 > >  > 
 > >  >  * In git, leaves of the DAG must be assigned a name. If they don't have
 > >  >a name, they will be garbage collected.
 > >
 > > You can turn off automatic garbage collection.  I usually do: it's
 > > very unusual that I create millions of objects, or even megabytes
 > > worth of objects, that I'm creating.
 > 
 > Okay... (I don't quite see why this matters here).

Because it's very possible to have unnamed heads in git, although
naive usage in git doesn't create them.  The most common case used to
be after a rebase, but now the reflog provides a name and prevents
deletion for quite a while.  Now you have to do something weird like
delete a ref and change your mind, or commit to a detached HEAD and
then checkout something else.

Turning off GC is a very specialized taste, though.  I'm a packrat and
I'm also interested in workflow management (my day job is teaching
economics in a management school).  Spelunking in the detritus of my
work has made me more conscious of *how* I do various activities (not
limited to programming!), which helps in teaching others either to do
the same or to adapt my preferred workflows to their needs.

 > > >If they have a name, they are called a branch.
 > >
 > > Tags are also refs, the difference being that committing child of the
 > > tip of the current branch advances the branch pointer, while that
 > > won't happen with a tag.
 > 
 > Yeah, it's like that both in hg and git, so I'm not quite sure what
 > you're trying to say...

Well, first of all tags in hg are *commits*, not refs.  That bugs git
people.

Second, "explicit is better than implicit".  In git, there's one
implicit object: the "cache", "index", or "staging area".  This
confuses a lot of people.  For example, "git diff" does NOT give a
diff against HEAD, it gives a diff against the staging area -- which
for my usual workflow which commits files by name is the same thing
because the staging area *equals* HEAD in that scenario.  But in cases
where I do use "git add", that's no longer true, and at first I was
surprised by the resulting diffs.[1]  In hg, there may be several
implicit objects, namely the unnamed heads.

I'm not going to insist on the importance of the *number* of implicit
objects (among other things, it's not obvious how many objects the
index should be counted as).  But what is implicit in git and hg is
*different*.  In git, heads are always explicitly named (even detached
heads have the name HEAD) when you want to operate on them.  In hg,
the most commonly used heads (the default branch and merge heads) are
not.  In hg, you don't have to worry about the difference between the
index (there is one: that's what things like "hg add" affect) and tip,
because the index isn't used implicitly by any commands (except
status, but that's a special case that isn't going to bother anybody).



Footnotes: [1] Now I find this useful, as I almost never make a
mistake with "git add ", and the diff against the index filters
out all the files I haven't decided about yet, as well as notifying me
that I've made changes -- often unintended -- to previously added
files.  But for me this was definitely an acquired taste, it wasn't
natural at first.

___
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

Re: [Python-Dev] PEP: Collecting information about git

[Nikolaus Rath]

On Sep 16 2015, Nikolaus Rath  wrote:
> On Sep 16 2015, "R. David Murray"  wrote:
>> On Wed, 16 Sep 2015 09:17:38 -0700, Nikolaus Rath  wrote:
>>> On Sep 16 2015, "R. David Murray"  wrote:
>>> > The DAG plus git branches-as-labels *fits in my head* in a way that the
>>> > DAG plus named-branches-and-other-things does not.
>>> 
>>> Hmm, that's odd. As far as I know, the difference between the hg and git
>>> DAG model can be summarized like this:
>>> 
>>>  * In git, leaves of the DAG must be assigned a name. If they don't have
>>>a name, they will be garbage collected. If they have a name, they are
>>>called a branch.
>>> 
>>>  * In hg, leaves of the DAG persist. If you want to remove them, you
>>>have to do so explicitly (hg strip), if you want them to have a name,
>>>you must do so explicitly (hg bookmark). A node of the DAG with a
>>>name is called a bookmark.
>>> 
>>>  * hg named branches have no equivalent in git. 
>>> 
>>> Does that help?
>>
>> Well, that last bullet kind of complicates the model, doesn't it?  :)
>
> Not if you come from git and want to use hg. You can just ignore
> bookmarks.

Obviously, that should have read "..you can just ignore named branches".


Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
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

Re: [Python-Dev] PEP: Collecting information about git

[R. David Murray]

On Wed, 16 Sep 2015 09:17:38 -0700, Nikolaus Rath  wrote:
> On Sep 16 2015, "R. David Murray"  wrote:
> > The DAG plus git branches-as-labels *fits in my head* in a way that the
> > DAG plus named-branches-and-other-things does not.
> 
> Hmm, that's odd. As far as I know, the difference between the hg and git
> DAG model can be summarized like this:
> 
>  * In git, leaves of the DAG must be assigned a name. If they don't have
>a name, they will be garbage collected. If they have a name, they are
>called a branch.
> 
>  * In hg, leaves of the DAG persist. If you want to remove them, you
>have to do so explicitly (hg strip), if you want them to have a name,
>you must do so explicitly (hg bookmark). A node of the DAG with a
>name is called a bookmark.
> 
>  * hg named branches have no equivalent in git. 
> 
> Does that help?

Well, that last bullet kind of complicates the model, doesn't it?  :)
Especially when you add the fact that (IIUC) which named branch a commit
is on is recorded in the commit or something, which means the DAG is
more complicated than just being a DAG of commits.  The fact that I have
to worry about (remember to delete) branches I no longer want is also an
additional mental load, especially since (again, IIUC) I'd have to
figure out which commit I wanted to strip *from* in order to get rid of
an abandoned branch.

This is what I mean by hg not being *oriented* toward the simple model:
if I end up with extra heads in my cpython repo I treat this as a bug
that needs to be fixed.  In git, it's just a branch I'm working with and
later do something with...or delete, and git takes care of cleaning up
the orphaned commits for me.  I'm leery (wrongly, I suspect) of creating
branches in hg because they don't fit into my mental model of how I'm
working with the cpython repository and its named branches.  Now, is
that just a consequence of having learned mercurial in the context of how
CPython uses it?  I don't know.

As another example of this orientation issue, rebase was a big no-no in
hg when we started with it, and so I would only deal with patch sets (hg
diff to save a work in progress, reapply it later...a pattern I still
follow with cpython/hg) so that I didn't screw up my history.  In git,
it is the most natural thing in the world to take a branch you've been
working on and rebase it on to the point in the tree where you want to
commit it.  Even now I have to read carefully and think hard every time
I use the hg rebase command...I'm not sure why it is, but again it
doesn't fit in my head the way the git rebase does[*].

None of these things that mercurial does is *wrong*, and in fact they
are very useful in the right context.

The point is that the git model is *simple*.  Like I said, it fits
in my head.  I guess I have a small head :)

But, now the thread is again drifting away from how mercurial and git
relate to cpython development into simply how mercurial and git differ.

--David

[*] Note also that the hg help lacks the DAG examples that the current
git help has, and that it talks about "repeated merging" when what I
want to do is *move* the commits, I don't want to merge.  I think it
means exactly the same thing, but again it doesn't fit into my simple
git mental model of moving a branch of the DAG from here to there.
___
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

Re: [Python-Dev] PEP: Collecting information about git

[Stephen J. Turnbull]

Nikolaus Rath writes:

 > Hmm, that's odd. As far as I know, the difference between the hg and git
 > DAG model can be summarized like this:
 > 
 >  * In git, leaves of the DAG must be assigned a name. If they don't have
 >a name, they will be garbage collected.

You can turn off automatic garbage collection.  I usually do: it's
very unusual that I create millions of objects, or even megabytes
worth of objects, that I'm creating.

 >If they have a name, they are called a branch.

Tags are also refs, the difference being that committing child of the
tip of the current branch advances the branch pointer, while that
won't happen with a tag.

 >  * In hg, leaves of the DAG persist. If you want to remove them, you
 >have to do so explicitly (hg strip), if you want them to have a name,
 >you must do so explicitly (hg bookmark). A node of the DAG with a
 >name is called a bookmark.
 > 
 >  * hg named branches have no equivalent in git. 

And that's a very good thing.

___
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