Re: [Python-Dev] r85838 - python/branches/py3k/.gitignore
Am 25.10.2010 19:37, schrieb victor.stinner:
Author: victor.stinner Date: Mon Oct 25 19:37:18 2010 New Revision: 85838
Log: update gitignore
Added: python/branches/py3k/.gitignore
This looks more like "Add gitignore". Do we really want to check in ignore files for every possible DVCS? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl <g.brandl@gmx.net> wrote:
This looks more like "Add gitignore". Do we really want to check in ignore files for every possible DVCS?
No, but supporting the current big four open source ones (svn, hg, bzr, git) seems reasonable enough. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl <g.brandl@gmx.net> wrote:
This looks more like "Add gitignore". Do we really want to check in ignore files for every possible DVCS?
No, but supporting the current big four open source ones (svn, hg, bzr, git) seems reasonable enough.
+1. A couple of extra dot files never hurt anyone. :) -Barry
In article <20101026085124.4c68459c@mission>, Barry Warsaw <barry@python.org> wrote:
On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl <g.brandl@gmx.net> wrote:
This looks more like "Add gitignore". Do we really want to check in ignore files for every possible DVCS?
No, but supporting the current big four open source ones (svn, hg, bzr, git) seems reasonable enough.
+1. A couple of extra dot files never hurt anyone. :)
Actually they have. I got burned a while back by the checked-in .hgignore file when creating my own hg repo (to use mq patch management) on top of a svn checkout. Now that I know they are there, I ensure they get deleted. -- Ned Deily, nad@acm.org
On Tue, 26 Oct 2010 10:42:27 -0700 Ned Deily <nad@acm.org> wrote:
In article <20101026085124.4c68459c@mission>, Barry Warsaw <barry@python.org> wrote:
On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl <g.brandl@gmx.net> wrote:
This looks more like "Add gitignore". Do we really want to check in ignore files for every possible DVCS?
No, but supporting the current big four open source ones (svn, hg, bzr, git) seems reasonable enough.
+1. A couple of extra dot files never hurt anyone. :)
Actually they have. I got burned a while back by the checked-in .hgignore file when creating my own hg repo (to use mq patch management) on top of a svn checkout.
You could use own of the "official" mirrors at http://code.python.org/hg/ cheers Antoine.
In article <20101026200234.5f8e8323@pitrou.net>, Antoine Pitrou <solipsis@pitrou.net> wrote:
You could use own of the "official" mirrors at http://code.python.org/hg/
The "official" hg mirrors work great: in my experience, faster than svn and simpler with all the useful history information retained from the original svn repos. Thanks for that! As an example, for OS X TextMate users out there, with up-to-date Mercurial and Subversion bundles, try doing an Annotate on an hg clone of a Python branch vs a Blame on an svn co. With the hg clones and the hg rebase extension (now a standard part of hg), I've moved away from using hg mq patch queues for patch development although I still use the svn repos (until the transition is closer) and mq for installer build and regression testing. FWIW, my hg workflow these days is to clone a local "master" clone for each of 27, 31, and py3k repos from the official mirrors then just clone working copies from my local masters as needed for each issue. Using a local master speeds things up, potentially saves disk space as hg uses hard links for local clones where possible, and saves on network bandwidth. With work-in-progress committed to a working copy, I can update automatically to the latest tip by a two-step update: update the local master from the official mirror (via "pull") and then update the working copy from the local master and use rebase to manage any new merge conflicts. I couldn't quite get the two-stage pulls to completely work using one standard hg command so I wrote a "pull-clone" script that does the trick for me: import ConfigParser import os.path import subprocess import sys HG_DEFAULTS = '.hg/hgrc' HG_BIN = '/opt/local/bin/hg' if not os.path.exists(HG_DEFAULTS): sys.exit('No hg repository here') else: config = ConfigParser.ConfigParser() config.read(HG_DEFAULTS) try: default = config.get('paths', 'default') except ConfigParser.NoSectionError, ConfigParser.NoOptionError: default = '' if default.startswith('/'): subprocess.check_call([HG_BIN, 'pull', '-R', default], cwd=default) subprocess.check_call([HG_BIN, 'pull', '-u', '--rebase']) subprocess.check_call([HG_BIN, 'summary', '--remote']) -- Ned Deily, nad@acm.org
On Tue, Oct 26, 2010 at 3:51 PM, Barry Warsaw <barry@python.org> wrote:
On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl <g.brandl@gmx.net> wrote:
This looks more like "Add gitignore". Do we really want to check in ignore files for every possible DVCS?
No, but supporting the current big four open source ones (svn, hg, bzr, git) seems reasonable enough.
+1. A couple of extra dot files never hurt anyone. :)
Why hg and bzr can't be tuned to understand .svnignore files? -- anatoly t.
On 10/27/2010 3:25 AM, anatoly techtonik wrote:
On Tue, Oct 26, 2010 at 3:51 PM, Barry Warsaw <barry@python.org> wrote:
On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl <g.brandl@gmx.net> wrote:
This looks more like "Add gitignore". Do we really want to check in ignore files for every possible DVCS?
No, but supporting the current big four open source ones (svn, hg, bzr, git) seems reasonable enough.
+1. A couple of extra dot files never hurt anyone. :)
Why hg and bzr can't be tuned to understand .svnignore files?
Is there such a thing? I think you mean the svn:ignore metadata, which I doubt you can get to through either mirror. Even if you could, svn:ignore is pretty weak (only applies to the directory it is set on and can only do glob patterns). .hgignore is significantly more robust (and only has to be written to a single spot) since matches entire paths and supports regex. Eventually, we'll need to build an appropriate .hgignore file for the python tree anyways. As with others, I don't see the harm in committers who use those tools adding and maintaining these files. Seems akin to having Misc/python-mode.el and Misc/Vim/python.vim. It's all in the spirit of supporting the tools that people are actually using. -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
On Oct 27, 2010, at 03:54 AM, Scott Dial wrote:
As with others, I don't see the harm in committers who use those tools adding and maintaining these files. Seems akin to having Misc/python-mode.el and Misc/Vim/python.vim. It's all in the spirit of supporting the tools that people are actually using.
Oh crap, Misc/python-mode.el is still there and way out of date. Please, if anybody's using it, switch to the latest one at http://launchpad.net/python-mode I'd like to delete the one in Misc for the py3k branch and replace it with a README.python-mode that points to the new location. What do y'all think about doing the same for the Python 2.7 and 3.1 branches? -Barry
2010/10/27 Barry Warsaw <barry@python.org>:
On Oct 27, 2010, at 03:54 AM, Scott Dial wrote:
As with others, I don't see the harm in committers who use those tools adding and maintaining these files. Seems akin to having Misc/python-mode.el and Misc/Vim/python.vim. It's all in the spirit of supporting the tools that people are actually using.
Oh crap, Misc/python-mode.el is still there and way out of date. Please, if anybody's using it, switch to the latest one at
http://launchpad.net/python-mode
I'd like to delete the one in Misc for the py3k branch and replace it with a README.python-mode that points to the new location. What do y'all think about doing the same for the Python 2.7 and 3.1 branches?
+1 and this should probably happen to the other editor related things in Misc. -- Regards, Benjamin
I remember a discussion about Vim files some time ago. I use Vim with the files from Misc/Vim, which are up-to-date and more useful than the files shipped with Vim. I don’t use plugins or external files, so I’m -1 on removing Misc/Vim. Regards
On Oct 27, 2010, at 02:54 PM, Éric Araujo wrote:
I remember a discussion about Vim files some time ago. I use Vim with the files from Misc/Vim, which are up-to-date and more useful than the files shipped with Vim. I don’t use plugins or external files, so I’m -1 on removing Misc/Vim.
FWIW, Python support in Emacs is muddled. GNU Emacs comes with python.el which is an alternative implementation that shares some features with, but also has differences to, python-mode.el. Many of us hard-core Python Emacsers prefer the latter, but sadly the FSF won't bundle it and a merge has proven impossible so far. I think I'll replace Misc/python-mode.el with Misc/README.Emacs that attempts to discuss the issue in a neutral way. I'll fix this in Python 2.7, 3.1, and 3.2. Thanks, -Barry
On Wed, Oct 27, 2010 at 5:55 AM, Barry Warsaw <barry@python.org> wrote:
On Oct 27, 2010, at 02:54 PM, Éric Araujo wrote:
I remember a discussion about Vim files some time ago. I use Vim with the files from Misc/Vim, which are up-to-date and more useful than the files shipped with Vim. I don’t use plugins or external files, so I’m -1 on removing Misc/Vim.
FWIW, Python support in Emacs is muddled. GNU Emacs comes with python.el which is an alternative implementation that shares some features with, but also has differences to, python-mode.el. Many of us hard-core Python Emacsers prefer the latter, but sadly the FSF won't bundle it and a merge has proven impossible so far.
I think I'll replace Misc/python-mode.el with Misc/README.Emacs that attempts to discuss the issue in a neutral way. I'll fix this in Python 2.7, 3.1, and 3.2.
Why "in a neutral way"? I don't see any problem with us recommending python-mode.el, since it comes from our community and it works better. I have recently had to go out of my way to make sure it is used in my Google setups. I can't live without pdbtrack. -- --Guido van Rossum (python.org/~guido)
On Oct 27, 2010, at 08:29 AM, Guido van Rossum wrote:
Why "in a neutral way"? I don't see any problem with us recommending python-mode.el, since it comes from our community and it works better. I have recently had to go out of my way to make sure it is used in my Google setups. I can't live without pdbtrack.
pdbtrack does rock! (Hi Ken :). -Barry
On Wed, Oct 27, 2010 at 05:54, Éric Araujo <merwok@netwok.org> wrote:
I remember a discussion about Vim files some time ago. I use Vim with the files from Misc/Vim, which are up-to-date and more useful than the files shipped with Vim. I don’t use plugins or external files, so I’m -1 on removing Misc/Vim.
In the name of completeness for people not aware of the issue, http://bugs.python.org/issue9893 discusses actually removing these files in preference to files maintained by others. If Misc/Vim were to be dropped we could place a text file much like Barry is planning to do for Emacs and point to the files Antoine is recommending.
On Oct 27, 2010, at 09:19 AM, Brett Cannon wrote:
In the name of completeness for people not aware of the issue, http://bugs.python.org/issue9893 discusses actually removing these files in preference to files maintained by others. If Misc/Vim were to be dropped we could place a text file much like Barry is planning to do for Emacs and point to the files Antoine is recommending.
The Emacs changes are committed now in py3k, release31-maint, and release27-maint. Cheers, -Barry
Am 27.10.2010 09:25, schrieb anatoly techtonik:
On Tue, Oct 26, 2010 at 3:51 PM, Barry Warsaw <barry@python.org> wrote:
On Oct 26, 2010, at 09:19 PM, Nick Coghlan wrote:
On Tue, Oct 26, 2010 at 5:31 PM, Georg Brandl <g.brandl@gmx.net> wrote:
This looks more like "Add gitignore". Do we really want to check in ignore files for every possible DVCS?
No, but supporting the current big four open source ones (svn, hg, bzr, git) seems reasonable enough.
+1. A couple of extra dot files never hurt anyone. :)
Why hg and bzr can't be tuned to understand .svnignore files?
As Scott said, this isn't possible because there are no .svnignore files. However, it would be nice to see those VCS handling ignores as a dotfile in the repo root developing support for a single .ignore file... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Le mardi 26 octobre 2010 09:31:11, Georg Brandl a écrit :
Am 25.10.2010 19:37, schrieb victor.stinner:
Author: victor.stinner Date: Mon Oct 25 19:37:18 2010 New Revision: 85838
Log: update gitignore
Added: python/branches/py3k/.gitignore
This looks more like "Add gitignore". Do we really want to check in ignore files for every possible DVCS?
It's a mistake. I didn't want to commit this file. The changelog is "update" because I merged two or three commits about gitignore using git rebase -i, and I kept the wrong changelog. If it doesn't "hurt", keep it, otherwise you can delete it. As you want. But each time that I create a git-svn repository, I have to recreate this file. -- Victor Stinner http://www.haypocalc.com/
participants (12)
-
anatoly techtonik -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Georg Brandl -
Guido van Rossum -
Ned Deily -
Nick Coghlan -
Scott Dial -
Victor Stinner -
Éric Araujo