GIT vs Other: Need argument

I am dealing with idiots. I'd rather not argue with them, but sadly I
cannot ignore them as they are my "seniors".

So, in 15 seconds, how does one argue that GIT is vastly superior to
other version control software, especially CVS.

Thanks,
P.

On 4/17/07, Pietro Mascagni [off-list ref] wrote:

So, in 15 seconds, how does one argue that GIT is vastly superior to
other version control software, especially CVS.

Adding some ammunition:

 - Old school SCMs allow you to branch, but are unable to keep track
of merges in any meaningful way. Every time you merge, history is
lost. GIT (and other DSCMs) have excellent branching _and_ merging
facilities.

 - Speed (try it on you project repo, or if the project is new, on a
repo sized to what you'd expectyour project to be).

 - Disconnected development. Checkouts on your laptop, continue
working when the server is down.

 - Extremely powerful and flexible if you are using the SCM to manage
the deployment.

 - Behaves transactionally, even when doing things like applying patches

 - Anon GIT is much easier to run (via http)

 - If the team is large, of for any reason the code needs review, you
can setup a tiered review/merge scheme like the linux team does --
instead of a shared repo, each developer has their own repos, and
integrators review and merge (or reject!).

 - Signed tags for releases

And yet... If the project ends up using CVS, you can setup your
cvs->git gateway. Even if you are always at the office, and just use
CVS most of the time, It's enormously useful to be able to call gitk,
use pickaxe, etc. And just by having those tools around your project
will probably benefit.

cheers,


martin

On Tue, Apr 17, 2007 at 10:02:18 +0100, Pietro Mascagni wrote:

So, in 15 seconds, how does one argue that GIT is vastly superior to
other version control software, especially CVS.

I think you are not talking about choosing SCM for a new project, as
it is even _hard to imagine_ that one would consider CVS nowadays :).
And if you are trying to convince people to do the migration from CVS
to GIT, then technical points alone won't probably help you.  GIT, and
actually most modern SCMs, are superior to CVS not simply because they
have some CVS's features improved, and some nice features added.
Modern SCMs implement completely different workflow model.  GIT's own
power in its rich toolset, but until people learn (or at least are
willing to learn) what the workflow is, and how it is supported by
these tools, there's little advantage in migration.  You can't really
explain why 'git commit; git push' into some central repository is
better than 'cvs commit', and pushing after every commit is what
people will be doing at first ;).  You should also realize that the
whole process is probably already built around CVS (CVS-specific
hooks, scripts that access CVS, say, for nightly testing, etc), that
would also have to be reimplemented.

You may consider another route: create a GIT mirror of CVS repository,
and update it, say, daily, with git-cvsimport.  Clone from this
mirror, and work with your own GIT tree, pushing back to CVS with
git-cvsexportcommit.  Yes, you will be dealing with problems that
wouldn't be there in the first place if everyone would use GIT, and
you will basically use CVS workflow, but still, this way is quite
manageable.  Then approach the most promising guy in the company, and
explain to him how you benefit from using GIT (gitk/qgit, git-bisect,
StGIT are among your friends here :)).  As the saying goes, "Better to
see once, then to hear about a hundred of times".  You are not
interested in instant migration, and then being blamed if anything
would go wrong.  When you will grow sufficient number of GIT experts
in your company, then you will raise the migration question again.


Good luck!

-- 
   Tomash Brechko

On 4/17/07, Martin Langhoff [off-list ref] wrote:

 - Old school SCMs allow you to branch, but are unable to keep track
of merges in any meaningful way. Every time you merge, history is
lost. GIT (and other DSCMs) have excellent branching _and_ merging
facilities.

This one was a bad argument too. Curiously, and I cannot explain why,
ability to branch is considered a weakness of GIT ("because it confuses
the integrators", them being old mean men). The Perforce is said to
be "vastly superior to everything" on these grounds: "it also has
branching support, but luckily(!) it is hard enough for simple
developers. Was not their (Perforce's) fault, they just included it
to keep up with the market". Almost exact wording (I had to translate it).

I'm new to Git, but completly crazy of it.

In my point of view, in corporate team, lot of people does not
want/need the power offered by Git.
So, my conclusion is the better model in a corporate is a centralyzed
repo with some users using Git as "frontend". Other people will simply
use the native tools for accessing the repo.

I didn't try Git with CVS repo but seems less usable in day to day
work than a SVN repo with git-svn FANTASTIC tool.

So the problem is simply now: how to convince people to migrate from
CVS to SVN. This will be really less difficult as CVS and SVN are
quite similar.

On 4/17/07, Tomash Brechko [off-list ref] wrote:

On Tue, Apr 17, 2007 at 10:02:18 +0100, Pietro Mascagni wrote:

quoted

So, in 15 seconds, how does one argue that GIT is vastly superior to
other version control software, especially CVS.

I think you are not talking about choosing SCM for a new project, as
it is even _hard to imagine_ that one would consider CVS nowadays :).
And if you are trying to convince people to do the migration from CVS
to GIT, then technical points alone won't probably help you.  GIT, and
actually most modern SCMs, are superior to CVS not simply because they
have some CVS's features improved, and some nice features added.
Modern SCMs implement completely different workflow model.  GIT's own
power in its rich toolset, but until people learn (or at least are
willing to learn) what the workflow is, and how it is supported by
these tools, there's little advantage in migration.  You can't really
explain why 'git commit; git push' into some central repository is
better than 'cvs commit', and pushing after every commit is what
people will be doing at first ;).  You should also realize that the
whole process is probably already built around CVS (CVS-specific
hooks, scripts that access CVS, say, for nightly testing, etc), that
would also have to be reimplemented.

You may consider another route: create a GIT mirror of CVS repository,
and update it, say, daily, with git-cvsimport.  Clone from this
mirror, and work with your own GIT tree, pushing back to CVS with
git-cvsexportcommit.  Yes, you will be dealing with problems that
wouldn't be there in the first place if everyone would use GIT, and
you will basically use CVS workflow, but still, this way is quite
manageable.  Then approach the most promising guy in the company, and
explain to him how you benefit from using GIT (gitk/qgit, git-bisect,
StGIT are among your friends here :)).  As the saying goes, "Better to
see once, then to hear about a hundred of times".  You are not
interested in instant migration, and then being blamed if anything
would go wrong.  When you will grow sufficient number of GIT experts
in your company, then you will raise the migration question again.


Good luck!

--
   Tomash Brechko
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/

On Tuesday 2007, April 17, Guilhem Bonnefille wrote:

I'm new to Git, but completly crazy of it.

In my point of view, in corporate team, lot of people does not
want/need the power offered by Git.
So, my conclusion is the better model in a corporate is a centralyzed
repo with some users using Git as "frontend". Other people will
simply use the native tools for accessing the repo.

Git has you covered there - it works better than other version control 
systems for that model too.  I do it all the time; the only difference 
is that with git it's not the tool doesn't force the choice on you.

If you want a central repo, just make one - designate one repository as 
central, put it in the .git/config file for each of the others and away 
you go.  Pretend it's centralised if you want; you and your colleagues 
need never know otherwise.

What's even better is that everything will also work faster, take less 
diskspace and be heavily backed up just by everyone doing their normal 
work.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Andy Parkins [off-list ref] wrote:

On Tuesday 2007, April 17, Guilhem Bonnefille wrote:

quoted

So, my conclusion is the better model in a corporate is a centralyzed
repo with some users using Git as "frontend". Other people will
simply use the native tools for accessing the repo.

Git has you covered there - it works better than other version control 
systems for that model too.  I do it all the time; the only difference 
is that with git it's not the tool doesn't force the choice on you.

Actually my day-job corporate repo is probably more secured in
Git than in PVCS Version Manager, even though every developer
has the entire history on their laptop.

Basically with PVCS users cannot save their work-in-progress very
well, so they copy files onto random network shares to make backups.
Our checked out tree is only about 120 MiB or so, but we have (and
I'm not kidding) over 3 GiB worth of various copies of the source
on an open network drive that anyone in the company can access, even
if they aren't authorized to view the source code of the product...

Now that developers have switched to Git, they have stopped making
those copies onto the network drive.  Why?  Simple, the network drive
copy takes longer (and more effort) than `git commit; git push`!
Users are all pushing to private branch spaces on the server, so
their work isn't merged until they really are ready for it, and
that server is backed up to secure tapes nightly, so all-in-all
its a much better situation.

-- 
Shawn.

Let me add some salt. At the moment, there are at least two immediate 
show-stoppers
for using git in many organizations:

a) Windows are unsupported
b) Learning curve is too steep. Unclear relationship git-vs-cogito makes 
it even worse.

Third is also very likely:

c) Lack of reasonable subproject support (plus detailed permission model).

 From tools similar to git, Mercurial performs significantly better (at 
least it works
on Win and is easy to learn, although some GUI would be needed in most cases
before it could be truly implemented).

PS I am in related pos, long years ago I introduced CVS to my org - 
replacing
CMS on VMS, RCS on Unix and manual copies on Win, now I am sensing 
possibilities, but...

PS2 I am not sure whether git aims to handle corporate cases, or even 
whether it should,
those remarks are addressed rather to those who consider using it in 
such situation, than
to those who wrote it.

Guilhem Bonnefille wrote:

I'm new to Git, but completly crazy of it.

In my point of view, in corporate team, lot of people does not
want/need the power offered by Git.
So, my conclusion is the better model in a corporate is a centralyzed
repo with some users using Git as "frontend". Other people will simply
use the native tools for accessing the repo.

I didn't try Git with CVS repo but seems less usable in day to day
work than a SVN repo with git-svn FANTASTIC tool.

So the problem is simply now: how to convince people to migrate from
CVS to SVN. This will be really less difficult as CVS and SVN are
quite similar.
  

Once git-svnserver is available, it should be possible to work the other
way, too - use git as the repository format and support Subversion users
through a subversion interface flavour.  Then you don't lose the merge
tracking and fast checkout performance for those who can use the native
protocol.

