git versus CVS (versus bk)

My memory is playing tricks on me.  I seem to remember running linux
in the 1980's, but the earliest kernel I can find on kernel.org is
dated 1994.  Maybe I'm remembering xenix...dunno.

Anyway, I've been tracking Linus's kernel for many years -- long
before bitkeeper or git.

I know just enough to compile and run a kernel, but not enough to
be a software developer.  And that is where my question comes from:

Could someone explain to me the shortcomings of CVS which prompted
the development of bk (and then git) -- in a way that a non-developer
like me can understand?  Pretend that you are Albert Einstein, trying
to explain your theories to a ten-year-old -- this is always a useful
exercise for those of you who are drowning in micro-details!

I've already done some googling on this subject, but everything I've
found is drenched in those micro-details which make the subject
opaque to me.

Thanks for any pointers!

On 10/31/05, walt [off-list ref] wrote:

Could someone explain to me the shortcomings of CVS which prompted
the development of bk (and then git) -- in a way that a non-developer
like me can understand?

You need to understand the SCM "problem space" at least a little bit.
Can't cheat on that unfortunately.

The writeup at http://www.dwheeler.com/essays/scm.html is not perfect,
but should give you a bit of background. It barely covers git -- we
need to prod the author to update it ;)



martin

walt wrote:

My memory is playing tricks on me.  I seem to remember running linux
in the 1980's, but the earliest kernel I can find on kernel.org is
dated 1994.  Maybe I'm remembering xenix...dunno.

The very first version of Linux came out in 1991.

	-hpa

On Sun, 30 Oct 2005, walt wrote:

My memory is playing tricks on me.  I seem to remember running linux
in the 1980's, but the earliest kernel I can find on kernel.org is
dated 1994.  Maybe I'm remembering xenix...dunno.

-91 was the first version. It was usable (depending on your definition of 
"usable" ;) in early -92.

Could someone explain to me the shortcomings of CVS which prompted
the development of bk (and then git) -- in a way that a non-developer
like me can understand?

It's really not very easy to explain why CVS sucks. After all, sometimes 
people who have used it for decades have a hard time understanding the 
suckiness.

I've used CVS for "real work" at Transmeta, and hey, it worked well 
enough. When you have groups of just a couple of tens of people max, and 
very strict rules on how to do things, and you trust everybody, CVS works 
fine. It starts to really show its problems whenever you need to work 
remotely, but there are things you can do to make the pain less.

A lot of CVS people will tell you that it sucks because it can't do 
renames, and because certain operations take forever (tagging etc). That's 
only superficially true, and it is really a suckiness that comes from some 
implementation issues.

SVN fixes (supposedly) those "implementation suckiness" issues. It does so 
largely by doing a much better database, which allows it to do certain 
things much more efficiently. Personally that part scares me, since I 
think it's also a much more fragile setup and there's apparently been 
people who lost their entire database to corruption (something that is 
very hard to do with CVS, since the "database" is so weak), but that's a 
different issue.

But the things that SVN fixes are not the things that really matter in the 
end. SVN i sa better CVS, but it still has all the basic fundamental 
problems. Namely the fact that it's centralized.

The problem with a centralized model is that there's one point of contact: 
you can replicate the central database endlessly, but you can only really 
modify it in one place. Which means that anybody who wants to modify 
anything at all needs to have write access to that one repository.

