Hi, I thought I'd split this one off onto its own thread too because it's an important issue independent of scipy.stats
For me it's easier to develop and mature inside a pure python package, which is also more accessible for new contributors. One of my wishful target audience are contributors on Windows, which would become rather difficult as part of scipy and git.
I would imagine that everyone agrees that it's very important that we have developers like you (Josef) who are using windows as their main platform. It's by far the best way to make sure we are shaking out bugs on windows. So, given that there seems a strong mood to switch to git, we should make sure that this does not cause problems for windows developers. So: Josef - and others a) are there any problems that you know of using git from the windows shell? b) Do you think you would prefer to use mercurial as a client for the git repo : http://github.com/blog/439-hg-git-mercurial-plugin ? In that case we should set up documentation for that. c) Do you want to stick with bzr? That might be possible (https://launchpad.net/bzr-git, http://github.com/matthew-brett/git-bzr) but that will likely be considerably harder than a mercurial client. See you, Matthew
On Tue, Jun 1, 2010 at 12:24 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
I thought I'd split this one off onto its own thread too because it's an important issue independent of scipy.stats
For me it's easier to develop and mature inside a pure python package, which is also more accessible for new contributors. One of my wishful target audience are contributors on Windows, which would become rather difficult as part of scipy and git.
I would imagine that everyone agrees that it's very important that we have developers like you (Josef) who are using windows as their main platform. It's by far the best way to make sure we are shaking out bugs on windows.
So, given that there seems a strong mood to switch to git, we should make sure that this does not cause problems for windows developers.
So: Josef - and others
a) are there any problems that you know of using git from the windows shell?
None in principle here (and from what I've garnered through the discussion, I am supportive of the move, as long as we don't deprecate the SVN trunk too quickly), but do we have anyone, even just one person, who is already reasonably facile in this regard who'd be willing to support others through the transition? DG
b) Do you think you would prefer to use mercurial as a client for the git repo : http://github.com/blog/439-hg-git-mercurial-plugin ? In that case we should set up documentation for that. c) Do you want to stick with bzr? That might be possible (https://launchpad.net/bzr-git, http://github.com/matthew-brett/git-bzr) but that will likely be considerably harder than a mercurial client.
See you,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
-- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves)
Hi,
a) are there any problems that you know of using git from the windows shell?
None in principle here (and from what I've garnered through the discussion, I am supportive of the move, as long as we don't deprecate the SVN trunk too quickly), but do we have anyone, even just one person, who is already reasonably facile in this regard who'd be willing to support others through the transition?
I would not claim to be very experienced, but I have not had any problems using msysgit with either the windows shell or the (rather good) windows power shell. The bash shell does have problems but the windows shells have proved more useful. I'd certainly be willing to help as far as I can - but I think the next step is to find what problems people are having (or expect to have) and go from there. See you, Matthew
On Tue, Jun 1, 2010 at 12:44 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
a) are there any problems that you know of using git from the windows shell?
None in principle here (and from what I've garnered through the discussion, I am supportive of the move, as long as we don't deprecate the SVN trunk too quickly), but do we have anyone, even just one person, who is already reasonably facile in this regard who'd be willing to support others
Hi, through
the transition?
I would not claim to be very experienced, but I have not had any problems using msysgit with either the windows shell or the (rather good) windows power shell. The bash shell does have problems but the windows shells have proved more useful.
I'd certainly be willing to help as far as I can - but I think the next step is to find what problems people are having (or expect to have) and go from there.
Of course, but it's comforting to know there's someone in the community whom we might hope will know the answers to questions that arise. :-) FFR, what are your platform specifics (e.g., I'm running Win7 Home Prem. 64bit), in case it turns out to matter. DG
See you,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
-- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves)
On Tue, Jun 1, 2010 at 3:44 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
a) are there any problems that you know of using git from the windows shell?
None in principle here (and from what I've garnered through the discussion, I am supportive of the move, as long as we don't deprecate the SVN trunk too quickly), but do we have anyone, even just one person, who is already reasonably facile in this regard who'd be willing to support others through the transition?
I would not claim to be very experienced, but I have not had any problems using msysgit with either the windows shell or the (rather good) windows power shell. The bash shell does have problems but the windows shells have proved more useful.
It depends a lot on the part that I am working on. I wouldn't want to switch statsmodels where I do my main development to git. For scipy.stats (or bugfixes in other parts of scipy) I will give git a try, or look at the mercurial interface, if git doesn't work out for me. My main problem with git was the treatment of the file system, and I find it much easier to work with separate branches as in bzr or mercurial. For scipy, I never had to maintain a longer lived branch where I needed to worry about synchronizing with a changing trunk. I prepare most changes in scipy on standalone files, because they have a much faster development and test cycle, and merging them back into the scipy source is usually easy. (caveat: large/invasive changes like Ralf's docstring improvements are a lot more difficult to handle this way, but he was finally able to commit them himself.) And since I never (except for two c code bugfixes in numpy random) worked on compiled code, I didn't need a full develop-compile-test cycle. So, any version control system is fine with me, and maybe I can get used to the advantages of git. As long as it is possible to stick with the basic workflow of git without anything fancy, similar what I have seen while skimming the nipy docs, I think it is not a problem on windows. The basic commands and for example eclipse, GUI plugins look similar enough. However, if/when parts of statsmodels go into scipy and I have to do maintenance of less isolated code, then I think the Mercurial interface might be my preferred choice. I haven't used Mercurial much yet, but I don't see any problems with it. So, the bottom line is, that documentation for the hg-git interface would be very useful for Windows users (or those that think git is a strange/unfamiliar concept.) Josef
I'd certainly be willing to help as far as I can - but I think the next step is to find what problems people are having (or expect to have) and go from there.
See you,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On 1 June 2010 13:31, <josef.pktd@gmail.com> wrote:
So, the bottom line is, that documentation for the hg-git interface would be very useful for Windows users (or those that think git is a strange/unfamiliar concept.)
These interfaces are somewhat dangerous, in the sense that you may encounter rather untypical scenarios and strange bugs in those tools (for example, we even have to be careful with git-svn, and that tool is widely used). Do you think a clear, simple, numpy/scipy-oriented tutorial could sufficiently lower the barrier to adoption? I think the bzr work-flow you are used to is probably very similar to the one you'd follow with git. Regards Stéfan
2010/6/1 Stéfan van der Walt <stefan@sun.ac.za>
On 1 June 2010 13:31, <josef.pktd@gmail.com> wrote:
So, the bottom line is, that documentation for the hg-git interface would be very useful for Windows users (or those that think git is a strange/unfamiliar concept.)
These interfaces are somewhat dangerous, in the sense that you may encounter rather untypical scenarios and strange bugs in those tools (for example, we even have to be careful with git-svn, and that tool is widely used).
Do you think a clear, simple, numpy/scipy-oriented tutorial could sufficiently lower the barrier to adoption? I think the bzr work-flow you are used to is probably very similar to the one you'd follow with git.
I looked at the trial version of smartgit <http://www.syntevo.com/smartgit/index.html>a while back and it seemed decent to me as a git interface. I didn't actually use it, though. Chuck
2010/6/1 Stéfan van der Walt <stefan@sun.ac.za>
On 1 June 2010 13:31, <josef.pktd@gmail.com> wrote:
So, the bottom line is, that documentation for the hg-git interface would be very useful for Windows users (or those that think git is a strange/unfamiliar concept.)
These interfaces are somewhat dangerous, in the sense that you may encounter rather untypical scenarios and strange bugs in those tools (for example, we even have to be careful with git-svn, and that tool is widely used).
Do you think a clear, simple, numpy/scipy-oriented tutorial could sufficiently lower the barrier to adoption?
Is that a rhetorical question? I don't think there's any doubt that such would very likely have the stated result. The question is, is that your way of offering to write it? :-) DG
I think the bzr work-flow you are used to is probably very similar to the one you'd follow with git.
Regards Stéfan _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
-- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves)
Hi Josef, On Tue, Jun 1, 2010 at 1:31 PM, <josef.pktd@gmail.com> wrote:
My main problem with git was the treatment of the file system, and I find it much easier to work with separate branches as in bzr or mercurial.
One thing I've found very useful after transitioning to git for IPython is the git new-workdir command: http://kerneltrap.org/mailarchive/git/2008/5/21/1900044 http://nuclearsquid.com/writings/git-new-workdir.html It lets me keep a few branches around that I want 'permanent' on my filesystem, in a bzr shared-repo style, while using git for the lightweight feature-only branches. This is how it looks like right now on my system: - Main ipython git repo: uqbar[ipython]> cd ipython/ (Master)uqbar[ipython]> git branch -a 0.10 0.10.1 0.8 0.9 * Master master remotes/mainline/0.10 remotes/mainline/0.10.1 remotes/mainline/0.8 remotes/mainline/0.9 remotes/mainline/master remotes/min/0.10 remotes/min/0.10.1 remotes/min/0.8 remotes/min/0.9 remotes/min/master remotes/origin/master And a separate 'branches' repo, populated with new-workdir: (Master)uqbar[ipython]> cd ../branches uqbar[branches]> d /home/fperez/ipython/branches total 16 drwxr-xr-x 10 fperez 4096 2010-05-13 01:35 0.10/ drwxr-xr-x 10 fperez 4096 2010-05-13 15:48 0.10.1/ where I keep branches I may need to see persistently on disk. HTH. Cheers, f
On Tue, Jun 1, 2010 at 6:11 PM, Fernando Perez <fperez.net@gmail.com> wrote:
Hi Josef,
On Tue, Jun 1, 2010 at 1:31 PM, <josef.pktd@gmail.com> wrote:
My main problem with git was the treatment of the file system, and I find it much easier to work with separate branches as in bzr or mercurial.
One thing I've found very useful after transitioning to git for IPython is the git new-workdir command:
http://kerneltrap.org/mailarchive/git/2008/5/21/1900044 http://nuclearsquid.com/writings/git-new-workdir.html
It lets me keep a few branches around that I want 'permanent' on my filesystem, in a bzr shared-repo style, while using git for the lightweight feature-only branches. This is how it looks like right now on my system:
thanks very useful information , git-new-workdir seems to be what I would like. Does it work on Windows? last year I didn't find any way to do this. I haven't updated git since then and I don't see any git-new-workdir in the git folders. (But maybe I deleted it when I switched from the full 1.x GB git install to the light version - without mingw and the kitchen sink) Josef
- Main ipython git repo: uqbar[ipython]> cd ipython/ (Master)uqbar[ipython]> git branch -a 0.10 0.10.1 0.8 0.9 * Master master remotes/mainline/0.10 remotes/mainline/0.10.1 remotes/mainline/0.8 remotes/mainline/0.9 remotes/mainline/master remotes/min/0.10 remotes/min/0.10.1 remotes/min/0.8 remotes/min/0.9 remotes/min/master remotes/origin/master
And a separate 'branches' repo, populated with new-workdir:
(Master)uqbar[ipython]> cd ../branches uqbar[branches]> d /home/fperez/ipython/branches total 16 drwxr-xr-x 10 fperez 4096 2010-05-13 01:35 0.10/ drwxr-xr-x 10 fperez 4096 2010-05-13 15:48 0.10.1/
where I keep branches I may need to see persistently on disk.
HTH.
Cheers,
f _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Hi Josef, On Tue, Jun 1, 2010 at 8:07 PM, <josef.pktd@gmail.com> wrote:
thanks very useful information , git-new-workdir seems to be what I would like. Does it work on Windows?
last year I didn't find any way to do this. I haven't updated git since then and I don't see any git-new-workdir in the git folders. (But maybe I deleted it when I switched from the full 1.x GB git install to the light version - without mingw and the kitchen sink)
Unfortunately I don't know if it works on Windows; on my linux box it ships here: /usr/share/doc/git-core/contrib/workdir/git-new-workdir and I had to enable it by copying this script to somewhere in my PATH and making it executable. I have no idea if these contortions would work on Windows as well, though. Cheers, f
Hi, On Tue, Jun 1, 2010 at 8:07 PM, <josef.pktd@gmail.com> wrote:
On Tue, Jun 1, 2010 at 6:11 PM, Fernando Perez <fperez.net@gmail.com> wrote:
Hi Josef,
On Tue, Jun 1, 2010 at 1:31 PM, <josef.pktd@gmail.com> wrote:
My main problem with git was the treatment of the file system, and I find it much easier to work with separate branches as in bzr or mercurial.
One thing I've found very useful after transitioning to git for IPython is the git new-workdir command:
http://kerneltrap.org/mailarchive/git/2008/5/21/1900044 http://nuclearsquid.com/writings/git-new-workdir.html
It lets me keep a few branches around that I want 'permanent' on my filesystem, in a bzr shared-repo style, while using git for the lightweight feature-only branches. This is how it looks like right now on my system:
thanks very useful information , git-new-workdir seems to be what I would like. Does it work on Windows?
Sadly - probably not without a little hacking... http://code.google.com/p/msysgit/issues/detail?id=99 But, if you think you need it, the script is so short that it would only take a short time to port to python (it's in sh): http://git.kernel.org/?p=git/git.git;a=blob_plain;f=contrib/workdir/git-new-... I see there are symbolic links there, that will require a little fancy footwork on windows, as you know. If I have time I'll give it a go. See you, Matthew
On Tue, Jun 1, 2010 at 11:39 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Jun 1, 2010 at 8:07 PM, <josef.pktd@gmail.com> wrote:
On Tue, Jun 1, 2010 at 6:11 PM, Fernando Perez <fperez.net@gmail.com> wrote:
Hi Josef,
On Tue, Jun 1, 2010 at 1:31 PM, <josef.pktd@gmail.com> wrote:
My main problem with git was the treatment of the file system, and I find it much easier to work with separate branches as in bzr or mercurial.
One thing I've found very useful after transitioning to git for IPython is the git new-workdir command:
http://kerneltrap.org/mailarchive/git/2008/5/21/1900044 http://nuclearsquid.com/writings/git-new-workdir.html
It lets me keep a few branches around that I want 'permanent' on my filesystem, in a bzr shared-repo style, while using git for the lightweight feature-only branches. This is how it looks like right now on my system:
thanks very useful information , git-new-workdir seems to be what I would like. Does it work on Windows?
Sadly - probably not without a little hacking...
http://code.google.com/p/msysgit/issues/detail?id=99
But, if you think you need it, the script is so short that it would only take a short time to port to python (it's in sh):
http://git.kernel.org/?p=git/git.git;a=blob_plain;f=contrib/workdir/git-new-...
I see there are symbolic links there, that will require a little fancy footwork on windows, as you know.
If I have time I'll give it a go.
I don't think that's necessary (symlinks sound tricky) and scipy will be on a public repository, so your multiple (if I understand correctly) clone solution will work. Josef
See you,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Tue, Jun 1, 2010 at 9:56 PM, <josef.pktd@gmail.com> wrote:
On Tue, Jun 1, 2010 at 11:39 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Jun 1, 2010 at 8:07 PM, <josef.pktd@gmail.com> wrote:
On Tue, Jun 1, 2010 at 6:11 PM, Fernando Perez <fperez.net@gmail.com> wrote:
Hi Josef,
On Tue, Jun 1, 2010 at 1:31 PM, <josef.pktd@gmail.com> wrote:
My main problem with git was the treatment of the file system, and I find it much easier to work with separate branches as in bzr or mercurial.
One thing I've found very useful after transitioning to git for IPython is the git new-workdir command:
http://kerneltrap.org/mailarchive/git/2008/5/21/1900044 http://nuclearsquid.com/writings/git-new-workdir.html
It lets me keep a few branches around that I want 'permanent' on my filesystem, in a bzr shared-repo style, while using git for the lightweight feature-only branches. This is how it looks like right now on my system:
thanks very useful information , git-new-workdir seems to be what I would like. Does it work on Windows?
Sadly - probably not without a little hacking...
http://code.google.com/p/msysgit/issues/detail?id=99
But, if you think you need it, the script is so short that it would only take a short time to port to python (it's in sh):
http://git.kernel.org/?p=git/git.git;a=blob_plain;f=contrib/workdir/git-new-...
I see there are symbolic links there, that will require a little fancy footwork on windows, as you know.
If I have time I'll give it a go.
I don't think that's necessary (symlinks sound tricky) and scipy will be on a public repository, so your multiple (if I understand correctly) clone solution will work.
Could you not use hg to do what you want (work with local directories) and the use hg-git when you need to? I am kinda partial to hg and bzr. Vincent
Josef
See you,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Wed, Jun 2, 2010 at 12:02 AM, Vincent Davis <vincent@vincentdavis.net> wrote:
On Tue, Jun 1, 2010 at 9:56 PM, <josef.pktd@gmail.com> wrote:
On Tue, Jun 1, 2010 at 11:39 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Tue, Jun 1, 2010 at 8:07 PM, <josef.pktd@gmail.com> wrote:
On Tue, Jun 1, 2010 at 6:11 PM, Fernando Perez <fperez.net@gmail.com> wrote:
Hi Josef,
On Tue, Jun 1, 2010 at 1:31 PM, <josef.pktd@gmail.com> wrote:
My main problem with git was the treatment of the file system, and I find it much easier to work with separate branches as in bzr or mercurial.
One thing I've found very useful after transitioning to git for IPython is the git new-workdir command:
http://kerneltrap.org/mailarchive/git/2008/5/21/1900044 http://nuclearsquid.com/writings/git-new-workdir.html
It lets me keep a few branches around that I want 'permanent' on my filesystem, in a bzr shared-repo style, while using git for the lightweight feature-only branches. This is how it looks like right now on my system:
thanks very useful information , git-new-workdir seems to be what I would like. Does it work on Windows?
Sadly - probably not without a little hacking...
http://code.google.com/p/msysgit/issues/detail?id=99
But, if you think you need it, the script is so short that it would only take a short time to port to python (it's in sh):
http://git.kernel.org/?p=git/git.git;a=blob_plain;f=contrib/workdir/git-new-...
I see there are symbolic links there, that will require a little fancy footwork on windows, as you know.
If I have time I'll give it a go.
I don't think that's necessary (symlinks sound tricky) and scipy will be on a public repository, so your multiple (if I understand correctly) clone solution will work.
Could you not use hg to do what you want (work with local directories) and the use hg-git when you need to?
I am kinda partial to hg and bzr.
I will give git a try, reviewing patches sounds easier with git. For other things, hg-git will be the likely outcome. Josef
Vincent
Josef
See you,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Hi,
My main problem with git was the treatment of the file system, and I find it much easier to work with separate branches as in bzr or mercurial.
Yes, it is true that the git lightweight branch model takes some time to get used to. My experience is that it's quick to get used to the git way, and once I did, it was a large relief to get rid of all those branch directories when we switched, but I understand that it is a leap. I am sure you know this, but you can replicate the heavyweight branches of hg and bzr with: # initial git clone of 'trunk' git clone git://github.com/nipy/nipy.git # make a heavyweight branch git clone nipy my-nipy-branch # push somewhere # First add repo for the branch via github interface, then cd my-nipy-branch git remote add origin git@github.com:matthew-brett/my-nipy-branch.git git push origin master I think you'd agree that it's not a windows / unix difference though. I'd agree it is a larger conceptual leap from svn to git than it is from svn to bzr or svn to mercurial. The git argument is that making that initial leap gives you a great deal of freedom and flexibility, but it can be intimidating at first.
As long as it is possible to stick with the basic workflow of git without anything fancy, similar what I have seen while skimming the nipy docs, I think it is not a problem on windows.
I think that is true that most of us won't need to go further than the nipy basic workflow - but we haven't been using git long enough to know that very well. I would defer to the git masters out there - David, Pauli and others - ?
However, if/when parts of statsmodels go into scipy and I have to do maintenance of less isolated code, then I think the Mercurial interface might be my preferred choice.
I haven't used Mercurial much yet, but I don't see any problems with it.
So, the bottom line is, that documentation for the hg-git interface would be very useful for Windows users (or those that think git is a strange/unfamiliar concept.)
So - two issues: 1) The conceptual issues involved in switching mind-set from svn or bzr to git. That may require some thought and documentation 2) There might be some technical issues using git on windows - but I think so far we don't have any reason to think so? 3) Some people may prefer mercurial for other reasons; it would be good to respect that if possible. So, it may well be worth making a hg-git doc for numpy when we do the transition - with the caveats that David raised. In the meantime, it would be very good to hear of any problems that do come up specifically using git on windows... See you, Matthew
On Tue, Jun 1, 2010 at 6:14 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
My main problem with git was the treatment of the file system, and I find it much easier to work with separate branches as in bzr or mercurial.
Yes, it is true that the git lightweight branch model takes some time to get used to. My experience is that it's quick to get used to the git way, and once I did, it was a large relief to get rid of all those branch directories when we switched, but I understand that it is a leap.
I am sure you know this, but you can replicate the heavyweight branches of hg and bzr with:
# initial git clone of 'trunk' git clone git://github.com/nipy/nipy.git # make a heavyweight branch git clone nipy my-nipy-branch # push somewhere # First add repo for the branch via github interface, then cd my-nipy-branch git remote add origin git@github.com:matthew-brett/my-nipy-branch.git git push origin master
However, I think this works only with a remote remote, github or similar When I looked at bzr vs hg vs git, I also thought about my private use, where I didn't find a way to compare across branches in separate directories. My work style in statsmodels is similar to the mailing list reference that Fernando gave. Mainly I have many uncommitted files in each branch, test scripts, examples scripts, quick checks whether a rewrite would work, or R and matlab files. None of it I want to commit to the repository, but have available when I work on it again.
I think you'd agree that it's not a windows / unix difference though. I'd agree it is a larger conceptual leap from svn to git than it is from svn to bzr or svn to mercurial. The git argument is that making that initial leap gives you a great deal of freedom and flexibility, but it can be intimidating at first.
A great deal of freedom gives any new user also a lot of opportunities to shoot in his own foot. And my impression from the mailing lists is that the rescue team is called more often than with bzr or hg. My recommendation to myself is not to use with git more than the 10 or so basic commands similar to svn or bzr. Then I don't think it will create any real problems. So the basic workflow description by the nipy and numpy/scipy git developers will be the most useful help for the transition. (just confirming what is obvious to you)
As long as it is possible to stick with the basic workflow of git without anything fancy, similar what I have seen while skimming the nipy docs, I think it is not a problem on windows.
I think that is true that most of us won't need to go further than the nipy basic workflow - but we haven't been using git long enough to know that very well. I would defer to the git masters out there - David, Pauli and others - ?
However, if/when parts of statsmodels go into scipy and I have to do maintenance of less isolated code, then I think the Mercurial interface might be my preferred choice.
I haven't used Mercurial much yet, but I don't see any problems with it.
So, the bottom line is, that documentation for the hg-git interface would be very useful for Windows users (or those that think git is a strange/unfamiliar concept.)
So - two issues:
1) The conceptual issues involved in switching mind-set from svn or bzr to git. That may require some thought and documentation 2) There might be some technical issues using git on windows - but I think so far we don't have any reason to think so? 3) Some people may prefer mercurial for other reasons; it would be good to respect that if possible.
So, it may well be worth making a hg-git doc for numpy when we do the transition - with the caveats that David raised.
In the meantime, it would be very good to hear of any problems that do come up specifically using git on windows...
Right now I only use 3 or so git commands and I don't see any problems. Cheers, Josef
See you,
Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Hi,
# initial git clone of 'trunk' git clone git://github.com/nipy/nipy.git # make a heavyweight branch git clone nipy my-nipy-branch # push somewhere # First add repo for the branch via github interface, then cd my-nipy-branch git remote add origin git@github.com:matthew-brett/my-nipy-branch.git git push origin master
However, I think this works only with a remote remote, github or similar When I looked at bzr vs hg vs git, I also thought about my private use, where I didn't find a way to compare across branches in separate directories.
Ah - with the paragraph below, I begin to see what you mean. You often have uncommitted changes, hence the need for several working trees. You can compare repositories, but it's a bit harder that with - say - bzr: http://stackoverflow.com/questions/687450/how-do-i-compare-two-git-repositor...
My work style in statsmodels is similar to the mailing list reference that Fernando gave. Mainly I have many uncommitted files in each branch, test scripts, examples scripts, quick checks whether a rewrite would work, or R and matlab files. None of it I want to commit to the repository, but have available when I work on it again.
Right - I see your point. Maybe the git solution to that workflow will be more obvious to others than it is to me.
A great deal of freedom gives any new user also a lot of opportunities to shoot in his own foot. And my impression from the mailing lists is that the rescue team is called more often than with bzr or hg. My recommendation to myself is not to use with git more than the 10 or so basic commands similar to svn or bzr. Then I don't think it will create any real problems.
That's fair. It is easier to mess up with git - it has a steeper learning curve when you go past the basics. It is well worthwhile spending some time understanding the model underneath it - good links from Fernando's page : http://www.fperez.org/py4science/git.html ; I particularly liked http://tom.preston-werner.com/2009/05/19/the-git-parable.html .
So the basic workflow description by the nipy and numpy/scipy git developers will be the most useful help for the transition. (just confirming what is obvious to you)
Worth saying - thanks for the thoughtful feedback, Matthew
On 06/02/2010 05:31 AM, josef.pktd@gmail.com wrote:
On Tue, Jun 1, 2010 at 3:44 PM, Matthew Brett<matthew.brett@gmail.com> wrote:
Hi,
a) are there any problems that you know of using git from the windows shell?
None in principle here (and from what I've garnered through the discussion, I am supportive of the move, as long as we don't deprecate the SVN trunk too quickly), but do we have anyone, even just one person, who is already reasonably facile in this regard who'd be willing to support others through the transition?
I would not claim to be very experienced, but I have not had any problems using msysgit with either the windows shell or the (rather good) windows power shell. The bash shell does have problems but the windows shells have proved more useful.
It depends a lot on the part that I am working on. I wouldn't want to switch statsmodels where I do my main development to git.
I don't think it is anyone's intention to force you to use git for your own packages :)
As long as it is possible to stick with the basic workflow of git without anything fancy, similar what I have seen while skimming the nipy docs, I think it is not a problem on windows. The basic commands and for example eclipse, GUI plugins look similar enough.
We started some time ago a document in that respect: instead of describing git's features, we have a workflow-oriented document: http://projects.scipy.org/numpy/wiki/GitWorkflow David
participants (8)
-
Charles R Harris -
David -
David Goldsmith -
Fernando Perez -
josef.pktd＠gmail.com -
Matthew Brett -
Stéfan van der Walt -
Vincent Davis