Sam.

Hi,

On Tue, 17 Apr 2007, Marcin Kasperski wrote:

a) Windows are unsupported

Wrong.

b) Learning curve is too steep. Unclear relationship git-vs-cogito makes it
even worse.

Not so wrong. But then, it is clear that git is git is git. If you find it 
too complicated, soon enough somebody says "use cogito instead" and you'll 
find out about that.

c) Lack of reasonable subproject support (plus detailed permission 
model).

It is just being introduced into Git.

And we're back to Alex' point: if you want to make a feature a first class 
citizen, you have to invest a little energy in it. But experience shows 
that it _is_ possible to get something completely new into Git quite fast.

BTW the most striking argument pro Git I can think of is showing people 
how fast you can find out things. Like who wrote it, or more importantly 
_where_ the code is for a certain feature. Searching through `git log -p` 
is really fast, and it becomes even faster when you use "-Sblub".

And I really blew my audience away when I imported some CVS tracked 
project into Git, and showed all the features on that repository, 
_without_ much work.

I mean, you can do with CVS, SVN, HG, etc. almost the same as with Git. 
But with Git, I find it faster and easier. BTW much of that does come from 
the scriptable nature of Git. It _is_ much easier to write a short and 
simple script than to work on a plugin.

Ciao,
Dscho

On 4/17/07, Andy Parkins [off-list ref] wrote:

On Tuesday 2007, April 17, Guilhem Bonnefille wrote:

quoted

I'm new to Git, but completly crazy of it.

In my point of view, in corporate team, lot of people does not
want/need the power offered by Git.
So, my conclusion is the better model in a corporate is a centralyzed
repo with some users using Git as "frontend". Other people will
simply use the native tools for accessing the repo.

Git has you covered there - it works better than other version control
systems for that model too.  I do it all the time; the only difference
is that with git it's not the tool doesn't force the choice on you.

If you want a central repo, just make one - designate one repository as
central, put it in the .git/config file for each of the others and away
you go.  Pretend it's centralised if you want; you and your colleagues
need never know otherwise.

In fact, the most important problem (in my case) is that there are
people that really don't want/need Git features. These people consider
that CVS/SVN are constraints and not usefull tools. They are not
interested in what a VCS can offer. I have success with CVS/SVN
because we now use Eclipse which offers an easy to use GUI for CVS/SVN
actions.
An other point is that CVS/SVN actions for our developers are
"trivial": update or commit, nothing more (even tags are made by
"power" users, so working with branches...). With Git, you have to
ALWAYS remember that you have a repo locally which is different than
the central repo. I think this point is quite confusing for people not
interested in the features offered by having a "private" repo.

This is why I think my corporate friends will brake if I try to
propose Git for everybody.

In my mind, git-svn or even git-svnserve, are THE tools to introduce
Git in teams not convinced by the power of DVCS. Or perhaps someone
will create a porcelain that offers the same simple interface of
CVS/SVN and will integrate it in all the fantastic IDE ;-)
-- 
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/

On Wednesday 2007 April 18 13:40, Guilhem Bonnefille wrote:

An other point is that CVS/SVN actions for our developers are
"trivial": update or commit, nothing more (even tags are made by

In my mind, git-svn or even git-svnserve, are THE tools to introduce
Git in teams not convinced by the power of DVCS. Or perhaps someone
will create a porcelain that offers the same simple interface of
CVS/SVN and will integrate it in all the fantastic IDE ;-)

It's already there.  The git porcelain can do almost anything.  If you were so 
inclined you could write a fake svn command that translated all those calls 
to git.

svn add = git add
svn update = git pull
svn commit = git commit -a && git push

I'm fairly convinced that the reason everyone thinks git is hard is because 
they're introduced to too much of it too quickly.

git /is/ easy.  It's more powerful, so there are more knobs, but if you don't 
want to use those knobs - don't.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

On Wed, 18 Apr 2007, Johannes Schindelin wrote:

On Tue, 17 Apr 2007, Marcin Kasperski wrote:

quoted

a) Windows are unsupported

Wrong.

It's a bit more work to set up though, and it has a lot less mindshare, 
and testing, obviously.

So yes, windows is a step-child. I'd love for it to not be one, and we'll 
get there, but it's clearly not as supported as the unix side. We still 
use a fair number of shell scripts (which in turn use unix commands and 
pipelines).

We'll get away from it. I think GSoC will help here.

quoted

b) Learning curve is too steep. Unclear relationship git-vs-cogito makes it
even worse.

Not so wrong. But then, it is clear that git is git is git. If you find it 
too complicated, soon enough somebody says "use cogito instead" and you'll 
find out about that.

Actually, at this stage, I really think cogito just *complicates* git 
usage. It hasn't been well-supported lately, and asking for help with 
cogito means that a lot of people can't help you. And you still end up 
using git commands for anything fancier.

So I don't think it's even true that new people should be pointed at cg 
any more.

What _is_ true is that git is simply different from CVS. I don't think 
it's necessarily harder to understand or use (in fact, I would argue that 
git is a lot _easier_ to understand), but it is *different*, and it has a 
ton more capabilities.

But compare setting up a git repository with setting up a CVS repository.
With git, it's literally "git init", and you're done. No need to worry 
about CVSROOT issues etc. Everything is self-contained. CVS is *hard* to 
get into, by comparison.

But being different means that *if* you already know CVS, you actually 
have a lot of unlearning of idiotic and bad habits, _and_ you need to 
learn that things that were so hard and scary under CVS that you either 
never learnt them, or quickly learnt to avoid ("branches" and "merging") 
are just so _easy_ under git, that they are discussed in the very first 
chapters of "getting started".

I can pretty much guarantee that 95% of all CVS users have never done a 
branch or a merge, even if they have used it for *years*. And yet, in git, 
we kind of take both of those for granted, and make them visible pretty 
much from day one. 

Git is just *easier*. But it is also different, and people are used to 
things being so hard that you'd never use them.

In a CVS world, you never even *need* to learn about branches and merging, 
because no normal user is ever actually expected to use either. In 
contrast, in the git world, pretty much every project uses multiple 
branches, and you are introduced to them at a minimum as the "origin" 
branches even for projects that just have one. So you're getting all these 
concepts that were so hard in CVS that you never ever even learnt to do 
them!

So people coming from CVS/SVN have a double shock: they are supposed to 
learn things that they "know" are hard (because CVS/SVN made them so damn 
hard - don't tell me that SVN branching is easy, because it is *not* easy. 
It may be cheaper to create a branch, but it has _all_ the same idiocies 
that CVS has once it's created). And on top of that, they have to re-learn 
something new.

So I really don't think cogito is the answer any more. The answer simply 
is: you have to learn that branches are *simple*. That's a big hurdle for 
some people. It's not the learning part that is hard, it's the 
*unlearning*. CVS/SVN has taught people that some things are complicated, 
and git uses those "complicated" things every day.

People who come from a CVS background would be *shocked* to learn that I 
do multiple merges a day. In fact, in the two years we've used git, we've 
had 3300 merges - and that's just counting the *nontrivial* ones that 
didn't just fast-forward. That's roughly an *average* of 4.5 merges a day. 
EVERY DAY. For two years.

In the CVS/SVN kind of mindset, a merge is something you do once a month, 
and you gird your loins for it. And it's usually just an expert, and only 
used for complex projects. A normal user would _never_ do a merge!

			Linus

On Wed, 18 Apr 2007, Linus Torvalds wrote:

Actually, at this stage, I really think cogito just *complicates* git 
usage. It hasn't been well-supported lately, and asking for help with 
cogito means that a lot of people can't help you. And you still end up 
using git commands for anything fancier.

Maybe someone should nuke the prominent mention of Cogito at the top of 
http://www.kernel.org/git/ then, and replace it with the appropriate Git 
equivalent.


Nicolas

On Wednesday, April 18, 2007 at 09:07:55 (-0700) Linus Torvalds writes:

...
Actually, at this stage, I really think cogito just *complicates* git 
usage. ...

As a relative newbie to git, I agree.  At our company, we did not even
seriously consider using cogito.  Just easier to jump right in to the
frosty waters.

What _is_ true is that git is simply different from CVS. I don't think 
it's necessarily harder to understand or use (in fact, I would argue that 
git is a lot _easier_ to understand), but it is *different*, and it has a 
ton more capabilities.

Well, differences can lead to difficulties.

Here are a few of the differential difficulties we have faced:

1) There seems to be an innate desire on our part to just "update this
branch from that one on that repository".  We have been caught several
times pulling onto the wrong branch, pushing onto the wrong one,
because we assumed the behavior of push/pull was "update this branch,
the one I am on right now, and ONLY this branch", but what we got was
a cross-branch merge.  Coming from a CVS background, and there not
having "undo" very easy, this caused severe stress.  Easy enough to
undo, once we understood, but does not obviate the stress.

2) Addressing of branches.  When to use bare 'git pull/push', when to
use 'git pull/push branch' when to use 'git pull/push branch:branch',
have been continually confusing to us.

3) Funkiness of non-bare repos ---- we really got stung trying to push
into one.  Seemed like it took us days to figure out what was going
on.

4) Near disaster using git with ssh to push to our company repo.  In
our company, we have a very loosy-goosy IT group.  We started using
git with ssh and had serious permissions problems.  If we had used the
git protocol from the start, that would have avoided this mess, but
support for that came too late.

Git has gotten much better than when we started with it just at the
beginning of this year.  Remote support, branch tracking, lots of
stuff has gotten much, much better.

I could go on and on about the good things, but it is important to
caution --- not frighten --- newbies with tales from others who have
been stung.


Bill

Andy Parkins wrote:

svn update = git pull
  

That's not quite equivalent, and it's one of the biggest annoyances svn 
users seem to have when starting up with git in my observation (having 
gone through it myself and watched a few other people at my company do 
so.) svn update will merge upstream changes into your locally edited but 
not yet committed files. git pull will just complain if you have 
uncommitted local edits to files that changed upstream.