Now, you can limit write access in various ways ("user xyz can only write 
to these files"), but it still requires an a-priori trust network rather 
than a dynamic one. So every single CVS project (and SVN does zero in this 
regard) always ends up having politics around the question of who gets 
commit privileges, and what the rules for them are.

So one of the worst downsides of CVS is _politics_. People, not 
technology.

The other implication of centralization is the fact that it means that you 
can't do any off-line work. You need to be able to access the central 
database in order to do real work. You can replicate the repository and 
try to take it with you and then back-port whatever changes you did when 
you come back, but more commonly it means that when you go off with a 
laptop, you're either in read-only mode, or you need to have an internet 
connection whenever you want to do development. That's just nasty.

The upside of centralization is that a lot of things are easier. Easier to 
think about, easier to get a stupid and straightforward idea working. 

But if you have hundreds of developers, and you have a dynamic trust 
network (I trust some people, they trust others, and we all tend to trust 
people more or less depending on what they work on), the CVS model is 
absolutely HORRID. It just doesn't work.

Git does all of that right. So did BK, for that matter. There's no 
a-priori "these people can commit", because there's no central database. 
There's no problem with off-line work, because every repository is totally 
self-contained and independent of every other one.

			Linus

Hi,

On Sun, 30 Oct 2005, Linus Torvalds wrote:

It's really not very easy to explain why CVS sucks. After all, sometimes 
people who have used it for decades have a hard time understanding the 
suckiness.

[...]

How about adding the whole explanation as

	git/Documentation/howto/tell-why-cvs-sucks.txt

(maybe with some more polite name)?

Also, I´d like to add that CVS branching/merging is no good:

<tryingtoputonalbertsshoes>

Sometimes a developer gets an idea, or the need, to implement a certain 
feature to a piece of free software. Now, this idea might seem good, but 
it might take a while to

	- implement it,
	- flesh the bugs out, and
	- maybe realize the idea was not all that good.

All the while, the project is prospering, and you have to keep up-to-date. 
With CVS, you would do "cvs update" every once in a while, and clean up 
the merge conflicts. In effect, you would track the history of the 
upstream project.

Often, however, you would like to track *your* changes, too. This is not 
possible in CVS. You just can´t track two different histories in the same 
working directory.

Now, if you are working on two or more different ideas, which you want to 
test separately *and* together, you need to merge your local branches 
every once in a while. If it weren´t for "every once in a while", but 
"once", you still could do it in CVS. If you want to merge several times 
(keeping the separate development branches), you can´t.

</tryingtoputonalbertsshoesfailingmiserably>

Ciao,
Dscho

On Sun, 30 Oct 2005, Linus Torvalds wrote:

On Sun, 30 Oct 2005, walt wrote:

quoted

Could someone explain to me the shortcomings of CVS which prompted
the development of bk (and then git) -- in a way that a non-developer
like me can understand?

It's really not very easy to explain...

<explanation snipped>

But you explained very well, thank you!  And thanks to the others who
responded -- all very helpful.  I'm off to read the link that Martin
supplied -- looks gossipy enough to keep me awake :o)

On Mon, 31 Oct 2005, Johannes Schindelin wrote:

How about adding the whole explanation as

	git/Documentation/howto/tell-why-cvs-sucks.txt

(maybe with some more polite name)?

Hey, if somebody else does it, that's fine.

I'm personally _so_ biased against CVS that I'm not neutral. I really hate 
the thing. I'd much rather use tar-balls and patches than CVS: I think 
"quilt" ends up being much nicer in many ways than CVS can be.

So feel free to take my explanations and write something up. I just don't 
want to do it, because I fear I might be unfair to CVS (well.. I'm 
personally 120% convinced I'm not, but still, there's a lot of people who 
actually _use_ it, so..).

Also, I´d like to add that CVS branching/merging is no good:

<tryingtoputonalbertsshoes>

Sometimes a developer gets an idea, or the need, to implement a certain 
feature to a piece of free software. Now, this idea might seem good, but 
it might take a while to

	- implement it,
	- flesh the bugs out, and
	- maybe realize the idea was not all that good.

[ details deleted ]

Yes. I consider this to be part of the centralized/distributed issue, but 
it's worth talking about. A distributed system automatically implies that 
you can have "throw-away branches" for testing, and you can combine two or 
more of these test-branches without ever disturbing (or even _notifying_) 
the "real development" branch.

In a centralized system, any branches will always be in that central 
repository, so you can't do throw-away stuff without affecting everybody 
else. Maybe the actual _code_ won't be in the "real development" branch, 
but you're writing and affecting the same repository where the development 
happens.

Again, you could replicate the whole repo, and do things there, but then 
you can't ever merge again, which in effect makes the small branch a big 
fork. So in that sense the CVS/SVN mentality basically encourages forking 
and discourages working together. This is more of the same thing that I 
alluded to when saying that CVS inevitably leads to "politics" - having a 
central place means that you have people who fight for control over it, 
even when they'd otherwise _want_ to cooperate.

