Python Goes Mercurial
Lawrence D'Oliveiro
So what were these "strong antipathies" towards Git, exactly?
andrew cooke
> <http://arstechnica.com/open-source/news/2009/03/python-adopts-the-mercurial-version-control-system.ars>
>
> So what were these "strong antipathies" towards Git, exactly?
you're at the wrong group. there's a lot of interesting discussion in
python-dev about this (see thread titled "And the winner is...").
i haven't read the article you link to, but compared to what i've read on
dev "strong antipathies" sounds a bit over-hyped.
andrew
Lawrence D'Oliveiro
cooke wrote:
> Lawrence D'Oliveiro wrote:
>> <http://arstechnica.com/open-source/news/2009/03/python-adopts-the-
mercurial-version-control-system.ars>
>>
>> So what were these "strong antipathies" towards Git, exactly?
>
> i haven't read the article you link to, but compared to what i've read on
> dev "strong antipathies" sounds a bit over-hyped.
That was the phrase used by GvR.
andrew cooke
well if you find any, please do report back.
andrew
John Yeung
> >>> So what were these "strong antipathies" towards Git, exactly?
>
> >> compared to what i've read on dev
> >> "strong antipathies" sounds a bit over-hyped.
>
> > That was the phrase used by GvR.
>
> well if you find any, please do report back.
Andrew, perhaps you stopped reading too early. Here's one that
clearly expresses strong antipathy:
http://mail.python.org/pipermail/python-dev/2009-March/087971.html
(When challenged, he later goes on to claim "Internet hyperbole",
which I'll buy.)
John
Terry Reedy
> <http://arstechnica.com/open-source/news/2009/03/python-adopts-the-mercurial-version-control-system.ars>
>
> So what were these "strong antipathies" towards Git, exactly?
The relevant PEP is http://www.python.org/dev/peps/pep-0374/
To some Pythonic eyes, the git command syntax in the examples given is
less graceful.
Another thing mentioned in the py-dev thread. Git apparently allows
'changing history' by changing the underlying directed acyclic graph.
Some like that, some do not. (I do not completely understand this, but
you asked...)
tjr
Lawrence D'Oliveiro
> Lawrence D'Oliveiro wrote:
>> <http://arstechnica.com/open-source/news/2009/03/python-adopts-the-mercurial-version-control-system.ars>
>>
>> So what were these "strong antipathies" towards Git, exactly?
>
> The relevant PEP is http://www.python.org/dev/peps/pep-0374/
Useful link, though it seems incomplete.
Interesting phrase "To make up for svn's lack of cheap branching"--it's not the branching that's the problem in Subversion, it's the merging. :)
> Git apparently allows 'changing history' by changing the underlying
> directed acyclic graph.
Every object in a Git repository is identified by the SHA-1 hash of its entire contents. For a commit object, that includes the references to its parent commit(s). Thus,
there's no way <http://wlug.org.nz/VeryImpossible> to change these while preserving the identity of the commit object.
Yes, it's easy with the low-level Git commands to go back and synthesize past history, but you can't hide the fact that you've done so. One of the design goals of Git
was guaranteeing the integrity of the entire commit history.
Lawrence D'Oliveiro
a443-6a9...@o6g2000yql.googlegroups.com>, John Yeung wrote:
> Here's one that clearly expresses strong antipathy:
>
> http://mail.python.org/pipermail/python-dev/2009-March/087971.html
There are lots of GUI- and Web-based front ends to Git. And look at on-line
services like GitHub and Gitorious. The level of support for it is huge.
Paul Rubin
> > So what were these "strong antipathies" towards Git, exactly?
>
> The relevant PEP is http://www.python.org/dev/peps/pep-0374/
Interesting. I'm on a project that switched from Mercurial to Git
recently. I don't have much of a sense of the relevant differences
but other people on the project seemed to prefer Git rather strongly.
Git does seem to faster, contrary to the measurements in that PEP.
Carl Banks
central.gen.new_zealand> wrote:
> <http://arstechnica.com/open-source/news/2009/03/python-adopts-the-mer...>
>
> So what were these "strong antipathies" towards Git, exactly?
Apparently Mercurial had it's own hate club, and the reaction on
python-dev was so severe GvR backtracked on his decision.
Trying to appease a least common denominator, he changed his mind and
Python is going with SCCS instead.
Carl Banks
Chris Rebert
This is why I hate staying up late on March 31st...
Cheers,
Chris
--
I have a blog:
http://blog.rebertia.com
Paul Boddie
> Terry Reedy <tjre...@udel.edu> writes:
> > > So what were these "strong antipathies" towards Git, exactly?
>
>
> Interesting. I'm on a project that switched from Mercurial to Git
> recently. I don't have much of a sense of the relevant differences
> but other people on the project seemed to prefer Git rather strongly.
> Git does seem to faster, contrary to the measurements in that PEP.
From what I've seen by browsing the blogs of various large
communities, there always seems to be large numbers of Git advocates
(although "fanboys" might be a more accurate term in numerous cases)
ready to crowd out blog comments with single line insistences that
projects switch to Git. Indeed, I've even seen something resembling an
advocacy site for Git where there's a comparison to Mercurial and
Bazaar, although the benchmarks seem to be done with a certain amount
of honesty. Consequently, many projects seem to choose Git either on
the basis of what other people have supposedly done, or on the "hacker
cred" supposedly conferred through its association with Linus
Torvalds.
I've also heard various tales of Git usage where "strong antipathies"
would be a fairly accurate summary of user experiences, and this is
where such experiences can be contrasted with solid experiences with
other version control systems. And I've heard stories of "bait and
switch" with Git: "you can do XYZ with Git but not with ..." followed
by the discovery that you can't realistically do XYZ with Git, either.
Such advocacy makes me deeply cynical about Git.
To be fair, Git usability has apparently come some way since, say,
2006 when I first encountered Git and Mercurial, with the former being
recommended by the guys who develop itools (whose judgement I
generally trust) but with the caveat that one used the Cogito front-
end at that time, and the latter by the guys who develop MoinMoin
(whose judgement I also trust). The difference between the two DVCSs
as far as I have seen is that Mercurial has always been as usable as
it is today without additional tools. In addition, there seems to be
more honesty from the Mercurial community about what Mercurial can and
cannot support, as opposed to the disinformation cloud (or perhaps
uninformation cloud) that seems to surround Git.
As for the performance of these tools, you wouldn't think Mercurial
was written in Python (admittedly with some C) and Git was written in
C looking at various benchmarks. For what it's worth, this BDFL
decision is one I actually agree with.
Paul
Tim Daneliuk
;)
A few years ago I had a very large client - many multi-billions of
dollars in revenue annually - that ran their entire custom IT
system from a home grown variant of SCCS. It did work, but when
I suggested that better open source tools existed, they kindly
explained their complete lack of interest in moving several millions
of lines of code to anything new. Go figure.
--
----------------------------------------------------------------------------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
Lawrence D'Oliveiro
> ,,, when I suggested that better open source tools existed, they kindly
> explained their complete lack of interest in moving several millions
> of lines of code to anything new.
What was their explanation?
Lawrence D'Oliveiro
a80d-574...@q16g2000yqg.googlegroups.com>, Paul Boddie wrote:
> And I've heard stories of "bait and
> switch" with Git: "you can do XYZ with Git but not with ..." followed
> by the discovery that you can't realistically do XYZ with Git, either.
Cite?
Tim Daneliuk
Their entire internal workflow from development through final release
and deployment was built around these ancient/nonstandard toolset. It
was economically infeasible to retool both the technology and the
processes for millions of lines of code under version control - there
just wasn't an ROI for it. This is not uncommon in large legacy
environments in my experience.
Paul Boddie
central.gen.new_zealand> wrote:
> In message <7a1dd0d8-1978-470b-
>
> a80d-57478d7f7...@q16g2000yqg.googlegroups.com>, Paul Boddie wrote:
> > And I've heard stories of "bait and
> > switch" with Git: "you can do XYZ with Git but not with ..." followed
> > by the discovery that you can't realistically do XYZ with Git, either.
>
> Cite?
Well, I "heard" stories rather than read them, so I can't cite them,
but I believe that one argument crafted to favour Git was that it is
great for history editing, but it turns out that it isn't so great, as
the following commentary points out:
"You can do it, but as soon as you go to merge with another repo that
had the unedited commit history, you’ll bump into weirdness (and
probably invalidate your whole reason for rebasing, which was to clean
up the history)."
- http://adam.blog.heroku.com/past/2008/6/30/rebasing_is_editing_commits/
I'm sure other people have their own tales of a similar nature.
Paul
David Cournapeau
>
> "You can do it, but as soon as you go to merge with another repo that
> had the unedited commit history, you’ll bump into weirdness (and
> probably invalidate your whole reason for rebasing, which was to clean
> up the history)."
>
> - http://adam.blog.heroku.com/past/2008/6/30/rebasing_is_editing_commits/
>
> I'm sure other people have their own tales of a similar nature.
It is explained in this article why rebase can't be used for something
which will be the base for upcoming merges; not all branches are
intended this way (but most public ones are). I would say this shows
one feature which I think matters a lot in git, more than rebasing
itself: multiple branches in a repo, and very cheap branching (in CPU
cost, space and workflow) so that you can use private branches for
experimentation.
cheers,
David
Kay Schluehr
central.gen.new_zealand> wrote:
> In message <35d429fa-5d13-4703-
>
> a443-6a95c740c...@o6g2000yql.googlegroups.com>, John Yeung wrote:
> > Here's one that clearly expresses strong antipathy:
>
> > http://mail.python.org/pipermail/python-dev/2009-March/087971.html
>
> There are lots of GUI- and Web-based front ends to Git. And look at on-line
> services like GitHub and Gitorious. The level of support for it is huge.
Ironically Mercurials most popular UI frontend Tortoise is going to
crash Python tools ( like Wing-IDE ) on Windows. That's a known issue
for about a year and more and the developers are not inclined to fix
it. This doesn't really increase my trust that Mercurials UI tools are
of a higher quality than Git's no matter which platform is used.
David Smith
The conflict between TortoiseHg and Wing IDE can be fixed by simply
uninstalling the Tortoise Overlays. You loose the graphic overlay on
folders, but otherwise everything works.
--David
Kay Schluehr
Good to know. Uninstalling a major feature that enhances usability
just to make it usable isn't much less ironic though.
andrew cooke
> 2009/4/2 Jeremiah Dodds <jeremia...@gmail.com>
>
>> The one thing that makes me want to use git more than any other dvcs is
>> that you don't have to create a new directory for branches. This may be
>> possible in other dvcs's , but git is the only one I've seen advertise
>> the
>> capability.
[...]
> That is the main reason why I switched to git at my work.
> As for the git rebase, I don't ever plan on using that 'feature'. Even
> though I would rather have had GvR pick git, I think he did a good job
> deciding.
please can you explain this? i can think of a couple of things you could
mean, but neither of them seem to make much sense to me.
one is that hg only allows you one branch per repository. i checked the
docs and that's not true - see 2/3 way down
http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html
- which describes how you can branch in the repository and then swap your
working copy between them.
another is that you want a directory structure like:
myproject/
tag1/
tag2/
and for there to be a single repository in myproject, rather than two
repositories, one in tag1 and one in tag2. since a dvcs works across
repos as well as it works within a repo, i don't see how this is
significantly different to having two repositories, one in tag1 and one in
tag2. how does it matter?
or do you mean something else?
i don't use a dvcs myself - i'm happy with svn - but i am curious about
what the advantages and disadvantages might be.
thanks,
andrew
Rhodri James
wrote:
> Good to know. Uninstalling a major feature that enhances usability
> just to make it usable isn't much less ironic though.
Meh. Use the command line like God intended.
--
Rhodri James *-* Wildebeeste Herder to the Masses
Kay Schluehr
I'm sorry to say this Rhodri but there is probably no god ;)
The reason I like overlays is that they are data displays that
highlight changes without letting me do any action. The VCS works for
me before I'm doing any work with it and that's a good thing because
I'm *always* lazy.
Patrick Mullen
>
>
> On Thu, Apr 2, 2009 at 9:02 PM, andrew cooke <and...@acooke.org> wrote:
>>
>> Echo wrote:
>> > 2009/4/2 Jeremiah Dodds <jeremia...@gmail.com>
>> >
>> >> The one thing that makes me want to use git more than any other dvcs is
>> >> that you don't have to create a new directory for branches. This may be
>> >> possible in other dvcs's , but git is the only one I've seen advertise
>> >> the
>> >> capability.
>> [...]
>> > That is the main reason why I switched to git at my work.
>> > As for the git rebase, I don't ever plan on using that 'feature'. Even
>> > though I would rather have had GvR pick git, I think he did a good job
>> > deciding.
> discouraged (I am not experienced with hg, and haven't read the docs
> thoroughly, so I could be off base here). In most (d)vcs's , there is
> normally a one-to-one relationship between project branches and directories
> on your filesystem. In git, there is normally a many-to-on relationship
> between project branches and directories on your filesystem - branching is
> cheap and easy, and you can branch for every little fix or feature you want
> to do, keeping one directory with multiple logical development paths with
> basically no pain.
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
I don't think it's discouraged at all. There are several ways to
accomplish a similar workflow if you want a quick, short-lived branch.
The ones I know of, are named branches, bookmarks, and mercurial
queues. I have a hard time wrapping my head around what all of these
(and git branching) mean, since a quick branch is something I rarely
need in my personal development. The differences between each
approach is very difficult for me to see. But they all let you have
one set of files and work on disparate things at once to merge later.
Queues (which is a patch stack) seem useful but also dangerous, since
you can do a lot of switching back and forth without actually
commiting. Since you can apply any of the queues to your working
directory, they might work well for a short lived feature that you
potentially put into a real branch or into the main if the feature is
more complete and less experimental.
Named branches work off of a changeset I believe. At any time you can
rename the current branch, commit new stuff from that point in
history, and you have a new branch; using the name to keep track of
where you are. If you want to switch branches, you just update the
working copy to be the new branch you want to work from.
There are probably some advantages to how git handles things,
considering this is the main feature I hear cited at something git
does certifiably better, but I wouldn't know what that would be.
Oh, and merc recently got a rebase as well, for good or ill.
"Martin v. Löwis"
>>> i haven't read the article you link to, but compared to what i've read
>>> on
>>> dev "strong antipathies" sounds a bit over-hyped.
>> That was the phrase used by GvR.
>
> well if you find any, please do report back.
I don't like git because it is too difficult for me. In many cases,
git would refuse to do operations like updating or local committing,
producing error messages I was not able to understand (most of the
time including long sequences of hexdigits which I did not recognize,
or complaining about conflicts in long lists of files I knew I hadn't
touched at all). In some cases, I lost all my changes, and had to
do them all over again.
Regards,
Martin
Lawrence D'Oliveiro
wrote:
> I don't like git because it is too difficult for me. In many cases,
> git would refuse to do operations like updating or local committing,
> producing error messages I was not able to understand ...
Post an example of what you were trying to do, with the exact messages, and
we can walk you through it.
Ben Finney
No, please, not in this forum. It would be quite off-topic, and Git
has its own discussion forums; please use those.
--
\ Eccles: “I just saw the Earth through the clouds!” Lew: “Did |
`\ it look round?” Eccles: “Yes, but I don't think it saw me.” |
_o__) —The Goon Show, _Wings Over Dagenham_ |
Ben Finney
"Martin v. Löwis"
>> git would refuse to do operations like updating or local committing,
>> producing error messages I was not able to understand ...
>
> Post an example of what you were trying to do, with the exact messages, and
> we can walk you through it.
Unfortunately, these are many months ago, and I don't recall the exact
error messages. I wasn't really asking for help, merely pointing out
that I dislike git because it makes me ask for help (something I did
not have to do for CVS or subversion, except for very special cases).
Regards,
Martin
"Martin v. Löwis"
>> git would refuse to do operations like updating or local committing,
>> producing error messages I was not able to understand ...
>
> Post an example of what you were trying to do, with the exact messages, and
> we can walk you through it.
Unfortunately, these are many months ago, and I don't recall the exact
"Martin v. Löwis"
>> git would refuse to do operations like updating or local committing,
>> producing error messages I was not able to understand ...
>
> Post an example of what you were trying to do, with the exact messages, and
> we can walk you through it.
Unfortunately, these are many months ago, and I don't recall the exact
sk...@pobox.com
Martin> I wasn't really asking for help, merely pointing out that I
Martin> dislike git because it makes me ask for help (something I did
Martin> not have to do for CVS or subversion, except for very special
Martin> cases).
In fact, Martin is generally the guy answering the CVS and Subversion
questions.
--
Skip Montanaro - sk...@pobox.com - http://www.smontanaro.net/
"XML sucks, dictionaries rock" - Dave Beazley
Lawrence D'Oliveiro
wrote:
>In message <gr647t$jf2$1...@lust.ihug.co.nz>, Lawrence D'Oliveiro wrote:
>
>> Post an example of what you were trying to do, with the exact messages,
>> and we can walk you through it.
>
> Unfortunately, these are many months ago, and I don't recall the exact
> error messages. I wasn't really asking for help, merely pointing out
> that I dislike git because it makes me ask for help (something I did
> not have to do for CVS or subversion, except for very special cases).
Everybody needs help sometime. If you're accustomed to centralized version
control (CVS and SVN), it probably takes some time to get used to the way
distributed systems work. It's nothing to be ashamed of.
Michele Simionato
central.gen.new_zealand> wrote:
> Everybody needs help sometime. If you're accustomed to centralized version
> control (CVS and SVN), it probably takes some time to get used to the way
> distributed systems work. It's nothing to be ashamed of.
If Martin - which is well above the average programmer -
says that he would need help with Git, I take this as
meaning that most people would get lost with Git.
Heck, I am getting lost even with SVN!
Michele Simionato
P.S. the thing I do not understand if why we are moving
away from Subversion. Will all the new features entered
in 1.5 and 1.6 Subversion is now not so bad as it used to
be and it has the advantage of being already there and
familiar to most people.
Jeroen Ruigrok van der Werven
>P.S. the thing I do not understand if why we are moving
>away from Subversion. Will all the new features entered
>in 1.5 and 1.6 Subversion is now not so bad as it used to
>be and it has the advantage of being already there and
>familiar to most people.
I don't fully get the whole 'we MUST go DVCS!' meme going around the
Internet either.
There's situations where a centralised system like SVN works and there's
situations where a DVCS works better.
Unfortunately there's a whole group of rabid, zealous proponents of one
system or ther other out there that are quick to denounce any of your
rationale for going with one or the other if it is not their $FAVOURITE_ONE.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Love conquers all...
Lawrence D'Oliveiro
fc5571...@c11g2000yqj.googlegroups.com>, Michele Simionato wrote:
> If Martin - which is well above the average programmer -
> says that he would need help with Git, I take this as
> meaning that most people would get lost with Git.
I don't feel lost with Git. Does that make me an above-average programmer?
> P.S. the thing I do not understand if why we are moving
> away from Subversion.
Because it's still centralized. That means different developers cannot pursue
parallel branches on their own, those branches must be represented on the
server.
Lawrence D'Oliveiro
> There's situations where a centralised system like SVN works and there's
> situations where a DVCS works better.
Most of the people using Subversion seem to be corporates with a
centralized, top-down-controlled policy for development.
Conway's Law in effect, I guess.
> Unfortunately there's a whole group of rabid, zealous proponents...
Tell you what, keep the ad-hominem bullshit out of this discussion, and I
agree to do the same. Deal?
Michele Simionato
central.gen.new_zealand> wrote:
> Michele wrote:
> > the thing I do not understand if why we are moving
> > away from Subversion.
>
> Because it's still centralized. That means different developers cannot pursue
> parallel branches on their own, those branches must be represented on the
> server.
Yes, but Python managed to work this way for nearly two
decades and I am not sure the change is really required.
Notice that I did use a DVCS in the past (Darcs) and
in principle I like DVCS better, but in practice there
are too many of them nowadays, and I would wait for
a few years to see if the situation stabilizes before
changing the old route. But this point is moot, of course,
since the BDFL has already spoken. I take the core
developers are happy with the choice.
The relevance for me is that at work we use Subversion,
but now that Python uses mercurial I am sure there will
be coworkers wanting to switch to Mercurial and I would
like to understand what are the tradeoffs involved.
Jeroen Ruigrok van der Werven
>Most of the people using Subversion seem to be corporates with a
>centralized, top-down-controlled policy for development.
Not just corporations. An open source or other type of organisation might
just as well have requirements that mandate a different kind of policy.
>Tell you what, keep the ad-hominem bullshit out of this discussion, and I
>agree to do the same. Deal?
I guess I touched a nerve, so you must consider yourself one of those then.
Just for the record: I meant that there's always a group who actively push
one solution over all others without regard to what the current situation
demands. If you cannot step back and look at the whole without trying to
push your own things, there's nary a word other than rabid and zealous for
that type of behaviour.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
How are the mighty fallen...
David Cournapeau
<asm...@in-nomine.org> wrote:
> -On [20090405 06:05], Michele Simionato (michele....@gmail.com) wrote:
>>away from Subversion. Will all the new features entered
>>in 1.5 and 1.6 Subversion is now not so bad as it used to
>>be and it has the advantage of being already there and
>>familiar to most people.
>
> Internet either.
I think it is often poorly 'marketed', and not well explained. But as
someone whose first source control system which made sense was a DVCS,
I can assure you that svn feels clumsy, slow, inadequate and extremely
primitive. Most people justification for svn is based on the fact they
are used to the workflow. Using DVCS to mimic the svn workflow is an
error IMHO. What would have happened if people tried to mimic the
visual sourcesafe workflow, with locks and co, with svn ? To me,
defending svn against DVCS is like defending the lock-per-file
approach of visual sourcesafe and the likes. Believe or not, there are
some people who think this lock-based workflow is better.
A simplistic analogy: svn it to CVS what C++ is to C, but try selling
C++ to python developers :)
David
Ben Finney
> -On [20090405 09:35], Lawrence D'Oliveiro (l...@geek-central.gen.new_zealand) wrote:
> >Tell you what, keep the ad-hominem bullshit out of this discussion,
> >and I agree to do the same. Deal?
>
> I guess I touched a nerve, so you must consider yourself one of
> those then.
Alternative explanation: You made bullshit ad-hominem attacks instead
of addressing the arguments. Please cut it out.
> Just for the record: I meant that there's always a group who
> actively push one solution over all others without regard to what
> the current situation demands. If you cannot step back and look at
> the whole without trying to push your own things, there's nary a
> word other than rabid and zealous for that type of behaviour.
If you can look at the process that was followed in this decision and
see “push one solution over all others without regard to what the
current situation demands” you're not looking very hard.
--
\ “I am amazed, O Wall, that you have not collapsed and fallen, |
`\ since you must bear the tedious stupidities of so many |
_o__) scrawlers.” —anonymous graffiti, Pompeii, 79 CE |
Ben Finney
Jeroen Ruigrok van der Werven
>If you can look at the process that was followed in this decision and
>see “push one solution over all others without regard to what the
>current situation demands” you're not looking very hard.
I did not argue the decision for the Python project to use a DVCS at all,
which was evident from my initial email.
I merely stated that I cannot understand why there's a meme and/or group of
people on the 'net that vehemently declare that everything less than a DVCS
sucks.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Wisdom is the difference between knowledge and experience...
Lawrence D'Oliveiro
bf6e-587...@u8g2000yqn.googlegroups.com>, Michele Simionato wrote:
> The relevance for me is that at work we use Subversion,
> but now that Python uses mercurial I am sure there will
> be coworkers wanting to switch to Mercurial and I would
> like to understand what are the tradeoffs involved.
Eric Raymond has a good survey of what the important issues that they
address and the differences between them
<http://www.catb.org/~esr/writings/version-control/version-control.html>. I
would say that, basically, it's all about increasingly sophisticated ways of
handling merging.
sk...@pobox.com
>> If Martin - which is well above the average programmer - says that he
>> would need help with Git, I take this as meaning that most people
>> would get lost with Git.
Lawrence> I don't feel lost with Git. Does that make me an above-average
Lawrence> programmer?
No, perhaps it just means git fits your brain better than it fits Martin's.
I have trouble understanding any of the DVCS tools, but I think it's mostly
because I'm overwhelmed by the seemingly infinite variety of workflows.
Delaney, Timothy (Tim)
Unfortunately, I get asked to top-post here at work ...
Tim Delaney
Lawrence D'Oliveiro
<http://www.ulrikchristensen.dk/scripts/montypython/mrgit.html>