To avoid that problem, my workflow often looks like

git commit -a -m "dummy revision"
git fetch
git rebase origin/master
git reset --soft HEAD^

which IMO is something the tool should be doing for me. Cogito's 
cg-update would do this for me, but Cogito hasn't kept up with recent 
git changes so aside from cg-admin-rewritehist I never use it. Please 
tell me if the above is doable in fewer commands, by the way.

-Steve

On 4/18/07, Linus Torvalds [off-list ref] wrote:

What _is_ true is that git is simply different from CVS. I don't think
it's necessarily harder to understand or use (in fact, I would argue that
git is a lot _easier_ to understand), but it is *different*, and it has a
ton more capabilities.

Yes, but I think that, as Git has ton more capabilities, user has to
understand more things than with CVS.

I don't know lot of corporate teams, but here, our developers are
REALLY not motivated by VCS. It's only a way to share work. And I'm
not talking about concurrent modification: lot of people in my office
really think that the better model is the locked one.
These people won't be the guy who set up the repo. These people only
expect a system to:
- retrieve and merge the job done by other people
- archive their job for other people.
Nothing more. No interest for topic branches (they are simple minded
;-)), no interest for data integrity (it's "not their job"),
interested in problem with connected system ("hey, CVS server is down,
would you like a coffee while waiting IT detects that ?")...

So for such people, I really think raw Git is much more complicated
than CVS/SVN.

-- 
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/

On Wed, 18 Apr 2007, Guilhem Bonnefille wrote:

Yes, but I think that, as Git has ton more capabilities, user has to
understand more things than with CVS.

I do agree.

The whole "branch" thing is something you can ignore in CVS, but it's 
simply very hard to ignore in git, because even *if* you just follow 
another repository, git kind of forces you to be aware of the difference 
between "local branch" and "remote tracking branch".

I think that's fairly fundamental to being distributed, though. 

I don't know lot of corporate teams, but here, our developers are
REALLY not motivated by VCS. It's only a way to share work. And I'm
not talking about concurrent modification: lot of people in my office
really think that the better model is the locked one.

Sure. At one level they may even be right. It's just that the locked model 
obviously doesn't work past a certain scenario. But explaining that to 
somebody who doesn't even think outside his own scenario is pointless.

So no question: git has a level of abstraction and perhaps requires a 
higher-level view than RCS and CVS do. And I can well imagine that it is 
seen as more "difficult" because of that.

I just haev to say that I worked with CVS at a commercial company for 
seven years, and I *did* do things like branches and merges etc, and 
despite workign with it at that level (not that I was the expert by any 
means: we had a person who came in with the main job literally being the 
tools around CVS to make branching more convenient etc), I seriously feel 
that CVS was a *lot* harder to get into than it is to get into git.

So for such people, I really think raw Git is much more complicated
than CVS/SVN.

I do wonder what we could do about that. I think you can use git in the 
"SVN tracker only" model, and I really thought it was pretty damn simple, 
but ...

		Linus

On Tue, Apr 17, 2007 at 02:45:20PM +0400, Tomash Brechko wrote:

I think you are not talking about choosing SCM for a new project, as
it is even _hard to imagine_ that one would consider CVS nowadays :).

Don't think that.  Some people used to CVS still say "it does the job,
and I know the tool", and look suspciously on those youngsters trying
push anything they did not even heard of (I'd push for git today, but
18 months ago all I had to push for was svn).  And only after months
of "here svn/git would have done better", and regularly showing off
gitk (git-cvsimport is not a panacea, but it helps), can they be ready
to hear.

But by then more people have been made to meet CVS because of a new
project using it, and it will take more time that we would like to see
it retire from the scene...

On Wed, Apr 18, 2007 at 02:26:17PM +0100, Andy Parkins wrote:

On Wednesday 2007 April 18 13:40, Guilhem Bonnefille wrote:

quoted

An other point is that CVS/SVN actions for our developers are
"trivial": update or commit, nothing more (even tags are made by

quoted

In my mind, git-svn or even git-svnserve, are THE tools to introduce
Git in teams not convinced by the power of DVCS. Or perhaps someone
will create a porcelain that offers the same simple interface of
CVS/SVN and will integrate it in all the fantastic IDE ;-)

It's already there.  The git porcelain can do almost anything.  If you were so 
inclined you could write a fake svn command that translated all those calls 
to git.

svn add = git add
svn update = git pull
svn commit = git commit -a && git push

It's even possible to write those as git aliases, so you can have "git
update" and "git ci" behave as cvs/svn users would expect.

Suppose I were dealing with career software developers, backed by real
money, who also happened to be intelligent, thoughtful people, and I
wanted to make the case for git vs. CVS/SVN.  I'd start by handing
them copies of the O'Reilly Perforce book and suggesting that they
read it cover to cover.  Focus on the chapters on how well organized
development and release branches, and good tracking of feature/fix
propagation among them, can help you cope with the vagaries of
real-life software development.

Then I'd explain the relative merits of Perforce and git -- on one
hand, availability and quality of documentation, training, tech
support, and Windows versions; on the other hand, a genuinely
distributed design, which means that you don't need psychic powers to
arrive at a sane branch structure.  Specifically, git's design makes
private branches ultra-cheap for the developers that use them and
zero-impact on the release infrastructure, and the integrity of
_content_ and _history_ doesn't rely on any resemblance between my
branch layout and yours.  Speed, scalability, zero license cost, and
the hypothetical ability to hack on it yourself are nice too, but
they're basically fringe issues unless you're so big that you can't
just throw money at the problem -- in which case they're still fringe
issues because you're the enterprise-customer tail that wags the
vendor dog.  (If you're big _and_ cash-poor, or if you're stuck on a
VC system so badly designed that no amount of money thrown at the
problem will help, you have a different problem.)

If you do this right, it should be clear that CVS is in the dust on
all fronts and SVN doesn't (AFAICT) have any advantage over Perforce
that git doesn't have more of.  You might also mention that git was
designed by Linus to systematically not suck, and has been
successfully handed over to a strong maintenance/enhancement team that
works in public view.  And Linus is still here policing to keep
suckage from creeping in.  ;-)  The hypothetical smart developers will
then agree to go with either Perforce or git, depending on which the
people who have to do the hard work -- release managers and the IT
Morlocks -- are most comfortable with.