With git (or with BK, or any truly decentralized model), you just make 
your own repo, do your development there, and you never need to ask for 
permissions from the central repo people. If the development works out, 
you just ask people to merge back. And if it doesn't, you don't even have 
to tell people what a total failure you were.

So with the distributed model, you don't have to publicly humiliate 
yourself when you do something stupid. Similarly, you don't have to 
publicly prove that you're "good enough" before you can play in the 
sandbox. In other words, there's no need for politics and egos.

(Now, obviously, when you've actually done the work, if people recognize 
that you're a mental giant, they'll be more likely to merge with you, and 
you'll generally have an easier time. So I'm not saying that a distributed 
model takes away the need for showing how good you are, but it doesn't 
make that a central pre-conception).

			Linus

On Mon, 31 Oct 2005, Linus Torvalds wrote:

...CVS inevitably leads to "politics" - having a
central place means that you have people who fight for control over it,
even when they'd otherwise _want_ to cooperate...

Ahh -- the lightbulb just lit up.  Using CVS is just like being married.
No wonder you hate it...

quoted

quoted

quoted

quoted

"wa1ter" == wa1ter  [off-list ref] writes:

wa1ter> Ahh -- the lightbulb just lit up.  Using CVS is just like
wa1ter> being married.  No wonder you hate it...

Now, hey hey.  I've met Tove.  She's very nice.  I doubt that Linus
would compare his marriage to her with CVS. :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[off-list ref] <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

On Mon, Oct 31, 2005 at 08:18:49AM -0800, Linus Torvalds wrote:

With git (or with BK, or any truly decentralized model), you just make 
your own repo, do your development there, and you never need to ask for 
permissions from the central repo people. If the development works out, 
you just ask people to merge back. And if it doesn't, you don't even have 
to tell people what a total failure you were.

	Actually, Linus, this provokes a question I've always wanted the
answer to.  I'm well aware of the centralized/distributed stuff you are
discussing, but there is policy regarding the distributed merges I've
never been quite clear on.
	When one does a feature branch, one creates a "throw-away"
repository.  They work on the feature, and when they are done, they
pull/push back to the main repository.  This pattern is pretty much
identical in both centralized in distributed environments, even if the
nuts-and-bolts are different.
	In the CVS/Subversion world, this merge becomes a single commit
on the "main" line of development ("trunk", or whatever you call it).
The merge has no concept of the steps taken to create the change, just
the actual patch.  This has the disadvantage that you have to work hard
in the branch namespace to find the actual steps taken (the working
repository for the feature), but the advantage that a quick look does
not have to wade through fits and starts as the feature takes shape.
	In the distributed world, a pull of the "feature" repository
pulls in all changes - the full history of the work.  This includes
aborted tries, rewritten pieces, bug fixes, etc.  Here, the main
repository has the detritus of the development process, but that also
contains the full context of the work.  It goes against your claim that:

So with the distributed model, you don't have to publicly humiliate 
yourself when you do something stupid. Similarly, you don't have to 

because that history will contain all your something stupids, plus your
fixes for them.
	But that's not how the kernel and git appear to work.  Many
developers have popularized dropping that context.  They take their
working repository, diff it against your mainline repository, and then
create a new repository that is merely your mainline plus one commit,
the patch of their changes.
	This violently breaks the model of "work in a new repository,
then have it pulled into the 'main' repository."  It has no real support
in the git/cogito command space (that I know of).  It does, however,
leave all the intermediate commits out of your tree, with only a feature
commit remaining.
	Where do you stand on this?  Would you rather see the full
history pulled?  Do you prefer the one-clean-patch approach?  If so, is
there any way to get a cogito/git command for it (git-pull-as-one?)?

Joel

-- 

"Drake!  We're LEAVING!"

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

On 11/1/05, Joel Becker [off-list ref] wrote:

        Where do you stand on this?  Would you rather see the full
history pulled?  Do you prefer the one-clean-patch approach?  If so, is
there any way to get a cogito/git command for it (git-pull-as-one?)?

