On Mon, Apr 13, 2009 at 11:02 PM, Martin Geisler wrote:
> You're right, the UI is not so good. In particular, you cannot use 'hg
> diff' to compare repositories. The rdiff extension does this, though:
>
> http://www.selenic.com/mercurial/wiki/index.cgi/RdiffExtension
In git, it is not just abou
On Mon, Apr 13, 2009 at 10:10 PM, David Soria Parra wrote:
>
> You can have multiple heads in a repository and if you created a bookmark
> on the remote site you can refer to it by using ssh://url#bookmarkname .
> It is not possible to get a list of bookmarks at the moment, nor is it
> possible t
2009/4/14 Stéfan van der Walt :
> 2009/4/12 Stéfan van der Walt :
>> I underestimated the
>> value of this type of manipulation, and of having a clearly structured
>> and easily traversable history.
>
> I read that Bram Cohen of Codeville / "patience diff" fame doesn't
> agree with me, so I'll give
2009/4/12 Stéfan van der Walt :
> I underestimated the
> value of this type of manipulation, and of having a clearly structured
> and easily traversable history.
I read that Bram Cohen of Codeville / "patience diff" fame doesn't
agree with me, so I'll give his opinion too:
"""
Don't bother with a
David Cournapeau writes:
> On Mon, Apr 13, 2009 at 6:22 PM, Martin Geisler wrote:
>
>> hg diff -r F -r tip
>>
>> where 'tip' is a built-in name that always point to the newest
>> revision in a repository. If you have a bookmark named 'numpy-1.2.x'
>> on F you could write:
>>
>> hg diff -r nump
On Mon, Apr 13, 2009 at 6:22 PM, Martin Geisler wrote:
>
> hg diff -r F -r tip
>
> where 'tip' is a built-in name that always point to the newest revision
> in a repository. If you have a bookmark named 'numpy-1.2.x' on F you
> could write:
>
> hg diff -r numpy-1.2.x -r tip
Ok, so bookmarks ar
David Cournapeau writes:
Hi David x 2 :-)
I've put the David Soria on Cc since he wrote the bookmarks extension,
maybe he can give additional information. The thread can be found here:
http://thread.gmane.org/gmane.comp.python.numeric.general/29117
> Martin Geisler wrote:
>
>> [...] changese
Martin Geisler wrote:
> Ondrej Certik writes:
>
>> Plus with git, you can fetch the remote repository with all the
>> branches and browse them locally in your remote branches, when you are
>> offline. And merge them with your own branches. In mercurial, it seems
>> the only way to see what changes
Ondrej Certik writes:
> Plus with git, you can fetch the remote repository with all the
> branches and browse them locally in your remote branches, when you are
> offline. And merge them with your own branches. In mercurial, it seems
> the only way to see what changes are there and which branch a
Stéfan van der Walt wrote:
> 2009/4/13 Eric Firing :
>> Stéfan, or other git-users,
>>
>> One feature of hg that I use frequently is "hg serve", the builtin web
>> server. I use it for two purposes: for temporary local publishing
>> (e.g., in place of using ssh--sometimes it is quicker and easier)
2009/4/13 Stéfan van der Walt :
> 2009/4/13 Eric Firing :
>>
>> Stéfan, or other git-users,
>>
>> One feature of hg that I use frequently is "hg serve", the builtin web
>> server. I use it for two purposes: for temporary local publishing
>> (e.g., in place of using ssh--sometimes it is quicker and
2009/4/13 Eric Firing :
>
> Stéfan, or other git-users,
>
> One feature of hg that I use frequently is "hg serve", the builtin web
> server. I use it for two purposes: for temporary local publishing
> (e.g., in place of using ssh--sometimes it is quicker and easier), and
> for providing access to
Stéfan van der Walt writes:
> Hi Martin
>
> 2009/4/13 Martin Geisler :
>> In Mercurial it creates a *named
>> branch*, which are imbedded in the history and are used for long-term
>> development branches. Names of Git branches are not recorded in the
>> history and are thus well-suited for local
On Sun, Apr 12, 2009 at 10:13 PM, David Cournapeau
wrote:
> Eric Firing wrote:
>>
>> Sure enough, that is what I was looking for. (gitweb doesn't seem to
>> have the annotate [or blame, in git-speak] option, or the graph.)
>>
>
> It indeed does not support blame, which is a bit of a shame, as git
On Sun, Apr 12, 2009 at 7:13 PM, David Cournapeau
wrote:
> Eric Firing wrote:
>> It probably does--it is written in python.
>>
>
> Yes, but it is just a script to call git-daemon. I am somewhat doubtful
> that it would work on windows, but I would love being proven wrong :)
It uses os.fork() whic
Eric Firing wrote:
> Sure enough, that is what I was looking for. (gitweb doesn't seem to
> have the annotate [or blame, in git-speak] option, or the graph.)
>
gitweb does, you have to turn it on, though...
You need to add this to your gitweb.conf, though:
$feature{'blame'}{'default'} = [1];
Eric Firing wrote:
>
> Sure enough, that is what I was looking for. (gitweb doesn't seem to
> have the annotate [or blame, in git-speak] option, or the graph.)
>
It indeed does not support blame, which is a bit of a shame, as git
blame is so much better than svn blame (it automatically detec
David Cournapeau wrote:
> On Mon, Apr 13, 2009 at 9:46 AM, David Cournapeau wrote:
>> On Mon, Apr 13, 2009 at 9:26 AM, Eric Firing wrote:
>>> Stéfan, or other git-users,
>>>
>>> One feature of hg that I use frequently is "hg serve", the builtin web
>>> server. I use it for two purposes: for temp
On Mon, Apr 13, 2009 at 9:46 AM, David Cournapeau wrote:
> On Mon, Apr 13, 2009 at 9:26 AM, Eric Firing wrote:
>>
>> Stéfan, or other git-users,
>>
>> One feature of hg that I use frequently is "hg serve", the builtin web
>> server. I use it for two purposes: for temporary local publishing
>> (e
On Mon, Apr 13, 2009 at 9:26 AM, Eric Firing wrote:
>
> Stéfan, or other git-users,
>
> One feature of hg that I use frequently is "hg serve", the builtin web
> server. I use it for two purposes: for temporary local publishing
> (e.g., in place of using ssh--sometimes it is quicker and easier), a
Stéfan, or other git-users,
One feature of hg that I use frequently is "hg serve", the builtin web
server. I use it for two purposes: for temporary local publishing
(e.g., in place of using ssh--sometimes it is quicker and easier), and
for providing access to the very nice hgwebdir.cgi browsi
Hi Martin
2009/4/13 Martin Geisler :
> In Mercurial it creates a *named
> branch*, which are imbedded in the history and are used for long-term
> development branches. Names of Git branches are not recorded in the
> history and are thus well-suited for local experiments.
[...]
> The bookmarks ex
David Cournapeau writes:
> Ok, will look at it more closely (I have just made a hg repo from the
> numpy git one on my machine). I am still confused about how named
> branches are supposed to work (the hg book is a a bit light on this).
> For example, let's say I want to create a branch from a gi
Fri, 10 Apr 2009 18:50:36 -1000, Eric Firing wrote:
[clip]
>> Ah, I think I was confused between named branches and bookmarks. From
>> the description of bookmarks, this actually looks nearer to the git
>> cheap branch concept. I should really try it to get a good
>> understanding, though.
>
> I w
On Sun, Apr 12, 2009 at 12:58 PM, Ondrej Certik wrote:
>
> I am just surprised, you have exactly the same experience with bzr, I
> thought it's only hg.
I agree that simplicity is a bit overrated. Sure, bzr is simpler than
git - at the beginning. But once you start thinking about shared
reposito
2009/4/12 Fernando Perez :
> What you need to
> accept is that the core objects you should manipulate are the atomic
> change units needed to reconstruct the state of the project, and the
> connectivity between those units. If you have tools to manipulate
> said entities, you'll be able to really
On Sat, Apr 11, 2009 at 8:28 PM, Fernando Perez wrote:
> In bzr (and as far as I see, also in hg), this kind of history
> rewriting is near impossible, so the best you can do is make a merge
> commit and leave all that history in there, visible in the 'second
> level' log (indented in the text vi
2009/4/11 Stéfan van der Walt :
> From my POV, the current system is very unproductive and, while
> git-svn makes life a bit easier, it comes with its own set of
> headaches. Especially now that we are evaluating different
> work-flows, we need the right kind of vcs to back it up.
Please take th
2009/4/12 Charles R Harris :
> I vote that we don't even think about a decision until next year. The
> current system works well enough, I think. Meanwhile, the endless
> discussions are fun and pass the time.
I'll take that with a pinch of salt, as I assume it was intended :)
>From my POV, the c
2009/4/11 Stéfan van der Walt
> Hi all,
>
> DVCS discussions are notoriously unproductive, aren't they :)
>
> The two systems under discussion, git and hg, are both *almost* what
> we want, which means we have to make a choice and compromise.
>
>
> Here are some of the pros and cons I've picked u
Hi all,
DVCS discussions are notoriously unproductive, aren't they :)
The two systems under discussion, git and hg, are both *almost* what
we want, which means we have to make a choice and compromise.
Here are some of the pros and cons I've picked up, and I'm sure you
can add more:
Git has wel
On Sat, Apr 11, 2009 at 2:12 PM, Neal Becker wrote:
>
> Why not try asking on mercur...@selenic.com (gmane.comp.version-
> control.mercurial.general)
Done:
http://www.selenic.com/pipermail/mercurial/2009-April/025131.html
O.
___
Numpy-discussion maili
Ondrej Certik wrote:
> On Sat, Apr 11, 2009 at 11:44 AM, Neal Becker wrote:
>> Ondrej Certik wrote:
>>
>>> On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing
>>> wrote:
Ondrej Certik wrote:
> On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau
> wrote:
>> Ondrej Certik wrote:
>>>
On Sat, Apr 11, 2009 at 11:44 AM, Neal Becker wrote:
> Ondrej Certik wrote:
>
>> On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing wrote:
>>> Ondrej Certik wrote:
On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau
wrote:
> Ondrej Certik wrote:
>> It is maybe easier to learn how to w
Ondrej Certik wrote:
> On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing wrote:
>> Ondrej Certik wrote:
>>> On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau
>>> wrote:
Ondrej Certik wrote:
> It is maybe easier to learn how to work with different clones, but
> once you start working wit
On Sun, Apr 12, 2009 at 12:05 AM, Bruce Southey wrote:
> On Sat, Apr 11, 2009 at 5:38 AM, David Cournapeau wrote:
>> On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux
>> wrote:
>>> On Sat, Apr 11, 2009 at 12:05:55PM +0900, David Cournapeau wrote:
On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing
On Sat, Apr 11, 2009 at 5:38 AM, David Cournapeau wrote:
> On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux
> wrote:
>> On Sat, Apr 11, 2009 at 12:05:55PM +0900, David Cournapeau wrote:
>>> On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing wrote:
>>> No need to apologize, I think I used the work bash
On Sat, Apr 11, 2009 at 07:38:42PM +0900, David Cournapeau wrote:
> But that's a development tool. I think it is expected that people have
> to somewhat learn something about it. I agree we should care about
> barrier of entry - if there is no way to make Josef happy, for
> example, that would be a
On Sat, Apr 11, 2009 at 6:38 AM, David Cournapeau wrote:
> On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux
> wrote:
>> On Sat, Apr 11, 2009 at 12:05:55PM +0900, David Cournapeau wrote:
>>> On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing wrote:
>>> No need to apologize, I think I used the work bash
On Sat, Apr 11, 2009 at 6:52 PM, Gael Varoquaux
wrote:
> On Sat, Apr 11, 2009 at 12:05:55PM +0900, David Cournapeau wrote:
>> On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing wrote:
>> No need to apologize, I think I used the work bashing inappropriately
>> - I just wanted to say that the only way t
On Fri, Apr 10, 2009 at 11:54:59PM -0600, Charles R Harris wrote:
>It seems that designing an intuitive gui that fits a dvcs isn't all that
>easy, and git is a bit of a jump because of the way it treats branches and
>the irrelevence of time as opposed to change set sequence. I think the
On Sat, Apr 11, 2009 at 12:05:55PM +0900, David Cournapeau wrote:
> On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing wrote:
> No need to apologize, I think I used the work bashing inappropriately
> - I just wanted to say that the only way to understand the differences
> between the tools is to use th
On Fri, Apr 10, 2009 at 11:25 PM, David Cournapeau wrote:
> On Sat, Apr 11, 2009 at 1:00 PM, Charles R Harris
> wrote:
>
> > I think hg works in a similar manner to git. At least Linus said so in
> that
> > old google talk ;)
>
> Yes, compared to svn, hg, git and bzr are quite similar in a way. I
On Sat, Apr 11, 2009 at 1:00 PM, Charles R Harris
wrote:
> I think hg works in a similar manner to git. At least Linus said so in that
> old google talk ;)
Yes, compared to svn, hg, git and bzr are quite similar in a way. I
think the differences still matter, though.
> But hg doesn't/didn't hav
David Cournapeau wrote:
> On Sat, Apr 11, 2009 at 6:16 AM, Eric Firing wrote:
>
>> On my laptop, switching back and forth between the two active branches
>> of mpl takes about 3 s for the first and 2 s for the second, timed by
>> counting in my head.
>
> I think Ondrej cares more about being fas
On Fri, Apr 10, 2009 at 9:49 PM, David Cournapeau wrote:
> On Sat, Apr 11, 2009 at 12:37 PM, Charles R Harris
> wrote:
> >
> >
> > On Fri, Apr 10, 2009 at 8:17 PM, David Cournapeau
> > wrote:
> >>
> >> On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing
> wrote:
> >>
> >> >
> >> > Important note: if
On Sat, Apr 11, 2009 at 12:37 PM, Charles R Harris
wrote:
>
>
> On Fri, Apr 10, 2009 at 8:17 PM, David Cournapeau
> wrote:
>>
>> On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing wrote:
>>
>> >
>> > Important note: if there are any uncommitted changes when you run git
>> > checkout, Git will behave
On Fri, Apr 10, 2009 at 8:17 PM, David Cournapeau wrote:
> On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing wrote:
>
> >
> > Important note: if there are any uncommitted changes when you run git
> > checkout, Git will behave very strangely. The strangeness is predictable
> > and sometimes useful, bu
On Sat, Apr 11, 2009 at 11:53 AM, Eric Firing wrote:
>
> Please understand, I am not trying to bash git--it is clearly an
> enormously powerful and well-made tool--and I apologize if my posts have
> appeared to tend in that direction.
No need to apologize, I think I used the work bashing inappro
On Sat, Apr 11, 2009 at 6:16 AM, Eric Firing wrote:
>
> On my laptop, switching back and forth between the two active branches
> of mpl takes about 3 s for the first and 2 s for the second, timed by
> counting in my head.
I think Ondrej cares more about being faster than most of us - he is
just
David Cournapeau wrote:
> On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing wrote:
>
>> Important note: if there are any uncommitted changes when you run git
>> checkout, Git will behave very strangely. The strangeness is predictable
>> and sometimes useful, but it is best to avoid it. All you need t
On Sat, Apr 11, 2009 at 10:59 AM, Eric Firing wrote:
>
> Important note: if there are any uncommitted changes when you run git
> checkout, Git will behave very strangely. The strangeness is predictable
> and sometimes useful, but it is best to avoid it. All you need to do, of
> course, is commit
On Sat, Apr 11, 2009 at 10:30 AM, wrote:
>
> I updated my eclipse so I can try out the git eclipse plugin. Except
> for a description how to clone a github repository and push back to
> it, I didn't find much information on the internet.
FWIW, I tried the eclipse plugin yesterday, and I did not
Matthew Brett wrote:
> Hi,
>
> I enjoyed this quote from http://www.eecs.harvard.edu/~cduan/technical/git/
>
> Summary: You can only really use Git if you understand how Git works.
Matthew,
Nice link, thank you.
Another couple of quotes from that tutorial:
Important note: if there are any unc
On Fri, Apr 10, 2009 at 5:47 PM, Matthew Brett wrote:
> Hi,
>
> I enjoyed this quote from http://www.eecs.harvard.edu/~cduan/technical/git/
>
> Summary: You can only really use Git if you understand how Git works.
>
> "When I first started using Git, I read plenty of tutorials, as well
> as the us
Hi,
I enjoyed this quote from http://www.eecs.harvard.edu/~cduan/technical/git/
Summary: You can only really use Git if you understand how Git works.
"When I first started using Git, I read plenty of tutorials, as well
as the user manual. Though I picked up the basic usage patterns and
commands,
David Cournapeau wrote:
> Eric Firing wrote:
>> This is simply wrong. Mercurial uses hard links for cloning a repo that
>> is on the same disk, so it is faster and much more space-efficient than
>> copying the files.
>
> Yes, but maybe Ondrej talks about an older hg version ? Hg could not
> han
Well, there is a LOT to consider here, and I have virtually no
experience with any of the DVCSs, so I don't have any conclusions to
offer, but:
Windows support matters.
Tool support matters.
Those should be taken into consideration when making a choice.
-CHB
--
Christopher Barker, Ph.D.
Ocea
David Cournapeau wrote:
> Eric Firing wrote:
>> Speaking to Josef: does tortoise-hg provide a satisfactory windows gui,
>> from your standpoint?
>>
>
> Another solution may be eclipse integration. I don't know if that would
> work for Josef, but there is a git plugin for eclipse, and I can at
On Sat, Apr 11, 2009 at 1:43 AM, Christopher Barker
wrote:
> David Cournapeau wrote:
>>> we're really better off with a system with
>>> good tool support on all platforms.
>>
>> Why ? We are not python, where many core developers work on windows.
>
> As I understand it there is a dearth of Python
> * I use Python for a bunch of other stuff Matlab is not suitable for --
> This is my argument about usability and tool support. A few years back,
> CVS was a standard, now SVN is. I like that I can use the same tool to
> contribute to a whole bunch of OS projects, and I use it to manage all
> my
David Cournapeau wrote:
>> we're really better off with a system with
>> good tool support on all platforms.
>
> Why ? We are not python, where many core developers work on windows.
As I understand it there is a dearth of Python developers on Windows,
too... But anyway, we probably want MORE Win
Hi Josef,
josef.p...@gmail.com wrote:
>
> I tried out mercurial one year ago, including the eclipse plugin, but
> it didn't work very well compared to the svn plugin. And since at that
> time mercurial to svn connection wasn't very good, I gave up (I have
> all my work in svn). I haven't used it s
On Fri, Apr 10, 2009 at 5:13 AM, Matthieu Brucher
wrote:
> 2009/4/10 David Cournapeau :
>> Eric Firing wrote:
>>> Speaking to Josef: does tortoise-hg provide a satisfactory windows gui,
>>> from your standpoint?
>>>
>>
>> Another solution may be eclipse integration. I don't know if that would
>> w
2009/4/10 David Cournapeau :
> Eric Firing wrote:
>> Speaking to Josef: does tortoise-hg provide a satisfactory windows gui,
>> from your standpoint?
>>
>
> Another solution may be eclipse integration. I don't know if that would
> work for Josef, but there is a git plugin for eclipse, and I can at
Eric Firing wrote:
> Speaking to Josef: does tortoise-hg provide a satisfactory windows gui,
> from your standpoint?
>
Another solution may be eclipse integration. I don't know if that would
work for Josef, but there is a git plugin for eclipse, and I can at
least clone branches from a remote
On Fri, Apr 10, 2009 at 1:07 AM, David Cournapeau
wrote:
> Eric Firing wrote:
>>
>> This is simply wrong. Mercurial uses hard links for cloning a repo that
>> is on the same disk, so it is faster and much more space-efficient than
>> copying the files.
>
> Yes, but maybe Ondrej talks about an old
Eric Firing wrote:
>
> This is simply wrong. Mercurial uses hard links for cloning a repo that
> is on the same disk, so it is faster and much more space-efficient than
> copying the files.
Yes, but maybe Ondrej talks about an older hg version ? Hg could not
handle NTFS hardlink for some time,
On Fri, Apr 10, 2009 at 12:43 AM, Eric Firing wrote:
> Ondrej Certik wrote:
>> On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau
>> wrote:
>>> Ondrej Certik wrote:
It is maybe easier to learn how to work with different clones, but
once you start working with lots of patches and you need
Ondrej Certik wrote:
> On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau
> wrote:
>> Ondrej Certik wrote:
>>> It is maybe easier to learn how to work with different clones, but
>>> once you start working with lots of patches and you need to reclone
>>> all the time, then it's the wrong approach to
On Fri, Apr 10, 2009 at 7:56 AM, Ondrej Certik wrote:
> It is maybe easier to learn how to work with different clones, but
> once you start working with lots of patches and you need to reclone
> all the time, then it's the wrong approach to work, as it takes lots
> of time to copy the whole reposi
On Thu, Apr 9, 2009 at 10:45 PM, David Cournapeau
wrote:
> Ondrej Certik wrote:
>>
>> It is maybe easier to learn how to work with different clones, but
>> once you start working with lots of patches and you need to reclone
>> all the time, then it's the wrong approach to work, as it takes lots
>>
Ondrej Certik wrote:
>
> It is maybe easier to learn how to work with different clones, but
> once you start working with lots of patches and you need to reclone
> all the time, then it's the wrong approach to work, as it takes lots
> of time to copy the whole repository on the disk.
Yes, *I* know
On Thu, Apr 9, 2009 at 10:25 PM, David Cournapeau
wrote:
> josef.p...@gmail.com wrote:
>> So, for my
>> style, working with different clones instead of branches seems easier.
>>
>
> Yes, it is. There is no denying that git makes it more difficult for
> this workflow, and that git is more difficul
josef.p...@gmail.com wrote:
> So, for my
> style, working with different clones instead of branches seems easier.
>
Yes, it is. There is no denying that git makes it more difficult for
this workflow, and that git is more difficult at first for easy tasks. I
am interested in making it as easy a
On Thu, Apr 9, 2009 at 11:13 PM, David Cournapeau wrote:
> On Fri, Apr 10, 2009 at 5:30 AM, wrote:
>
>>
>> In the file browser, I'm still missing change dates, tree view doesn't
>> have dates to quickly see which files got changed last, e.g.
>>
>> http://projects.scipy.org/gitweb?p=scipy;a=tree
On Fri, Apr 10, 2009 at 2:29 AM, Christopher Barker
wrote:
> David Cournapeau wrote:
>> I don't think git-svn work well
>> or at all on windows.
>
> This brings up a key issue for Python: git does not support Windows very
> well -- which makes sense, given its history with Linux kernel development
On Fri, Apr 10, 2009 at 3:56 AM, Matthieu Brucher
wrote:
>
> Unfortunately, I'm investigating it for my professional use, and I
> don't have a decent Internet access (i.e. without proxies).
If you are behind a proxy, you have to use the (slower) http protocol.
That's actually a good argument in f
On Fri, Apr 10, 2009 at 5:30 AM, wrote:
>
> In the file browser, I'm still missing change dates, tree view doesn't
> have dates to quickly see which files got changed last, e.g.
>
> http://projects.scipy.org/gitweb?p=scipy;a=tree;h=refs/heads/trunk;hb=trunk
Yes, you can't see this cheaply with
On Thu, Apr 9, 2009 at 1:58 PM, Ondrej Certik wrote:
> On Thu, Apr 9, 2009 at 7:15 AM, Matthieu Brucher
> wrote:
>> 2009/4/9 David Cournapeau :
>>> On Thu, Apr 9, 2009 at 10:38 PM, Matthieu Brucher
>>> wrote:
2009/4/9 David Cournapeau :
> On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik w
>>> I was inquiring the use of git with the use of one of our internal svn
>>> repositories, just to have a feeling about it :(
>>
>> My opinion is that attempting to use git-svn to get a feeling of git is
>> not a good idea. There's too much slowness of svn involved, too much
>> pain of trying to
On Thu, Apr 9, 2009 at 11:16 AM, Andrew Straw wrote:
> Matthieu Brucher wrote:
>>> One thing about git-svn is that this is not really needed if you just
>>> use git and I installed git from source on many linuxes and clusters
>>> and it just works, as it is just pure C. I usually just use git-svn
Matthieu Brucher wrote:
>> One thing about git-svn is that this is not really needed if you just
>> use git and I installed git from source on many linuxes and clusters
>> and it just works, as it is just pure C. I usually just use git-svn on
>> my laptop/workstation, where I install the Debian/Ubu
> One thing about git-svn is that this is not really needed if you just
> use git and I installed git from source on many linuxes and clusters
> and it just works, as it is just pure C. I usually just use git-svn on
> my laptop/workstation, where I install the Debian/Ubuntu packages, and
> I create
On Thu, Apr 9, 2009 at 7:15 AM, Matthieu Brucher
wrote:
> 2009/4/9 David Cournapeau :
>> On Thu, Apr 9, 2009 at 10:38 PM, Matthieu Brucher
>> wrote:
>>> 2009/4/9 David Cournapeau :
On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik wrote:
> Yes.
Do you have any windows develop
David Cournapeau wrote:
> I don't think git-svn work well
> or at all on windows.
This brings up a key issue for Python: git does not support Windows very
well -- which makes sense, given its history with Linux kernel development.
I personally use SVN primarily form the command line on all syste
On Thu, Apr 9, 2009 at 11:15 PM, Matthieu Brucher
>
> Installed from source on a RH4. It complains about missing SVN/Core.pm.
you need the perl wrapper for subversion installed, and to set the
equivalent of PYTHONPATH for perl to it (sorry, the name of the
variable eludes me ATM, but I had to do t
2009/4/9 David Cournapeau :
> On Thu, Apr 9, 2009 at 10:38 PM, Matthieu Brucher
> wrote:
>> 2009/4/9 David Cournapeau :
>>> On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik wrote:
>>>
Yes.
>>>
>>> Do you have any windows developers (I am sorry, I am not familiar at
>>> all with sympy)?
>>>
>>>
On Thu, Apr 9, 2009 at 21:38, Matthieu Brucher
wrote:
> 2009/4/9 David Cournapeau :
> > On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik wrote:
> >
> >> Yes.
> >
> > Do you have any windows developers (I am sorry, I am not familiar at
> > all with sympy)?
> >
> > My main concern with git are:
> > -
On Thu, Apr 9, 2009 at 10:38 PM, Matthieu Brucher
wrote:
> 2009/4/9 David Cournapeau :
>> On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik wrote:
>>
>>> Yes.
>>
>> Do you have any windows developers (I am sorry, I am not familiar at
>> all with sympy)?
>>
>> My main concern with git are:
>> - you m
2009/4/9 David Cournapeau :
> On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik wrote:
>
>> Yes.
>
> Do you have any windows developers (I am sorry, I am not familiar at
> all with sympy)?
>
> My main concern with git are:
> - you may need the command line
> - the index can be confusing (you can avo
On Thu, Apr 9, 2009 at 21:09, wrote:
> On Thu, Apr 9, 2009 at 6:00 AM, Ondrej Certik wrote:
> > On Wed, Apr 8, 2009 at 11:04 PM, David Cournapeau
> wrote:
> >> On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik wrote:
> >>
> >>> Yes.
> >>
> >> Do you have any windows developers (I am sorry, I am no
On Thu, Apr 9, 2009 at 6:00 AM, Ondrej Certik wrote:
> On Wed, Apr 8, 2009 at 11:04 PM, David Cournapeau wrote:
>> On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik wrote:
>>
>>> Yes.
>>
>> Do you have any windows developers (I am sorry, I am not familiar at
>> all with sympy)?
>
> Not much.
>
>>
>>
Gael Varoquaux wrote:
> That may be true for up, in my previous examples, but not for stat, info
> and revert.
>
hg does not have an info either. And for revert, st, ci, etc... what do
you feel is missing from there ?
http://projects.scipy.org/numpy/wiki/GitWorkflow
Which is an attempt to all
On Thu, Apr 09, 2009 at 08:14:20PM +0900, David Cournapeau wrote:
> Gael Varoquaux wrote:
> > On Thu, Apr 09, 2009 at 03:04:37PM +0900, David Cournapeau wrote:
> >> - git is not discoverable (you need to read some documentation)
> > Yes, I found that when I tried to use git to quickly get a few
Gael Varoquaux wrote:
> On Thu, Apr 09, 2009 at 03:04:37PM +0900, David Cournapeau wrote:
>
>> - git is not discoverable (you need to read some documentation)
>>
>
> Yes, I found that when I tried to use git to quickly get a few basic
> things done, I had a lot of stupid problems:
>
Th
On Thu, Apr 09, 2009 at 03:04:37PM +0900, David Cournapeau wrote:
> - git is not discoverable (you need to read some documentation)
Yes, I found that when I tried to use git to quickly get a few basic
things done, I had a lot of stupid problems:
$ git stat
git: 'stat' is not a git-command
The m
On Thu, Apr 9, 2009 at 3:04 AM, David Cournapeau
wrote:
> Ondrej Certik wrote:
>>
>> Yes, but in fact the staging area (if this is what you mean) is in
>> every VCS, only it's hidden, except git, where it is made explicit.
>>
>
> I am not sure the staging area concept is there in other vcs, becaus
Ondrej Certik wrote:
>
> Yes, but in fact the staging area (if this is what you mean) is in
> every VCS, only it's hidden, except git, where it is made explicit.
>
I am not sure the staging area concept is there in other vcs, because in
git it is intrinsically linked to idea that git tracks con
On Wed, Apr 8, 2009 at 11:04 PM, David Cournapeau wrote:
> On Wed, Apr 8, 2009 at 3:34 AM, Ondrej Certik wrote:
>
>> Yes.
>
> Do you have any windows developers (I am sorry, I am not familiar at
> all with sympy)?
Not much.
>
> My main concern with git are:
> - you may need the command line
O
1 - 100 of 111 matches
Mail list logo