If you take this route, be prepared to wind up with Perforce.  It's
got its weaknesses, and I prefer git myself, but you could certainly
do a lot worse.  I'm not as anti-SVN as Linus, but there aren't many
workflows for which I would recommend it over Perforce.  Personally, I
wouldn't voluntarily introduce any other version control system into
the discussion, because the others that I've used in the course of one
day job or another suck massively by comparison, and the ones I
haven't used (or have only toyed with) don't appear to have any
compelling advantage over git.  (Having _marginally_ better
documentation isn't much to brag about).

Until someone writes a good book on git and sets up shop as a
commercial support organization, presenting Perforce vs. git as a
classic buy/build decision is probably the best you can do.  (You
don't have to "build" git, of course, but you'd have to build your own
in-house training and tech support capability.)  I say this as someone
who routinely sits in the "release manager" chair, uses git by choice,
and is currently suffering the pain and agony of migrating a perfectly
good git-based integration process to Perforce, simply because it
appears to be the right thing for this developer organization.
(Doubtless this colors my opinion du jour.)

Cheers,
- Michael

On Wed, 18 Apr 2007, Linus Torvalds wrote:

On Wed, 18 Apr 2007, Guilhem Bonnefille wrote:

quoted

Yes, but I think that, as Git has ton more capabilities, user has to
understand more things than with CVS.

I do agree.

The whole "branch" thing is something you can ignore in CVS, but it's 
simply very hard to ignore in git, because even *if* you just follow 
another repository, git kind of forces you to be aware of the difference 
between "local branch" and "remote tracking branch".

I think that's fairly fundamental to being distributed, though. 

I actually disagree here. CVS users are obviously familiar with "how far 
have I updated from the server". With CVS the "local branch" and "remote 
tracking branch" are qualitatively different, and with git they're 
qualitatively the same, but the user doesn't have to care. Particularly 
with the new refs layout, it's pretty easy to ignore, as long as the 
upstream repository isn't using branches for anything this particular user 
cares about.

You can just tell people, "Before you merge upstream changes, you have to 
commit, so that if the merge gets screwed up you don't lose your work." 
And they say, "Oh. That's useful." And they don't need to know the 
technical reasons this is both possible and necessary.

(Of course, branches are really helpful once you have a need for them, but 
there's no reason to learn about them before that point.)

	-Daniel
*This .sig left intentionally blank*

Steven Grimm wrote:

Andy Parkins wrote:

quoted

svn update = git pull
  

That's not quite equivalent, and it's one of the biggest annoyances svn 
users seem to have when starting up with git in my observation (having 
gone through it myself and watched a few other people at my company do 
so.) svn update will merge upstream changes into your locally edited but 
not yet committed files. git pull will just complain if you have 
uncommitted local edits to files that changed upstream.

In my opinion the update-then-commit workflow CVS and SVN forces on users
is one of the more annoying features, forcing the user to resolve conflicts
if he/she wants to be up-to-date.

The update-then-commit assumes that you merge on update local modifications
with current server version, assuming that ancestor is current local
committed version. This makes off-line committing impossible, and makes
rare updates (server version advanced by more than one commit) unnecessary
hard.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Jakub Narebski wrote:

In my opinion the update-then-commit workflow CVS and SVN forces on users
is one of the more annoying features, forcing the user to resolve conflicts
if he/she wants to be up-to-date.
  

I'm not eager to jump to svn's defense -- there's a reason I'm using git 
and trying to get my coworkers to do the same -- but how does git allow 
you to stay up to date without resolving conflicts? Granted that git is 
smarter about resolving certain kinds of conflicts automatically, but 
fundamentally if the latest revision you've pulled down (from any kind 
of version control system) makes a change that conflicts with a local 
change (whether or not you've committed it locally first) you're going 
to have to resolve it by hand, yes?

Also, last I checked, git wouldn't let me push into a branch that had 
revisions I hadn't yet pulled down. Isn't that just another way of 
enforcing an update-then-commit workflow? If anything, svn wins in that 
area -- it allows me to commit without updating as long as my change 
doesn't touch any files that have changed upstream.

One can argue about whether allowing partial commits like that is a good 
idea, but it's just not true that svn forces you to always update before 
you commit, and if you're pushing into a branch that other people are 
also updating, the ability to commit files that didn't change upstream 
means it is actually *less* insistent on update-then-commit than git is 
(if you take "commit" to mean "commit-and-push" on the git side as was 
suggested in the message I replied to originally.)

Unless, of course, I'm misinterpreting you here.

The update-then-commit assumes that you merge on update local modifications
with current server version, assuming that ancestor is current local
committed version. This makes off-line committing impossible, and makes
rare updates (server version advanced by more than one commit) unnecessary
hard.

That last point is completely counter to my experience. At my company 
(where the svn repository is still the official code base) the 
repository is constantly changing. I'll sometimes let hundreds or even 
thousands of revisions go by between updates of my svn client. When I'm 
at a good point to do integration testing and I'm using an svn client 
instead of a git-svn one, I type "svn up", do roughly the same manual 
conflict resolution I'd do after a "git pull" that brought down a 
similar number of new revisions -- often none at all if I'm the only one 
working on a particular corner of the code base -- and I'm good to go. 
What's unnecessarily hard about that? How would it be any better in git?

Local commit capability is absolutely a huge win in git, though, and is 
one of the main features I use to sell people on it internally. No 
argument there. I just don't like being *forced* to do a local commit 
when I have no reason to do so other than to satisfy the version control 
tool. I end up either cluttering my history with dummy revisions or 
having to type extra commands to get rid of them.

And in particular -- this being the original topic of the thread -- when 
an svn user sees me doing that, they do not immediately think of the 
fact that merging between immutable revisions may have some benefits. 
They see me typing four commands (commit, fetch, rebase, reset) to do 
the same thing they can do in one command with svn, and conclude that 
git is harder to use. That some of them choose to use it anyway is a 
testament to how great git is in other areas.

-Steve

Steven Grimm wrote:

Jakub Narebski wrote:

quoted

In my opinion the update-then-commit workflow CVS and SVN forces on users
is one of the more annoying features, forcing the user to resolve conflicts
if he/she wants to be up-to-date.
  

I'm not eager to jump to svn's defense -- there's a reason I'm using git 
and trying to get my coworkers to do the same -- but how does git allow 
you to stay up to date without resolving conflicts? Granted that git is 
smarter about resolving certain kinds of conflicts automatically, but 
fundamentally if the latest revision you've pulled down (from any kind 
of version control system) makes a change that conflicts with a local 
change (whether or not you've committed it locally first) you're going 
to have to resolve it by hand, yes?

The answer is that in git you can separate _having_ most current version
from the server (git fetch) and _merging_ your work with current version
from the server (git pull).

Also, last I checked, git wouldn't let me push into a branch that had 
revisions I hadn't yet pulled down. Isn't that just another way of 
enforcing an update-then-commit workflow? If anything, svn wins in that 
area -- it allows me to commit without updating as long as my change 
doesn't touch any files that have changed upstream.

One can argue about whether allowing partial commits like that is a good 
idea, but it's just not true that svn forces you to always update before 
you commit, and if you're pushing into a branch that other people are 
also updating, the ability to commit files that didn't change upstream 
means it is actually *less* insistent on update-then-commit than git is 
(if you take "commit" to mean "commit-and-push" on the git side as was 
suggested in the message I replied to originally.)

Unless, of course, I'm misinterpreting you here.

I just think the commit _then_ merge (or commit-then-update) workflow is
much, much better than update-then-commit one.

-- 
Jakub Narebski
Poland

Hi,

On Wed, 18 Apr 2007, Guilhem Bonnefille wrote:

I don't know lot of corporate teams, but here, our developers are
REALLY not motivated by VCS. It's only a way to share work. And I'm
not talking about concurrent modification: lot of people in my office
really think that the better model is the locked one.
These people won't be the guy who set up the repo. These people only
expect a system to:
- retrieve and merge the job done by other people
- archive their job for other people.

How is that not concurrent? If it really was not, there would be no need 
to merge.

And let's face it: merging with CVS is cumbersome. Why? Exactly because 
CVS pretends (and tries to make you, too!) that there is just one branch.

Guess what. There are two branches. And they are conflicting. So, once you 
really looked at the problem you really should agree that branches are the 
natural mental model to deal with conflicts.

So for such people, I really think raw Git is much more complicated than 
CVS/SVN.

I imagine that somebody dedicated enough -- i.e. not me -- could set up 
some standard aliases which do the CVS/SVN equivalent; we'd probably need 
to support something like

	[alias]
		ci = commit -a && push origin

which should not be all that hard.

Ciao,
Dscho

Hi,

On Thu, 19 Apr 2007, Jakub Narebski wrote:

Steven Grimm wrote:

quoted

One can argue about whether allowing partial commits like that is a 
good idea, but it's just not true that svn forces you to always update 
before you commit, and if you're pushing into a branch that other 
people are also updating, the ability to commit files that didn't 
change upstream means it is actually *less* insistent on 
update-then-commit than git is (if you take "commit" to mean 
"commit-and-push" on the git side as was suggested in the message I 
replied to originally.)

Unless, of course, I'm misinterpreting you here.

I just think the commit _then_ merge (or commit-then-update) workflow is 
much, much better than update-then-commit one.

Let me pick up the ball here. Once you did your share of conflicting 
merges, you _will_ realize how much better it is to merge when you are at 
a relatively stable state, i.e. you can test things (if only to make sure 
that the merge did not introduce strange side effects). And guess what, at 
such a stage I would commit anyway.

It is so much easier to resolve conflicts if you can look at both sides, 
and can actually go to both sides to test things out, or even just 
generate the diff to one side. This is just not possible with a dirty 
merge. Exactly because you knowingly lost the current state, you cannot do 
diffs with it.

Needless to say (but I do it nevertheless, since I am in a chatty mood), I 
_never_ can be seen doing the 4-command equivalent of `svn up`. I only 
pull when I have a clean state. (Note: this also leads to a more 
structured way of working, which does prevent errors.)

Ciao,
Dscho

On Thu, 19 Apr 2007, Johannes Schindelin wrote:

Hi,

On Thu, 19 Apr 2007, Jakub Narebski wrote:

quoted

Steven Grimm wrote:

quoted

One can argue about whether allowing partial commits like that is a
good idea, but it's just not true that svn forces you to always update
before you commit, and if you're pushing into a branch that other
people are also updating, the ability to commit files that didn't
change upstream means it is actually *less* insistent on
update-then-commit than git is (if you take "commit" to mean
"commit-and-push" on the git side as was suggested in the message I
replied to originally.)

Unless, of course, I'm misinterpreting you here.

I just think the commit _then_ merge (or commit-then-update) workflow is
much, much better than update-then-commit one.

Let me pick up the ball here. Once you did your share of conflicting
merges, you _will_ realize how much better it is to merge when you are at
a relatively stable state, i.e. you can test things (if only to make sure
that the merge did not introduce strange side effects). And guess what, at
such a stage I would commit anyway.

It is so much easier to resolve conflicts if you can look at both sides,
and can actually go to both sides to test things out, or even just
generate the diff to one side. This is just not possible with a dirty
merge. Exactly because you knowingly lost the current state, you cannot do
diffs with it.

Not only that, but there is then a _record_ that Joe Developer had to 
merge your work into his (or vice versa) ...

-- 
Julian

  ---
"MacDonald has the gift on compressing the largest amount of words into
the smallest amount of thoughts."
 		-- Winston Churchill

Actually, at this stage, I really think cogito just *complicates* git 
usage. 

Agreed.

So I don't think it's even true that new people should be pointed at cg 
any more.

Google points to git.or.cz ;-)

But compare setting up a git repository with setting up a CVS repository.
With git, it's literally "git init", and you're done. No need to worry 
about CVSROOT issues etc. Everything is self-contained. CVS is *hard* to 
get into, by comparison.

I am in no way advocating CVS, but to be fair in such comparison, one
should mention also effort of *publishing* git repository and making it
available to remote clients. Initialized and configured CVS (or
subversion, or perforce, or ...) repo is something ready to be used by
remote clients.

Getting correct ssh keys in correct places is - for instance -
noticeable problem for many people. Especially if they use clients
(like plink) which natively use alternative key save format. Etc...

So people coming from CVS/SVN have a double shock: they are supposed to 
learn things that they "know" are hard (because CVS/SVN made them so damn 
hard - don't tell me that SVN branching is easy, because it is *not* easy. 

The way SVN implemented branching (and tagging!) simply killed the idea
of using this tool seriously. IMO. Let's leave it.

I agree that git introduces plenty of excellent concepts. What it needs
is better docs (also, clearly known **SINGLE** master doc, just sth like
subversion book), cleaned command line interface (I feel that there are
just too many lowlevel commands visible for beginning user, maybe at
least one could split them into git-* for mere mortals and gitadm-* for
repository hackers), portability, and finally GUI.

				Best regards

On 4/19/07, Johannes Schindelin [off-list ref] wrote:

to rebooting their machines several times a day, just to keep them
running).

That's not true! We only need to reboot them once a week to defragment
VFAT and NTFS volumes and cleanup the registry. Well, sometime the
antivirus software hangs up our machines and there of course always
are some malicious programs around. But we do not reboot them several
times a day. On a good day, at leas#$^%$#%^$#!!!!

On 4/19/07, Johannes Schindelin wrote:

Given the fact that Hannes is working not only _on_, but _with_ it, tells
me that it works well enough for any Windows user (remember, they are used
to rebooting their machines several times a day, just to keep them
running).

untrue, but very funny :)