You can do a diff that spans all the commits and apply it with a new
commit msg. With cogito:

   cg-diff -r from:to | patch -p1

With git you can also do it directly within the repo/index with

   git-read-tree -m from HEAD to

In practice, a new developer will often roll up commits to avoid
sending a string of shameful patches and corrections on top -- I often
do that ;-) . Developers with more "mana" will have published repos
where Junio pulls directly from -- and they get merged with full
history. Of course -- they don't have brown-paper-bag commits like I
do...

Sounds like a reasonable, organic/dynamic way of doing it.

cheers,


martin

On Tue, Nov 01, 2005 at 09:28:30AM +1300, Martin Langhoff wrote:

You can do a diff that spans all the commits and apply it with a new
commit msg. With cogito:

   cg-diff -r from:to | patch -p1

	I'm well aware of this, my question was rather one of
applicability.  First, do we want it to work this way, losing the
history.  Second, you'd like the process to be all encompasing if you go
this route.

    ((cd old-repo && cg-diff -r from) | patch -p1) && cg-commit

or any equivalent.  Why should I have to muck with patch and diff, when
I can have a 'pull-as-one' operation.  Sure, it's a wrapper, but if its
the intended mode of development, let's make it a first-class citizen.

Joel

-- 

Life's Little Instruction Book #157 

	"Take time to smell the roses."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

On Mon, 31 Oct 2005, Joel Becker wrote:

	In the CVS/Subversion world, this merge becomes a single commit
on the "main" line of development ("trunk", or whatever you call it).
The merge has no concept of the steps taken to create the change, just
the actual patch.  This has the disadvantage that you have to work hard
in the branch namespace to find the actual steps taken (the working
repository for the feature), but the advantage that a quick look does
not have to wade through fits and starts as the feature takes shape.

Note that I'm a big proponent of people cleaning up their private 
work-in-progress trees before merging.

In fact, I'll refuse to merge with too dirty a repository. It's ok to have 
some fixes for mistakes, but if you have a lot of ugly stuff, use git to 
first track the development, and then start a new branch that has the 
cleaned-up version in it.

quoted

So with the distributed model, you don't have to publicly humiliate 
yourself when you do something stupid. Similarly, you don't have to 

because that history will contain all your something stupids, plus your
fixes for them.

No, exactly because you do _not_ have to publicly humiliate yourself with 
showing what a nincompoop you are.

People should try things out, but they should clean up their worst 
mistakes too. Git allows both.

		Linus

Randal L. Schwartz wrote:

...I doubt that Linus
would compare his marriage...with CVS. :)

I dunno why not.  If my wife knew CVS she would probably agree
with me (for a change).

I've learned a great deal from reading this thread -- as I hope
others have.  I did learn one important thing while reading about
old Al Einstein:  you can get some astonishing insights by asking
really dumb questions of really smart people.

I've had many such astonishing insights from reading Linus's posts
over the years (and I look forward to many more).  I've been amazed
by Linus's understanding of both machines and people -- this combo
is rare indeed!

Linus, have you considered a career in marriage counseling?

On Mon, 31 Oct 2005, Randal L. Schwartz wrote:

quoted

quoted

quoted

quoted

quoted

"wa1ter" == wa1ter  [off-list ref] writes:

wa1ter> Ahh -- the lightbulb just lit up.  Using CVS is just like
wa1ter> being married.  No wonder you hate it...

Now, hey hey.  I've met Tove.  She's very nice.  I doubt that Linus
would compare his marriage to her with CVS. :)

He did say that CVS worked reasonably at Transmeta. He's probably just as 
glad she's not married to the entire Linux development community...

Being married is great, but it just doesn't scale past a dozen people who 
trust each other and have rules on how they do things.

	-Daniel
*This .sig left intentionally blank*

On Mon, 31 Oct 2005, Daniel Barkalow wrote:

Being married is great, but it just doesn't scale past a dozen people who 
trust each other and have rules on how they do things.

This thread is getting a big psychedelic.

People, take your meds, please,

		Linus

quoted

quoted

quoted

quoted

"Martin" == Martin Langhoff [off-list ref] writes:

Martin> You can do a diff that spans all the commits and apply it with a new
Martin> commit msg. With cogito:

