'So?' yourself.

You are correct that my quote 'does nowhere show that Google will NOT aggregate the information to improve their pagerank algorithim' (grammar notwithstanding). However that is a different topic (but as far as it goes I'm inclined to agree with you and they need to do something to improve pagerank...).

Anyway, I was replying to this part:

Which I believe my quote does show to be incorrect.

Mmmm, yeah, except Google themselves say:

https://www.google.com/support/profiles/bin/answer.py?answer=1186915

Well... It is December tomorrow so early next year probably isn't all that far away.

Sure, those are all pretty reasonable comments. I'll describe two ways of working with Git that I think address this somewhat.

I guess first up I would say that Git doesn't really push you towards a specific way of working so if there is a particular way that you want to do things then chances are you can do that with Git (that said there are definitely ways to do things that would be less worthwhile than others).

We switched to Git from Subversion where I work about 6 months ago and it's worked extremely well for us. We have a small team but it is spread across two or three countries (some of us move around a bit). For us we use a central model where there is a single 'authoritative' repository which we all push and pull from. So I don't share my repository directly with the other developers we all push and pull from the same central one (which we integrate with Hudson for CI).

So really we're not using the distributed for the sake of sharing code directly between us but because having access to the full repository (and did I mention that Git is fast?) allows us to do stuff we couldn't before. Once you've done the initial clone Git is very very fast (and things like svn log are much much faster with git because you don't have to do any network operations). Essentially we still have a central repository that update from and commit too simimlarly to SVN it's just that we can continue committing without a network connection and split our commits into sensible chunks of work that go into the central repository etc.

Now, in terms of doing something really distributed, you can do that too more easily than you described (though I've not really done it in any seriousness so not sure whether it is worth setting up). If you give me access to your repository, I give you access to mine and we both have access to a third repository. We can set up our own repositories to pull from both the others - so it is not so much more difficult to fetch the work of the other repositories into our own working tree. There is a tiny bit of extra work here - generally Git commands are bit more fine grained than something like Subversion so you do end up with more commands. For my use (and for my team) I've written some simple scripts that tie some stuff together (so I run 'git up' which simulates 'svn up' or 'cvs up' you could easily do the same for fetching from multiple repositories if you wanted ... ).

Generally I wouldn't really recommend working that way for a small group. What would make more sense would if you had two teams working on a product (maybe a team doing support and a team doing a product release) the release team might want to pull changes from the support team as they're finished and make sure that they're incorporated into the next release. Generally I think you'd have one person doing that and pushing it into a central repository for the release team (so each team would have a central repository but you might pull changes from one into the other). All this is far easier with Git than with Subversion (and I've worked in situations in the past where something like what I just described would have saved a lot of heartache and angst between teams).

But generally your point about Git being more complicated to use is absolutely correct and, sadly, when you ask for help you don't always get a nice answer (sometimes it's more along the lines of 'well the manuals say you shouldn't do that so you did it anyway now you're screwed and it serves you right for not understanding the internals of our magically wondrous system). So... Git *is* awesome, I'm really glad that my company uses it but it does have a very steep learning curve.

In terms of ease of use I quite like the look of Kiln which is some proprietary code wrapped around Mercurial and looks relatively easy to use (in general my impression is that Mercurial is easier to use). That said - Git is free...

I hope that helps I'm certainly not an expert with the finer points of Git but I'm happy to tell you what I know if you're interested (even if you stay with whatever you use if you're more informed then you're still going to make better decisions)....

-mark

Git will be faster and (much) more reliable.

CVS can lose your history without you noticing, Git won't do that. I've had subversion repositories become corrupted. On the other hand a) if a Git repository is corrupted then you know and b) in a worst case you can restore from one of the clones (as every developer has a clone of the central repository).

Yes but Git is still much much better. :)

Git would still be much faster for almost every operation than Subversion.

We have a small team but switching to Git from Subversion meant that check outs actually took measurably less time despite being a full copy of the repository rather than just the most recent revision.

Admittedly Subversion is probably a particularly bad example of non-DVCS but still...

nice :)

Thats insane - if someone publishes a paper and objections are raised then the *first* person you should look to for a response is the original author. Giving the right to reply is normal just about anywhere (e.g. http://www.bbc.co.uk/guidelines/editorialguidelines/edguide/fairness/rightofreply.shtml*). It is completely nuts to say that because someone has been criticised they're then out of the discussion because they'll try to defend themselves.

Beyond that:

It really depends on what they have to say doesn't it? If they're making poor arguments and fail to respond to criticism and just continue to restate the original argument then that would be bad. On the other hand what seems to be the case is that a group of scientists have grouped together to engage their critics and make clear responses and explanations where their original argument was unclear or misunderstood etc. Surely that is exactly what they should do?

* right of reply in a journalistic sense is slightly different but the concept is the same/similar

Wait! What? Did someone on the internet admit they were wrong?

What the hell is going on???

Yeah... because that happens all the time in other countries I can see how you'd be scared of health care that actually works.

wtf?

Are you kidding? This is insightful...?

First up - citrate is not an 'adverse condition' it is just something that the original bacteria were unable to use as a food source. That is not 'unable to use well' but unable to use *at all* - so if you put the original bacteria in a solution of only citrate (and no glucose) the population would not be able to grow due to lack of food but not because the citrate is harmful - they need glucose. So you're out right wrong to say that they already could metabolise it - that is really the whole point and if you'd read the article you'd know that btw - same for the morons that modded you insightful. If there was an 'adverse condition' then that would be that the amount of glucose in the solution was limited so that the bacteria would exhaust it everyday.

In an attempt to clarify why this is so interesting - the experiment* was to put the original strain in a solution of glucose and citrate - only the glucose was the limiting factor in the growth of the bacteria - as when the glucose was exhausted the bacteria could no longer continue to grow. This was repeated - so at the end of each day an extract of the bacteria in a phial would be extracted and put into a new phial of solution containing glucose and citrate.

The expected result - which kind of matches what you're describing, I think - is that subsequent generations would become more efficient at metabolising glucose and thats exactly what happened up to a point (and yes this is tweaking of an ability that was already there in that the bacteria was already able to metabolise glucose but they become more efficient at it). The really interesting thing is that after a while thousands of generations the bacteria evolved the ability to metabolise citrate - something that it could not do at all before.

Linking all this back to the summary - there were 45 mutations that they measured which were mostly related to the increased efficiency of glucose use (one of which was larger cell size, I believe). After the the ability to use citrate as a food source there was a much larger number of mutations (653) but more of these later mutations were neutral whereas the earlier mutations were largely about more efficient use of food. Anyway - the point of this new paper (as opposed to the original one which was about evolving to use citrate) is about measuring and observing rates of evolutionary change.

* disclaimer - my descriptions are largely based from memory, I don't have time to re-read the details and I may have a few points wrong. If there is a biologist around I'm sure they'll be able to correct me - however I am 100% certain that the original strain can not metabolise citrate as that is a large part of why this research is so impressive (the other part is the detailed level of record keeping that they've done to the point where they have frozen examples of the bacterial strain for every few hundred (few thousand? I forget the details) generations going back 20 years or more (hence they're able to do a lot of work from this - the citrate metabolism is just one part of that).

what about vampires?