My experience (offtopic, I know):

In one day, I actually reboot more often my qemu instances with my linux
test kernels than the current XP host crashes in a year.

-- 
Christian

Hi,

On Thu, 19 Apr 2007, Marcin Kasperski wrote:

[BTW: who said the following? You skipped that information.]

quoted

So I don't think it's even true that new people should be pointed at cg 
any more.

Google points to git.or.cz ;-)

How does Google point to something? You mean the last time you ran the 
search, the top find _for you_ was git.or.cz?

quoted

But compare setting up a git repository with setting up a CVS 
repository. With git, it's literally "git init", and you're done. No 
need to worry about CVSROOT issues etc. Everything is self-contained. 
CVS is *hard* to get into, by comparison.

I am in no way advocating CVS, but to be fair in such comparison, one
should mention also effort of *publishing* git repository and making it
available to remote clients. Initialized and configured CVS (or
subversion, or perforce, or ...) repo is something ready to be used by
remote clients.

No. Not at all. It took me _one day_ to publish my first CVS repository. 
It took me exactly 10 seconds to do that with Git.

If you are referring to readily-usable CVS services like sourceforge's, 
you are comparing apples with sentences.

Getting correct ssh keys in correct places is - for instance -
noticeable problem for many people. Especially if they use clients
(like plink) which natively use alternative key save format. Etc...

I fail to see how you need ssh keys in order to publish a Git repository.

I agree that git introduces plenty of excellent concepts. What it needs
is better docs (also, clearly known **SINGLE** master doc, just sth like
subversion book),

Does that mean you are volunteering?

cleaned command line interface (I feel that there are
just too many lowlevel commands visible for beginning user, maybe at
least one could split them into git-* for mere mortals and gitadm-* for
repository hackers),

Does that mean we can expect patches from you?

portability,

Which platform are you having in mind?

and finally GUI.

Does that mean you will provide patches? A good starting point is git-gui, 
IMHO.

Ciao,
Dscho

Hi,

On Thu, 19 Apr 2007, Christian MICHON wrote:

On 4/19/07, Johannes Schindelin wrote:

quoted

Given the fact that Hannes is working not only _on_, but _with_ it, 
tells me that it works well enough for any Windows user (remember, 
they are used to rebooting their machines several times a day, just to 
keep them running).

untrue, but very funny :)

Oh, but it is true! That's personal experience. My typical answer: "You 
needed to reboot? What is a 'reboot'?"

My experience (offtopic, I know):

In one day, I actually reboot more often my qemu instances with my linux 
test kernels than the current XP host crashes in a year.

With a linux test kernel. Yeah, right. So, you compare an experimental 
test kernel -- which I gather you stress test? -- with an XP kernel where 
you probably do not even check mails while running QEmu, for fear that it 
crashes? *lol*!

Ciao,
Dscho

quoted

Google points to git.or.cz ;-)

How does Google point to something? You mean the last time you ran the 
search, the top find _for you_ was git.or.cz?

Exactly. Searches for git documentation, git tutorial, git version
control pointed there.

quoted

I agree that git introduces plenty of excellent concepts. What it needs
is better docs (also, clearly known **SINGLE** master doc, just sth like
subversion book),

Does that mean you are volunteering?

No, as I do not have necessary knowledge. But I can volunteer to review
one.

quoted

cleaned command line interface (I feel that there are
just too many lowlevel commands visible for beginning user, maybe at
least one could split them into git-* for mere mortals and gitadm-* for
repository hackers),

Does that mean we can expect patches from you?

Not sure what is your point Johannes, but if you wanted to say that if
somebody is not actively developing git, he should not make any comments
regarding this, you could try doing this in a more straightforward
manner.

On Thu, Apr 19, 2007 at 02:33:31PM +0200, Johannes Schindelin wrote:

quoted

quoted

So I don't think it's even true that new people should be pointed at cg 
any more.

Google points to git.or.cz ;-)

How does Google point to something? You mean the last time you ran the 
search, the top find _for you_ was git.or.cz?

I just checked today.  If you go to http://www.google.com, and enter
"git", and then click on "I'm feeling lucky", you will go to
http://git.or.cz.  One of the first links you will then see,
misleading titled in a box labelled, "Git crash courses", are "Git for
CVS users", and "Git for SVN users", and both of these getting started
documents reference cg commands and only cg commands.

So when projects downgrade git as having confusing documentation, and
tutorials that contradict each other about how to do things, this is
very likely one of the reasons why.

							- Ted

On Wed, Apr 18, 2007 at 06:07:55PM CEST, Linus Torvalds wrote:

Actually, at this stage, I really think cogito just *complicates* git 
usage. It hasn't been well-supported lately, and asking for help with 
cogito means that a lot of people can't help you. And you still end up 
using git commands for anything fancier.

And at this stage, I actually rather agree.

I've been torn apart about this for few weeks now, struggling to get
some time (and strong motivation) to dive through the dusty cogito
patchqueues etc., and wondering what to actually *do* about Cogito.
I have been actually inclined to, hmm, "phase out" Cogito for some time
already, but then always some very nice mail from a Cogito user comes
and throws me in doubts. But this thread pushed me over the edge.  ;-)

I agree that by now, the situation is too confusing and while I'm not
happy with everything in Git, I believe that by now the best way is to
just fix Git. Therefore, I'm announcing that I don't plan to add any (at
least any significant) new features to Cogito. Sorry to all the Cogito
users, it is a hard decision for me, but by now I believe that it is
much more effective to just focus on Git.

If anyone else wants to take over Cogito maintainership, you're most
welcome: let me know, please! The "patch queue" means just filtering
=git mailbox, but I have some WIP code to add the .git/config "remotes"
support to Cogito, if you are interested.

Until someone else steps out to maintain Cogito, I'm not going to
abandon Cogito absolutely. I still plan to dive through the patch queue
as soon as possible and then continue integrating bugfixes and/or
smaller-scale changes necessary for newer Git versions. I'll maybe also
write a trivial more-or-less 1:1 cg->git porcelain wrapper for those
who trained their fingers to 'cg' instead of 'git'; but maybe it's best
just to retrain. ;-)


About git homepage:

The very least I wanted to do at any rate with git.or.cz ASAP is to
switch the crash courses to git-oriented ones too. I think git more or
less got to a reasonable point when this is a sane idea. Do you have any
tips on exactly what zero-level introductory material I should put there
instead of the Cogito crash courses, or should we write new ones
(perhaps based on the current ones)? I probably won't have much time to
write a lot of stuff, but I'll gladly use whatever reasonable anyone
suggests/writes, and I have no qualms to just give well-known people
push access to the homepage repository.

Live and prosper,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

On 4/19/07, Johannes Schindelin [off-list ref] wrote:

Oh, but it is true! That's personal experience. My typical answer: "You
needed to reboot? What is a 'reboot'?"

I agree it was the case in the past.

quoted

My experience (offtopic, I know):

In one day, I actually reboot more often my qemu instances with my linux
test kernels than the current XP host crashes in a year.

With a linux test kernel. Yeah, right. So, you compare an experimental
test kernel -- which I gather you stress test? -- with an XP kernel where
you probably do not even check mails while running QEmu, for fear that it
crashes? *lol*!

let me rephrase:
- I run some test on about a kernel I regenerate about > 20 times
a day [I'm making a distro right now...]
- my host XP crashes less than 20 times in a year

I was not comparing both kernels: I would not be spending time on
building a linux distro if I was not convinced linux is far superior :)

-- 
Christian

Hi,

On Thu, 19 Apr 2007, Marcin Kasperski wrote:

quoted

quoted

cleaned command line interface (I feel that there are just too many 
lowlevel commands visible for beginning user, maybe at least one 
could split them into git-* for mere mortals and gitadm-* for 
repository hackers),

Does that mean we can expect patches from you?

Not sure what is your point Johannes, but if you wanted to say that if 
somebody is not actively developing git, he should not make any comments 
regarding this, you could try doing this in a more straightforward 
manner.

No. I said that tongue-in-cheek.

But my point was: Since the current developers evidently are comfortable 
with the current set of command line options, and the consistency thereof, 
it needs more than some hand waving comments about what you want changed, 
and how.

To state it clearly: if you have any concrete wishes as to the 
clarification of Git, and to make it easier for beginners (at the same 
time not making it harder on others), I will be very glad to know them. 
And I think that the list will welcome these equally eagerly.

Ciao,
Dscho

On Thu, Apr 19, 2007 at 02:42:39PM +0200, Marcin Kasperski wrote:

quoted

quoted

I agree that git introduces plenty of excellent concepts. What it needs
is better docs (also, clearly known **SINGLE** master doc, just sth like
subversion book),

Does that mean you are volunteering?

No, as I do not have necessary knowledge. But I can volunteer to review
one.

That would be great--see Documentation/user-manual.txt.  (Or
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html.)

Patches welcomed, but so is general review.  It's not my highest
priority, unfortunately, so I may be a little slow to address comments,
but I'll get to them eventually.

I don't expect it to ever be a *single* master doc--I still want to
leave a lot of the details to the man pages, for example, and I expect
there'll always be a need for some shortcut howto's and tutorials.   I
suppose we could include much of that into appendices some day if it
helped findability.

--b.

On Thu, 19 Apr 2007, Johannes Schindelin wrote:

quoted

Actually, at this stage, I really think cogito just *complicates* git 
usage.

Hmm. However, I have to say that cogito serves/d another purpose quite 
well: Look at what came from cogito into git. Loads of useful 
enhancements. So, I really have to point to "at this stage", because that 
sure was not true 18 months ago.

Absolutely. I think there are still some pieces of cogito that we might 
want to migrate into git too, although they're fairly esoteric (ie the 
whole history rewriting thing). And I think we still have some places 
where git is influenced by cogito doing things differently (ie the whole 
branch tracking stuff) where we may want to change our default behaviour 
or extend on things.