Martin>    cg-diff -r from:to | patch -p1

What's the easiest way then to toss all that intermediate history?
I'm thinking of the rcs "-o" switch that "outdates" any deltas in that
range.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[off-list ref] <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

On Mon, 31 Oct 2005, Randal L. Schwartz wrote:

Martin>    cg-diff -r from:to | patch -p1

What's the easiest way then to toss all that intermediate history?
I'm thinking of the rcs "-o" switch that "outdates" any deltas in that
range.

Start a new branch before the sequence you want to clean up. Then, move 
the cleaned-up history to that branch, and eventually you can just delete 
the old one.

		Linus

quoted

quoted

quoted

quoted

"Linus" == Linus Torvalds [off-list ref] writes:

Linus> Start a new branch before the sequence you want to clean
Linus> up. Then, move the cleaned-up history to that branch, and
Linus> eventually you can just delete the old one.

So if I toss something in git/refs, the objects pointed to by that are
eventually reclaimed?  Do I need to git-fsck-objects to do that?  Or
is there some cg command to do the whole thing?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[off-list ref] <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

On Mon, 31 Oct 2005, Randal L. Schwartz wrote:

Linus> Start a new branch before the sequence you want to clean
Linus> up. Then, move the cleaned-up history to that branch, and
Linus> eventually you can just delete the old one.

So if I toss something in git/refs, the objects pointed to by that are
eventually reclaimed?  Do I need to git-fsck-objects to do that?  Or
is there some cg command to do the whole thing?

You can do "git prune". It's pretty expensive, though, and the extra 
objects don't _hurt_, so there's no reason to do pruning very 
aggressively. I tend to prune immediately just because I run 
git-fsck-objects all the time, and if you don't prune, it will nag you 
about "dangling commit".

You may also decide to just rename the old broken branch. Keeping it 
around for local historical reasons and never push it out.

		Linus

Dear diary, on Mon, Oct 31, 2005 at 10:30:03PM CET, I got a letter
where Joel Becker [off-list ref] told me that...

On Tue, Nov 01, 2005 at 09:28:30AM +1300, Martin Langhoff wrote:

quoted

You can do a diff that spans all the commits and apply it with a new
commit msg. With cogito:

   cg-diff -r from:to | patch -p1

	I'm well aware of this, my question was rather one of
applicability.  First, do we want it to work this way, losing the
history.  Second, you'd like the process to be all encompasing if you go
this route.

    ((cd old-repo && cg-diff -r from) | patch -p1) && cg-commit

or any equivalent.  Why should I have to muck with patch and diff, when
I can have a 'pull-as-one' operation.  Sure, it's a wrapper, but if its
the intended mode of development, let's make it a first-class citizen.

Personally, from my POV it is the intended mode of development only if
you keep strictly topical branches (a single logical change and fixes of
it on top of that). Otherwise, this is horrid because it loses the
_precious_ history and bundles us different changes to a single commit,
which is one of the thing that are wrong on CVS/SVN merging.

That said, with a big warning, I would be willing to do something like
cg-merge -s and cg-update -s (s as squash), with a big warning that this
is suitable only for topical branches. And I think it'd be still much
better to spend the work making StGIT able to track history of changes
to a particular patch.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

On Tue, Nov 01, 2005 at 10:15:33AM +0100, Petr Baudis wrote:

Personally, from my POV it is the intended mode of development only if
you keep strictly topical branches (a single logical change and fixes of
it on top of that). Otherwise, this is horrid because it loses the
_precious_ history and bundles us different changes to a single commit,
which is one of the thing that are wrong on CVS/SVN merging.

	Here we have the "precious" history vs the "throwaway" history
argument again.  You are correct, this does look like CVS/Subversion
merging.  But I'm quite capable of keeping my patches single-topic.
Anything that requires multiple patches in a logical separation still
needs that extra love.

That said, with a big warning, I would be willing to do something like
cg-merge -s and cg-update -s (s as squash), with a big warning that this

	Wouldn't it be cg-pull?  I guess I'm not conversant enough of
all ways to merge branches in cogito.