So yes, "at this stage" was the operative word.

I guess that we should not say that Git is complicated. People tend to 
believe that, but it is simply not true. The basic steps are easy. Really 
easy.

But Git does not keep you there.

I agree. And to some degree I suspect that the documentation pushes some 
of the advanced things a bit *too* eagerly.

Of course, with many of the projects that use git being very 
branch-oriented, I guess some of that is inevitable. You can't *not* 
mention branches, simply because even people who only track other peoples 
work do end up often needing to know about it, or at least hearing about 
them..

		Linus

quoted

I guess that we should not say that Git is complicated. People tend to 
believe that, but it is simply not true. (...)

I agree. And to some degree I suspect that the documentation pushes some 
of the advanced things a bit *too* eagerly. (...)

As I am among those, who think that git *is* complicated, I decided to 
sit down, and find out why
exactly I think so. Here are the top words/options/concepts, which I 
faced almost immediately while
trying GIT, and which I find confusing:

rebase
index
revtree
reset
ref / refs
rev-list
rev-parse

At the same time, concepts like add, rm, commit, push, pull, merge are 
natural and easily understandable.

Johannes Schindelin wrote:

Let me pick up the ball here. Once you did your share of conflicting 
merges, you _will_ realize how much better it is to merge when you are at 
a relatively stable state, i.e. you can test things (if only to make sure 
that the merge did not introduce strange side effects). And guess what, at 
such a stage I would commit anyway.
  

That's a great workflow if you're working on relatively discrete, 
standalone changes. A lot of the time, when I'm working on an isolated 
change, I do just that, and I merge when I'm stable just like you 
describe. That's probably the vastly most common mode of operation for 
distributed open-source projects, which obviously were git's initial 
target audience.

However, it is frequently NOT the mode of operation for development at a 
company where two or more people are working on implementing the same 
new feature in a highly collaborative way, often sitting across the room 
from one another. In that situation, it's frequently the case that, for 
example, I'm coding and discover I need some new utility method that Joe 
can easily factor out of the code he just checked in. So he does his 
quick refactoring, commits that change, and I pull it into my sandbox 
where I am *not* yet at a stable stopping point because I was waiting 
for his change in order to finish and/or test my change. Or, more 
commonly, I discover a bug in his code and he checks in a fix I want to 
pick up.

That's the use case for dirty working-copy merges. It is extremely 
common in my experience. Actually I can't think of a single company I've 
worked at in ~20 years of professional programming, from huge ones to 
small startups, where that wasn't a frequent working style, especially 
during crunch times or initial implementation.

The XP people even have a name for it: "continuous integration." 
(Granted, that's not *exactly* what that term means, but "update early 
and often" is a pretty important part of the CI workflow.)

It is so much easier to resolve conflicts if you can look at both sides, 
and can actually go to both sides to test things out, or even just 
generate the diff to one side. This is just not possible with a dirty 
merge. Exactly because you knowingly lost the current state, you cannot do 
diffs with it.
  

I don't disagree, but that's only an issue given the underlying 
assumption that you will be integrating only occasionally, and thus will 
tend to pull massive numbers of changes with lots of conflicts. If you 
know there will be at most one or two conflicts (or more likely none at 
all) because your last pull was twenty minutes ago and there have only 
been three other pushes since then, it's not an issue. That's the 
typical situation in a continuous-integration shop. I'd say 95% -- to be 
ridiculously conservative -- of the "svn up" commands that are run at my 
company result in no conflicts at all.

When a large conflict is a once-every-couple-of-months event because 
you've resolved all the trivial conflicts as they've appeared along the 
way, optimizing your daily workflow for the "what if I need to resolve a 
big hairy conflict?" case just doesn't make much sense.

Needless to say (but I do it nevertheless, since I am in a chatty mood), I 
_never_ can be seen doing the 4-command equivalent of `svn up`. I only 
pull when I have a clean state. (Note: this also leads to a more 
structured way of working, which does prevent errors.)
  

And out of curiosity, are you using git for distributed, relatively 
autonomous development, or for collaboration with a high level of 
interdependency between developers?

-Steve

Petr Baudis [off-list ref] writes:

I agree that by now, the situation is too confusing and while I'm not
happy with everything in Git, I believe that by now the best way is to
just fix Git. Therefore, I'm announcing that I don't plan to add any (at
least any significant) new features to Cogito. Sorry to all the Cogito
users, it is a hard decision for me, but by now I believe that it is
much more effective to just focus on Git.

I applaud this; I know this must have been a hard decision for
you to make.

About git homepage:

The very least I wanted to do at any rate with git.or.cz ASAP is to
switch the crash courses to git-oriented ones too. I think git more or
less got to a reasonable point when this is a sane idea.

I would agree, at this point.

When git.or.cz started offering those introductory pages, the
Porcelain-ish scripts (that is correct, "scripts", as there were
no "built-in" -- even "git diff" unified driver was a shell
script to driver diff-index, diff-files and diff-tree) shipped
with the core git was infinitely less pleasant to normal people,
especially the ones who have not seen the early days of git core
which shipped with almost none.  When you and I talked about
what text to put on git.or.cz, it was an obvious and easy thing
to agree on that newbie documentation should be based on Cogito,
and you did all the work to put the site together.

    I am saying this now for new people on the list, as I heard
    an incorrect "theory" that you have been advertising Cogito
    on git.or.cz site against the community's best interest,
    even when nobody seems to talk about it these days on the
    list anymore.

Since the early days of my involvement in git project, I said my
goal was to keep the plumbing stable, enhance the plumbing in
such a way that any and all Porcelains can do what they want
without resorting to Porcelain-specific hacks, so that the
resulting repositories can interoperate no matter what Porcelain
was used on top of the plumbing.  I worded that goal as "make
the choice of Porcelains irrelevant".  While that ideal still
stands, we ended up having rich enough Porcelain in the core
distribution.  To some people, this might look as if we are
making alternative Porcelains irrelevant instead, but that is
not the case.  Many features and workflows that are now
supported by the core Porcelain were first invented outside
(e.g. "automated tag following while fetching" came from
Cogito), and the core Porcelain does not ship with special
purpose features and expect alternative/augmentative Porcelains
to fill the niche (an existing example is that people who want
patch management use StGIT or guilt).  I am reasonably sure that
there still are features and workflows that Cogito supports
better, and given time and motivated users and contributors,
hopefully they will be ported to the core Porcelain.

I would thank you for your effort to ease adoption of git family
of tools to new people with Cogito; I would ask the list to do
the same.

And I look forward to see your continued involvement to make git
better.

On Thu, 19 Apr 2007, Junio C Hamano wrote:

I would thank you for your effort to ease adoption of git family of 
tools to new people with Cogito; I would ask the list to do the same.

Definitely. Thanks, Pasky. A lot of the user-friendliness we have in Git 
now, as opposed to, say, June 2005, is because of cogito. It was sort of a 
"next" for ui enhancements, and it is sort of sad that this is gone now.

Ciao,
Dscho

Hi,

On Thu, 19 Apr 2007, Linus Torvalds wrote:

On Thu, 19 Apr 2007, Johannes Schindelin wrote:

You can't *not* mention branches, simply because even people who only 
track other peoples work do end up often needing to know about it, or at 
least hearing about them..

Well, there is the classical case of an upstream which never merges from 
you, John R. Developer. You have two branches, upstream and local. But Jim 
R. Developer did not work with Git before, just CVS. To Jim, these are not 
two branches. Still, Git operations are easy, and Jim does not have to 
understand branches to track upstream (keeping local changes).

That is a very valid use scenario, at least from my point of view, since I 
use it quite often.

As an example, for me, "next" is upstream, and I keep some changes local, 
either because Junio refused to merge them, or because they are useful to 
nobody except me.

Of course, these _are_ two branches, but I don't have to realize that when 
working with Git in that manner.

Ciao,
Dscho

On Thu, 19 Apr 2007, Marcin Kasperski wrote:

quoted

I agree. And to some degree I suspect that the documentation pushes some of
the advanced things a bit *too* eagerly. (...)

As I am among those, who think that git *is* complicated, I decided to 
sit down, and find out why exactly I think so. Here are the top 
words/options/concepts, which I faced almost immediately while trying 
GIT, and which I find confusing:

rebase
index
revtree
reset
ref / refs
rev-list
rev-parse

Yes. I think it might be a good idea to write some kind of tutorial aimed 
for two very simple cases. Because there are really two cases that stand 
out as being (a) common and (b) something you start out with!

 - Case #1 would be using git basically as a "anonymous CVS" replacement 
   to track somebody others project.

   None of the above are ever really needed for that case, and I think all 
   you really want to learn is:

	git clone
	git pull

	gitk
	git log HEAD@{2.days.ago}..
	gitk HEAD@{1}.. some-file-or-directory

   and not a whole lot more (maybe pointing them at gitweb repos and 
   telling them what the thing can do).  In other words, you want to teach 
   people to just fetch the repo, and perhaps how to see what has changed 
   lately.

   In an advanced section for this usage case might be things like

	git bisect

   to teach people who track other peoples repository how to help those 
   other people find bugs when something goes wrong. But that would 
   literally be an "advanced topic".

 - Case #2 is the "how to start tracking your own project".

   In some ways, it's even *more* trivial, becuase if you start a new 
   project, you usually start from scratch (or perhaps from some CVS 
   import), with just one branch, and your first worry is not even how to 
   export it yet, but how to just *use* it for development.

   So for case #2, we'd never even mention "git clone/pull" or branches, 
   but instead we'd just talk about

	git init	(and "git cvsimport" or something)
	git add/rm/commit
	git diff/show
	git reset
	git checkout

   and walk through an everyday problem set of just some _very_ basic 
   situations. Explain the whole "content" thing, so that people 
   understand why "git add <filename>" + "git diff" doesn't actually show 
   the filename at all, and what the difference between "git diff" and 
   "git diff HEAD" is.

Those two usage cases actually cover a lot of trivial CVS usage already. A 
lot of people probably don't need to learn about branches AT ALL,  or 
about concurrent development, or anything like that. 

And the good news is that once you are very comfy with the two trivial 
cases, it's much easier to *later* explain how those two can actually be 
combined. In other words, there's probably not any reason at all to even 
start to talk about merging and branches until people are actually ready 
for it, and start asking you "so what happens if I've made changes and 
want to update to the most recent version". 

Similarly, you generally don't want to actually start serving your 
projects to others until long after you've started using the thing for 
development, so early on, it's probably perfectly fine to tell people: 
don't worry about setting up a server or gitweb, just be happy in the 
knowledge that it *can* be done, and has been done for big projects, so 
when you actually want to do that, you can do all these fancy things, but 
you shouldn't worry about it _yet_.

			Linus

Hi,

On Thu, 19 Apr 2007, Steven Grimm wrote:

Johannes Schindelin wrote:

quoted

Let me pick up the ball here. Once you did your share of conflicting 
merges, you _will_ realize how much better it is to merge when you are 
at a relatively stable state, i.e. you can test things (if only to 
make sure that the merge did not introduce strange side effects). And 
guess what, at such a stage I would commit anyway.

That's a great workflow if you're working on relatively discrete, 
standalone changes. A lot of the time, when I'm working on an isolated 
change, I do just that, and I merge when I'm stable just like you 
describe. That's probably the vastly most common mode of operation for 
distributed open-source projects, which obviously were git's initial 
target audience.

It is also possible (and I do that) when merging often. I use cherry-pick 
for that. At a later stage, I merge, and this mostly succeeds, since the 
merge is really a 3-way merge (with the obvious results).

And out of curiosity, are you using git for distributed, relatively 
autonomous development, or for collaboration with a high level of 
interdependency between developers?

I use Git virtually everywhere it can be used:

- backups
- personal projects
- configuration files
- documents
- collaboration with other people
- tracking CVS
- ...

Ciao,
Dscho

On Thu, Apr 19, 2007 at 09:43:50AM -0700, Linus Torvalds wrote:

On Thu, 19 Apr 2007, Johannes Schindelin wrote:

quoted

Hmm. However, I have to say that cogito serves/d another purpose quite 
well: Look at what came from cogito into git. Loads of useful 
enhancements. So, I really have to point to "at this stage", because that 
sure was not true 18 months ago.

Absolutely. I think there are still some pieces of cogito that we might 
want to migrate into git too, although they're fairly esoteric (ie the 
whole history rewriting thing). And I think we still have some places 

I actually have a fairly simple history rewriting script (written in python)
that I used when I converted some CVS archives to git. It is really intended
for such an initial import and history cleanup case so it doesn't deal with
reflogs and such.

Basic workflow I used is,

- Import CVS archive into a git repository
- Use gitk + the grafts file to clean up history as much as feasible
- Run git-rewrite-history.py which will
    - write out new commit objects with the corrected set of parents
    - copy existing refs to .git/newrefs, pointing them at the new commits.

- start gitk --all to see the tree before the rewrite.
- mv .git/refs .git/oldrefs ; mv .git/newrefs .git/refs
- start a second gitk --all to see the tree after the rewrite.
- compare gitk output to check if everything matches up.

- run git repack/prune/gc to get rid of the old commits, or clone the repo.

Jan

--8<-----------------------------------------------------------------------

#!/usr/bin/python

import os, sys

def git_write_object(type, blob):
    stdin, stdout = os.popen2("git-hash-object -t %s -w --stdin" % type)
    stdin.write(blob)
    stdin.close()
    return stdout.readline().strip()

def git_commits(branch):
    f = os.popen('git-rev-list --parents --header --topo-order %s' % branch)
    buf = ''
    while 1:
	buf = buf + f.read(4096)
	if not buf: break
	if not '\0' in buf: continue
	commit, buf = buf.split('\0', 1)
	yield Commit(commit)

def git_update_ref(name, hash):
    os.system('git-update-ref "%s" "%s"' % (name, hash))

grafts = []
pending = []
rewriteable = []
remap = {}
todo = 0
class Commit:
    def __init__(self, commit):
	global grafts
	lines = commit.split('\n')
	parts = lines.pop(0).split()
	self.hash, self.parents = parts[0], parts[1:]

	self.tree = lines.pop(0)

	parents = []
	while lines[0][:7] == 'parent ':
	    parents = parents + lines.pop(0).split()[1:]

	if parents != self.parents:
	    grafts.append(self.hash)

	commit = []
	while 1:
	    line = lines.pop(0)
	    commit.append(line)
	    if not line: break

	for line in lines:
	    commit.append(line[4:])
	self.commit = '\n'.join(commit)

	self.wait = 0
	self.children = []

    def mark(self):
	global todo, pending
	self.wait = self.wait + 1
	if self.wait == 1:
	    todo = todo + 1
	    for child in self.children:
		pending.append(child.hash)

    def pick(self):
	global rewriteable
	self.wait = self.wait - 1
	if not self.wait:
	    rewriteable.append(self)

    def fixup(self, old_hash, new_hash):
	i = self.parents.index(old_hash)
	self.parents[i] = new_hash
	self.pick()

    def rehash(self):
	global todo, remap
	todo = todo - 1

	blob = self.tree + '\n'
	for parent in self.parents:
	    blob = blob + 'parent %s\n' % parent
	blob = blob + self.commit

	new_hash = git_write_object('commit', blob)
	remap[self.hash] = new_hash

	for child in self.children:
	    child.fixup(self.hash, new_hash)

print "Reading commits... ",
commits = {}
for commit in git_commits('--all'):
    commits[commit.hash] = commit
print "read %d commits, found %d grafts" % (len(commits), len(grafts))

print "Setting up reverse linkage"
for commit in commits.values():
    for parent in commit.parents:
	commits[parent].children.append(commit)

print "Propagating graft information... ",
# first mark all commits that will have to be rewritten.
for commit in grafts:
    commits[commit].mark()

for commit in pending:
    commits[commit].mark()

# pick those commits that do not depend on any earlier rewrites
for commit in grafts:
    commits[commit].pick()
print "%d commits need to be rewritten" % todo

print "Rewriting commits... "
while rewriteable:
    print "\rrewriting %5d/%5d commits" % (len(rewriteable), todo),
    rewriteable.pop().rehash()
print "done..."

print "Rewriting refs..."
for ref in os.popen('git-for-each-ref'):
    hash, type, name = ref.split()
    if type != 'commit': continue

    if remap.has_key(hash):
	hash = remap[hash]

    # write updated refs to .git/newrefs
    git_update_ref('new' + name, hash)

print "done..."

Hi,

On Fri, 20 Apr 2007, Jan Harkes wrote:

On Thu, Apr 19, 2007 at 09:43:50AM -0700, Linus Torvalds wrote:

quoted

On Thu, 19 Apr 2007, Johannes Schindelin wrote:

quoted

Hmm. However, I have to say that cogito serves/d another purpose 
quite well: Look at what came from cogito into git. Loads of useful 
enhancements. So, I really have to point to "at this stage", because 
that sure was not true 18 months ago.

Absolutely. I think there are still some pieces of cogito that we 
might want to migrate into git too, although they're fairly esoteric 
(ie the whole history rewriting thing). And I think we still have some 
places

I actually have a fairly simple history rewriting script (written in 
python) that I used when I converted some CVS archives to git.

Telling by your description, cg-admin-rewrite-hist is more capable. And I 
think it should not be too complicated to rewrite the cogito specific 
parts, what with the parts we added to Git with cogito as a model. And it 
is in Perl... which makes it more portable than Python in my part of the 
world.

Ciao,
Dscho

On Fri, Apr 20, 2007 at 08:39:25PM CEST, Johannes Schindelin wrote:

Telling by your description, cg-admin-rewrite-hist is more capable. And I 
think it should not be too complicated to rewrite the cogito specific 
parts, what with the parts we added to Git with cogito as a model. And it 
is in Perl... which makes it more portable than Python in my part of the 
world.