is suitable only for topical branches. And I think it'd be still much
better to spend the work making StGIT able to track history of changes
to a particular patch.

	I like quilt for certain work, and what I read from you and
Caitlin makes me interested in StGIT for those large changes that
require split-out patches.  But for simple tasks, I just want to use the
SCM, you know?

Joel

-- 

"The cynics are right nine times out of ten."  
        - H. L. Mencken

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Dear diary, on Tue, Nov 01, 2005 at 05:17:30PM CET, I got a letter
where Joel Becker [off-list ref] told me that...

On Tue, Nov 01, 2005 at 10:15:33AM +0100, Petr Baudis wrote:

quoted

Personally, from my POV it is the intended mode of development only if
you keep strictly topical branches (a single logical change and fixes of
it on top of that). Otherwise, this is horrid because it loses the
_precious_ history and bundles us different changes to a single commit,
which is one of the thing that are wrong on CVS/SVN merging.

	Here we have the "precious" history vs the "throwaway" history
argument again.  You are correct, this does look like CVS/Subversion
merging.  But I'm quite capable of keeping my patches single-topic.
Anything that requires multiple patches in a logical separation still
needs that extra love.

Well, ok, so I assume you are indeed using strictly topical branches.
.

quoted

That said, with a big warning, I would be willing to do something like
cg-merge -s and cg-update -s (s as squash), with a big warning that this

	Wouldn't it be cg-pull?  I guess I'm not conversant enough of
all ways to merge branches in cogito.

cg-pull just fetches stuff, no merging done.

Ok, in theory you do not actually need to fetch the intermediate history
in case you are going to squash (unless you are going to default the
final commit message to concatenation of the intermediate ones), but
arranging that would not be easy to arrange with the current git tools,
I think. And neither feasible. But actually, I would like to do
something like this later, support for CVS/SVN-like tracking by always
having only the latest tree and no intermediate states, so that people
who just want to run the latest and want to do no development are not
forced to download anything useless for them.

quoted

is suitable only for topical branches. And I think it'd be still much
better to spend the work making StGIT able to track history of changes
to a particular patch.

	I like quilt for certain work, and what I read from you and
Caitlin makes me interested in StGIT for those large changes that
require split-out patches.  But for simple tasks, I just want to use the
SCM, you know?

Well, if you are already going to deform the history, StGIT (able to
track patch history) is just the best tool for that.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Dear diary, on Tue, Nov 01, 2005 at 10:15:33AM CET, I got a letter
where Petr Baudis [off-list ref] told me that...

That said, with a big warning, I would be willing to do something like
cg-merge -s and cg-update -s (s as squash), with a big warning that this
is suitable only for topical branches. And I think it'd be still much
better to spend the work making StGIT able to track history of changes
to a particular patch.

FWIW, cg-merge -s and cg-update -s is supported now.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

On Monday 07 November 2005 23:56, Petr Baudis wrote:

Dear diary, on Tue, Nov 01, 2005 at 10:15:33AM CET, I got a letter
where Petr Baudis [off-list ref] told me that...

quoted

That said, with a big warning, I would be willing to do something like
cg-merge -s and cg-update -s (s as squash)

...
FWIW, cg-merge -s and cg-update -s is supported now.

The -s option of git merge is about choosing a strategy.
How can I choose the "recursive" strategy with cg-merge?
Some consistency would be good here.

Josef

Dear diary, on Tue, Nov 08, 2005 at 11:50:10AM CET, I got a letter
where Josef Weidendorfer [off-list ref] told me that...

On Monday 07 November 2005 23:56, Petr Baudis wrote:

quoted

Dear diary, on Tue, Nov 01, 2005 at 10:15:33AM CET, I got a letter
where Petr Baudis [off-list ref] told me that...

quoted

That said, with a big warning, I would be willing to do something like
cg-merge -s and cg-update -s (s as squash)

...
FWIW, cg-merge -s and cg-update -s is supported now.

The -s option of git merge is about choosing a strategy.
How can I choose the "recursive" strategy with cg-merge?
Some consistency would be good here.

Good point. You can't now, but you should be able to in the future.
I renamed this from -s to --squash.

Thanks,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.