It is in shell, actually. (Well, bash, but I think [[ is the only
bashism in that one.) And it was specifically written to be as
independent of Cogito as possible, I think it uses only Cogito's cool
commandline parsing routines. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

On Fri, Apr 20, 2007 at 08:39:25PM +0200, Johannes Schindelin wrote:

On Fri, 20 Apr 2007, Jan Harkes wrote:

quoted

On Thu, Apr 19, 2007 at 09:43:50AM -0700, Linus Torvalds wrote:

quoted

On Thu, 19 Apr 2007, Johannes Schindelin wrote:

quoted

Hmm. However, I have to say that cogito serves/d another purpose 
quite well: Look at what came from cogito into git. Loads of useful 
enhancements. So, I really have to point to "at this stage", because 
that sure was not true 18 months ago.

Absolutely. I think there are still some pieces of cogito that we 
might want to migrate into git too, although they're fairly esoteric 
(ie the whole history rewriting thing). And I think we still have some 
places

I actually have a fairly simple history rewriting script (written in 
python) that I used when I converted some CVS archives to git.

Telling by your description, cg-admin-rewrite-hist is more capable. And I 
think it should not be too complicated to rewrite the cogito specific 
parts, what with the parts we added to Git with cogito as a model. And it 
is in Perl... which makes it more portable than Python in my part of the 
world.

As I wrote this a while ago, before reflogs and packed refs, and I only
needed it for the initial conversion, it only had to write out new
commit objects and retarget branch heads and simple tags. If
cg-admin-rewrite-hist can do better and can be merged into git-core I
would say that is a win-win situation for everyone.

Something like this should be available to allow people to reconstruct
their merge history or fix up empty 'file was added on branch foo'
commits that are left around after the initial import from another VCS.

Personally, I don't think it should ever be used for any published
repositories or branches. Most fixups before publishing can already be
done by rebasing or amending a commit, so this would only be useful for
that intial import where there are in fact a lot of scattered changes
all over the place, or to reconstruct a merge that went bad. But really
in that case, it is probably better to redo the merge correctly and
rebase any commits that might have gone in after the bad merge.

Jan

On Thu, 19 Apr 2007 13:57:35 -0700 (PDT), Linus Torvalds wrote:

 - Case #1 would be using git basically as a "anonymous CVS" replacement
   to track somebody others project.

I'd extend this to also say "tracking a specific branch" in some
project.

When I raised this recently, Junio suggested something like the
following:

	git config --global branch.autosetupmerge true	[*]
	git clone <URL>
	git checkout -b <branch> origin/<branch>
	git pull

I haven't gotten around to replying to that message yet, but the
thrust of my reply would be that that does actually work, but it's not
even close to the ease with which one can track the default branch as
Linus described:

   None of the above are ever really needed for that case, and I think all
   you really want to learn is:

	git clone
	git pull

So, currently, all non-default branches have a sort of second-class
status from the point of view of users that just want to track
them.

Compare this to svn, for example. Now, svn has an insanely broken
model for what a branch actually is, while git's model is sane.  But I
think that with svn the "anonymously tracking a branch" use case isn't
any harder for any one branch compared to any other, (it's just a
matter of starting with the right URL). I'd love to see git achieve
the same thing.

-Carl

[*] Is the command I have above even correct? What Junio actually
suggested was:

	$ cat >>$HOME/.gitconfig <<\EOF
	[branch]
		autosetupmerge
	EOF

But I can't find a way to use git-config create a block that looks
like that. I'm just guessing that "autosetupmerge = true" works
equivalently, but I could be wildly wrong.

On Monday 23 April 2007, Carl Worth wrote:

On Thu, 19 Apr 2007 13:57:35 -0700 (PDT), Linus Torvalds wrote:

quoted

 - Case #1 would be using git basically as a "anonymous CVS" replacement
   to track somebody others project.

I'd extend this to also say "tracking a specific branch" in some
project.

When I raised this recently, Junio suggested something like the
following:

	git config --global branch.autosetupmerge true	[*]
	git clone <URL>
	git checkout -b <branch> origin/<branch>
	git pull

I haven't gotten around to replying to that message yet, but the
thrust of my reply would be that that does actually work, but it's not
even close to the ease with which one can track the default branch as
Linus described:

The commands above are not needed for pure tracking, but instead prepare
a local development branch for you to work on, and where you can pull
upstream changes with "git pull".
For tracking a remote $branch, it should be enough to do

 git clone
 git fetch

and you get the any (*) remote $branch as "remotes/origin/$branch".

Josef


(*) Perhaps the "any" is too much for wanting to track one branch only?

quoted

   None of the above are ever really needed for that case, and I think all
   you really want to learn is:

	git clone
	git pull

So, currently, all non-default branches have a sort of second-class
status from the point of view of users that just want to track
them.

Compare this to svn, for example. Now, svn has an insanely broken
model for what a branch actually is, while git's model is sane.  But I
think that with svn the "anonymously tracking a branch" use case isn't
any harder for any one branch compared to any other, (it's just a
matter of starting with the right URL). I'd love to see git achieve
the same thing.

-Carl

[*] Is the command I have above even correct? What Junio actually
suggested was:

	$ cat >>$HOME/.gitconfig <<\EOF
	[branch]
		autosetupmerge
	EOF

But I can't find a way to use git-config create a block that looks
like that. I'm just guessing that "autosetupmerge = true" works
equivalently, but I could be wildly wrong.

On Mon, 23 Apr 2007 21:52:58 +0200,Josef Weidendorfer wrote:

The commands above are not needed for pure tracking, but instead prepare
a local development branch for you to work on, and where you can pull
upstream changes with "git pull".
For tracking a remote $branch, it should be enough to do

 git clone
 git fetch

and you get the any (*) remote $branch as "remotes/origin/$branch".

By "tracking" I mean the ability to get the working-tree state to
match that of some remote-tracking branch and then be able to
periodically do some command, ("git pull"), to make the working-tree
reflect the latest state of that remote branch.

So the fact that at any given point I can say:

	git checkout origin/<branch>

and get into a detached-HEAD where the working-tree matches what I
last fetched, doesn't quite do the job. From there, there's nothing
like "git pull" to usefully bring the working-tree state up to the
latest. Issuing "git pull" from the detached HEAD state does fetch,
but then complains:

	You are not currently on a branch; you must explicitly
	specify which branch you wish to merge:
	  git pull <remote> <branch>

So, no, the current git-clone alone does not get me to where I'd like
to be.

-Carl

On 4/17/07, Tomash Brechko [off-list ref] wrote:

On Tue, Apr 17, 2007 at 10:02:18 +0100, Pietro Mascagni wrote:

quoted

So, in 15 seconds, how does one argue that GIT is vastly superior to
other version control software, especially CVS.

... You can't really
explain why 'git commit; git push' into some central repository is
better than 'cvs commit', and pushing after every commit is what
people will be doing at first ;).

Yes, your point here is very real --
this perception that git imposes an "extra step"
is one thing I'm trying to avoid right now.  I think I've almost succeeded...
-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell

On 4/17/07, Alex Riesen [off-list ref] wrote:

On 4/17/07, Martin Langhoff [off-list ref] wrote:

quoted

 - Old school SCMs allow you to branch, but are unable to keep track
of merges in any meaningful way. Every time you merge, history is
lost. GIT (and other DSCMs) have excellent branching _and_ merging
facilities.

This one was a bad argument too. Curiously, and I cannot explain why,
ability to branch is considered a weakness of GIT ("because it confuses
the integrators", them being old mean men). The Perforce is said to
be "vastly superior to everything" on these grounds: "it also has
branching support, but luckily(!) it is hard enough for simple
developers. Was not their (Perforce's) fault, they just included it
to keep up with the market". Almost exact wording (I had to translate it).

You are also trying to gain traction in a Perforce environment?
I'd be interested in any more details you might have;
I'm just starting.  Email me directly if you like.

Thanks,
-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell

On 4/25/07, Dana How [off-list ref] wrote:

On 4/17/07, Alex Riesen [off-list ref] wrote:

quoted

On 4/17/07, Martin Langhoff [off-list ref] wrote:

quoted

 - Old school SCMs allow you to branch, but are unable to keep track
of merges in any meaningful way. Every time you merge, history is
lost. GIT (and other DSCMs) have excellent branching _and_ merging
facilities.

This one was a bad argument too. Curiously, and I cannot explain why,
ability to branch is considered a weakness of GIT ("because it confuses
the integrators", them being old mean men). The Perforce is said to
be "vastly superior to everything" on these grounds: "it also has
branching support, but luckily(!) it is hard enough for simple
developers. Was not their (Perforce's) fault, they just included it
to keep up with the market". Almost exact wording (I had to translate it).

You are also trying to gain traction in a Perforce environment?
I'd be interested in any more details you might have;

Well, as I have failed on every attempt get the idea through,
I am not sure I _have_ any useful details which can be shared.
Right at this moment I'm working on importing/exporting scripts
which hopefully can impress my colleagues enough to use git
(P4 is almost universally hated). The problem is complicated
by the fact we have to use a homegrown program which replaces
"p4 sync" (as it is somewhat handicapped in its ability to specify
what revision of what part of a project to sync).
At the moment there 4 scripts: one to workaround the mentioned
tool (unrelated to git), one to put the data into index (must use
perforce to get the real names of the files, the local names
constantly get mangled by windows), one to commit the index
along with information about the clients state (mappings aka
client specification, revision lists and custom information this
dumb tool of ours needs) and one to export git changes.
All this is very loosely connected and integrated, so I can use
them independent of each other. This also means that there
is a lot of hand work to do, though. I can share the last three
scripts, if anyone interested (the first is of no use to anyone,
except me).

Hi,

On Wed, 18 Apr 2007, Linus Torvalds wrote:

On Wed, 18 Apr 2007, Johannes Schindelin wrote:

quoted

On Tue, 17 Apr 2007, Marcin Kasperski wrote:

quoted

a) Windows are unsupported

Wrong.

It's a bit more work to set up though, and it has a lot less mindshare, 
and testing, obviously.

Given the fact that Hannes is working not only _on_, but _with_ it, tells 
me that it works well enough for any Windows user (remember, they are used 
to rebooting their machines several times a day, just to keep them 
running).

So yes, windows is a step-child. I'd love for it to not be one, and 
we'll get there, but it's clearly not as supported as the unix side. We 
still use a fair number of shell scripts (which in turn use unix 
commands and pipelines).

Of course, the Windows users' "I want, but I don't contribute" mindset 
does not help either.

We'll get away from it. I think GSoC will help here.

Unfortunately not as much as I hoped for. Since Google slashed our number 
of projects, we could not get funding for a developer who promised to make 
a Windows installer, and to work on the user experience on Windows.

Pity.

Actually, at this stage, I really think cogito just *complicates* git 
usage.

Hmm. However, I have to say that cogito serves/d another purpose quite 
well: Look at what came from cogito into git. Loads of useful 
enhancements. So, I really have to point to "at this stage", because that 
sure was not true 18 months ago.

What _is_ true is that git is simply different from CVS. I don't think 
it's necessarily harder to understand or use (in fact, I would argue 
that git is a lot _easier_ to understand), but it is *different*, and it 
has a ton more capabilities.

I guess that we should not say that Git is complicated. People tend to 
believe that, but it is simply not true. The basic steps are easy. Really 
easy.

But Git does not keep you there.

So people coming from CVS/SVN have a double shock: they are supposed to 
learn things that they "know" are hard (because CVS/SVN made them so damn 
hard - don't tell me that SVN branching is easy, because it is *not* easy. 
It may be cheaper to create a branch, but it has _all_ the same idiocies 
that CVS has once it's created).

It is also dog slow.

Ciao,
Dscho