LCA2006 Git/Cogito tutorial

LCA2006 Git/Cogito tutorial

[Martin Langhoff (CatalystIT)]

Good news! Sounds like I will be hosting a Git/Cogito tutorial in the
upcoming LCA2006 (Dunedin, NZ, Jan 25~28). Given that I do have some
significant holes in my git knowledge (no, really!?) I'll be happy if
other git hackers/users are present at LCA and willing to take part in
the tutorial.

Petr Baudis hinted earlier that he might be coming, as did Linus (but
he was hoping for a sponsor, I'm not sure whether he'll be there or
not). Speak up if you'll be there!

I'll post my slides and presentation plan beforehand to the list, to
avoid spreading misinfirmation/bad practices. They will probably be
based on a recent talk I gave @ Wellington Perl Mongers about
swtiching to Git/Cogito:

    http://wellington.pm.org/archive/200510/git/

The feedback (from both non-cogito-users and actual cogito-users) was
that I made it sound too complicated, so the current plan is to focus
on the tutorial part, and leave "under the hood" parts for a rainy day
or for an after tutorial in-the-corridor chat.

cheers,


martin
ps: lately, about 30% of my emails to git@vger from gmail have been 
dropped on the floor. This is starting to get annoying, is anyone seeing 
similar issues?
-- 
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ  Ltd, PO Box 11-053, Manners St,  Wellington
WEB: http://catalyst.net.nz/           PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224                              MOB: +64(21)364-017
       Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------

Re: LCA2006 Git/Cogito tutorial

[Petr Baudis]

Dear diary, on Mon, Oct 17, 2005 at 02:48:09AM CEST, I got a letter
where "Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> told me that...
> Petr Baudis hinted earlier that he might be coming, as did Linus (but
> he was hoping for a sponsor, I'm not sure whether he'll be there or
> not). Speak up if you'll be there!

I'm sorry but I will not be there - it is too far away from my little
country. :-(

> I'll post my slides and presentation plan beforehand to the list, to
> avoid spreading misinfirmation/bad practices. They will probably be
> based on a recent talk I gave @ Wellington Perl Mongers about
> swtiching to Git/Cogito:
> 
>    http://wellington.pm.org/archive/200510/git/

(i) You might want to say "cg-export" instead of "git-tar-tree" (*shrug*)

(ii) You say:

	- Very fast stupid merge
	    ... and very smart, slow merges when stupid won't do

  What are you explicitly referring to? I don't think any kind of merge
in GIT (unless something totally missed me) can be called "very smart".
If it's a three-way merge, it's never "very smart".

(iii) I have only one major problem with your file:

	emacs .gitignore

  This should be obviously:

	vim .gitignore

;-)

> ps: lately, about 30% of my emails to git@vger from gmail have been 
> dropped on the floor. This is starting to get annoying, is anyone seeing 
> similar issues?

Not me. Perhaps I'm in some VIP class. :^)

-- 
				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.

Re: LCA2006 Git/Cogito tutorial

[Dmitry Torokhov]

On Thursday 20 October 2005 19:51, Petr Baudis wrote:
> (ii) You say:
> 
>         - Very fast stupid merge
>             ... and very smart, slow merges when stupid won't do
> 

He might be referring to manual merge which is indeed as smart as it gets :)

-- 
Dmitry

Re: LCA2006 Git/Cogito tutorial

[Martin Langhoff (CatalystIT)]

Dmitry Torokhov wrote:
> On Thursday 20 October 2005 19:51, Petr Baudis wrote:
> 
>>(ii) You say:
>>
>>        - Very fast stupid merge
>>            ... and very smart, slow merges when stupid won't do
> 
> He might be referring to manual merge which is indeed as smart as it gets :)

Almost. No, truly, I'm very impressed with git-merge.sh, which first 
does the simple git-read-tree -m, and it can then try several merger 
scripts to resolve the index. The "smartest" merge resolver we have 
follows renames, but we could have language-specific and 
project-specific resolvers, for instance.

If you combine the coolness of git-merge.sh with the fact that cg-merge 
right now is buggy[*]... I'm starting to rely on doing cg-fetch and 
running git-merge.sh by hand.

* I just merged your latest fixes, knowing that they'd conflict on 
cg-fetch, but the merge didn't say a thing a bout cg-fetch, and only 
complained like this:

    MERGE ERROR: : Not handling case  ->  ->

But there were no conflicts at all in the tree! It seems to be that it's 
dropping the upstream changes it doesn't like.

cheers,


martin
-- 
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ  Ltd, PO Box 11-053, Manners St,  Wellington
WEB: http://catalyst.net.nz/           PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224                              MOB: +64(21)364-017
       Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------

Re: LCA2006 Git/Cogito tutorial

[Martin Langhoff (CatalystIT)]

Petr Baudis wrote:

> Dear diary, on Mon, Oct 17, 2005 at 02:48:09AM CEST, I got a letter
> where "Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> told me that...
> 
>>Petr Baudis hinted earlier that he might be coming, as did Linus (but
>>he was hoping for a sponsor, I'm not sure whether he'll be there or
>>not). Speak up if you'll be there!
> 
> 
> I'm sorry but I will not be there - it is too far away from my little
> country. :-(

Sad to hear that. I'll be soon in Europe, though, but not in CZ, 
unfortunately!

> (i) You might want to say "cg-export" instead of "git-tar-tree" (*shrug*)

You're right! I hadn't seen that.

> (ii) You say:
> 
> 	- Very fast stupid merge
> 	    ... and very smart, slow merges when stupid won't do
> 
>   What are you explicitly referring to? I don't think any kind of merge
> in GIT (unless something totally missed me) can be called "very smart".
> If it's a three-way merge, it's never "very smart".

See latest developments on git-merge.sh -- we should really revamp 
cg-merge ;)

> 	vim .gitignore

Then it'd be a bug, not a feature ;)

>>ps: lately, about 30% of my emails to git@vger from gmail have been 
>>dropped on the floor. This is starting to get annoying, is anyone seeing 
>>similar issues?
> 
> 
> Not me. Perhaps I'm in some VIP class. :^)

Oh, I figured that out! Gmail's "utf-8" mode encodes everything in 
base64. Awful sh*t. Reverted to ascii and life is good.



martin
-- 
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ  Ltd, PO Box 11-053, Manners St,  Wellington
WEB: http://catalyst.net.nz/           PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224                              MOB: +64(21)364-017
       Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------

Re: LCA2006 Git/Cogito tutorial

[Petr Baudis]

Dear diary, on Fri, Oct 21, 2005 at 04:59:06AM CEST, I got a letter
where "Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> told me that...
> Almost. No, truly, I'm very impressed with git-merge.sh, which first 
> does the simple git-read-tree -m, and it can then try several merger 
> scripts to resolve the index. The "smartest" merge resolver we have 
> follows renames, but we could have language-specific and 
> project-specific resolvers, for instance.

Yes, following renames is nice. But as long as it is three-way, it
suffers of inherent and rather nasty problems. Well, I'm watching the
weave merge effort and plan to give it a try to port it to GIT when I
have some time.

> If you combine the coolness of git-merge.sh with the fact that cg-merge 
> right now is buggy[*]... I'm starting to rely on doing cg-fetch and 
> running git-merge.sh by hand.
> 
> * I just merged your latest fixes, knowing that they'd conflict on 
> cg-fetch, but the merge didn't say a thing a bout cg-fetch, and only 
> complained like this:
> 
>    MERGE ERROR: : Not handling case  ->  ->
> 
> But there were no conflicts at all in the tree! It seems to be that it's 
> dropping the upstream changes it doesn't like.

There was a bug in argument parsing of cg-Xmergefile, already fixed now.

Well, it's true that cg-Xmergefile still does not handle all merge
cases, but it certainly will not be silent about it, at least. ;-)

-- 
				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.

Re: LCA2006 Git/Cogito tutorial

[Horst von Brand]

Martin Langhoff (CatalystIT) <martin@catalyst.net.nz> wrote:

[...]

> If you combine the coolness of git-merge.sh with the fact that
> cg-merge right now is buggy[*]... I'm starting to rely on doing
> cg-fetch and running git-merge.sh by hand.
> 
> * I just merged your latest fixes, knowing that they'd conflict on
> * cg-fetch, but the merge didn't say a thing a bout cg-fetch, and only
> * complained like this:
> 
>     MERGE ERROR: : Not handling case  ->  ->
> 
> But there were no conflicts at all in the tree! It seems to be that
> it's dropping the upstream changes it doesn't like.

It happens when a new file with the same name appears in both parents. For
example, we both see the need for a README file, and then I pull from you
and try to merge into my version.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: LCA2006 Git/Cogito tutorial

[Horst von Brand]

Petr Baudis <pasky@suse.cz> wrote:

[...]

> Well, it's true that cg-Xmergefile still does not handle all merge
> cases, but it certainly will not be silent about it, at least. ;-)

The Codeville <http://www.codeville.org> people seem to have taken a hard
look at merging, but I don't find any clear references to their algorithm.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: LCA2006 Git/Cogito tutorial

[Petr Baudis]

Dear diary, on Sun, Oct 23, 2005 at 05:35:53PM CEST, I got a letter
where Horst von Brand <vonbrand@inf.utfsm.cl> told me that...
> Petr Baudis <pasky@suse.cz> wrote:
> 
> [...]
> 
> > Well, it's true that cg-Xmergefile still does not handle all merge
> > cases, but it certainly will not be silent about it, at least. ;-)
> 
> The Codeville <http://www.codeville.org> people seem to have taken a hard
> look at merging, but I don't find any clear references to their algorithm.

They are working on something much more general, basically abandoning
the three-level (RCS-like) merging model altogether and going for the
weave (SCCS-like) merging model instead. See also

	http://revctrl.org/PreciseCodevilleMerge

and short crawling around the wiki and external links should give you
pretty good idea (see especially SimpleWeaveMerge).

-- 
				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.

Re: LCA2006 Git/Cogito tutorial

[Petr Baudis]

Dear diary, on Sun, Oct 23, 2005 at 05:33:43PM CEST, I got a letter
where Horst von Brand <vonbrand@inf.utfsm.cl> told me that...
> Martin Langhoff (CatalystIT) <martin@catalyst.net.nz> wrote:
> [...]
> >     MERGE ERROR: : Not handling case  ->  ->
> 
> It happens when a new file with the same name appears in both parents. For
> example, we both see the need for a README file, and then I pull from you
> and try to merge into my version.

It certainly shouldn't happen with precisely that error message - there
should be at least something written between the arrows. And yes, there
are unhandled cases like that, as I wrote in one of my other mails.

-- 
				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.

Re: LCA2006 Git/Cogito tutorial

[Horst von Brand]

Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sun, Oct 23, 2005 at 05:33:43PM CEST, I got a letter
> where Horst von Brand <vonbrand@inf.utfsm.cl> told me that...
> > Martin Langhoff (CatalystIT) <martin@catalyst.net.nz> wrote:
> > [...]
> > >     MERGE ERROR: : Not handling case  ->  ->

> > It happens when a new file with the same name appears in both parents. For
> > example, we both see the need for a README file, and then I pull from you
> > and try to merge into my version.

> It certainly shouldn't happen with precisely that error message - there
> should be at least something written between the arrows.

It does now.

>                                                          And yes, there
> are unhandled cases like that, as I wrote in one of my other mails.

Yep, thanks!
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: LCA2006 Git/Cogito tutorial

[Junio C Hamano]

"Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> writes:

>>>(ii) You say:
>>>
>>>        - Very fast stupid merge
>>>            ... and very smart, slow merges when stupid won't do
>
> Almost. No, truly, I'm very impressed with git-merge.sh, which first 
> does the simple git-read-tree -m, and it can then try several merger 
> scripts to resolve the index. The "smartest" merge resolver we have 
> follows renames, but we could have language-specific and 
> project-specific resolvers, for instance.

I should not be saying this because I am the primary guilty
party, but you should not be so impressed.

Being able to specify which merge strategy to use is a useful
thing, but I do not think being able to try more than one merge
strategies automatically, while it has some coolness value, is
very useful in practice.

The language-specific or project-specific part should be made
orthogonal to merge strategy modules, which currently is not.
The primary thing Daniel's git-merge-resolve and Fredrik's
git-merge-recursive do is to figure out which paths can be
resolved without merging the file contents, and which paths need
to be resolved with file contents merge, and they use different
strategies to find which 3 variants of the contents to use for
that final merge.

But at the end of the day, merging the contents is done by
running 'merge' in either case.  This should be made either
customizable, or we ship our standard one that can be extended
to first run 'file' to see the file content type of what is
being merged and run content specific merge program if there is
one.

Even if we did that, we are still doing 3-way merge; git-merge
framework may not mesh very well when we want to use something
like codeville merge which is not based on 3-way.

Re: LCA2006 Git/Cogito tutorial

[Linus Torvalds]

On Sun, 23 Oct 2005, Junio C Hamano wrote:
> 
> Even if we did that, we are still doing 3-way merge; git-merge
> framework may not mesh very well when we want to use something
> like codeville merge which is not based on 3-way.

Oh, the git merge is about a million times better than any silly weave 
merge with extra BonusPoints and MagicCapitalizedNames.

Why? Because if you want to be slow and careful, you can always just 
create the weave after-the-fact and do a weave merge.

And because well-behaved git merges as so fast, you can actually afford 
to so so.

There's nothing magic in a weave merge. It's just a trick. It doesn't need 
the files to be in weave format beforehand, even though people seem to 
believe that file formats go together with it.

If somebody thinks a weave merge is wonderful and fixes everything, I have 
to rain on their parade. You still need to manually fix real conflicts up, 
and regardless, what kind of merge you do has _nothing_ to do with how you 
maintain your files.

If you want to do a weave merge inside git, then the way to do that is to 
just create the weave on demand in the (rare) case where it's needed. We 
have all the history. You might even just do a "lazy weave", which just 
starts from the common parent, and ignores the history before that. 

Much cheaper that way, and arguably nicer (others will argue that you want 
to take history into account, to decide about undo's etc. It's a matter of 
taste). 

The thing is, automatic merging isn't all _that_ important. The thing that 
made BK wonderful at merging was that it had a wonderful tool for merging 
for when there were real clashes, which is where the _really_ nasty cases 
are. The actual automatic merge wasn't necessarily anything magical.

(Same went for applying diffs, btw. What made BK nice was "renametool". Of 
course, it was also what made me decide that tracking renames was the 
wrong thing to do in the first place, but if you make a CMS that does 
renames, you'd better have a "renametool").

And if you have a tool that helps you visually merge the _real_ clashes, 
it doesn't much matter if you are only half-way decent on the automatic 
ones. They'll be so trivial that nobody cares.

And it doesn't matter _how_ good your automatic merges are, there always 
_will_ be real clashes.

[ Side note. Think about this for a while. Git did three-way merges 
  pretty much since day one, but they only became _useful_ when we made it 
  easy to see the merge conflicts and fix them up. That's a fundamental
  lesson right there: you don't have to be perfect, you have to make it 
  easy for the user to fix up your imperfections. ]

So we should spend time on making it easy to see what the clash was, and 
on tools to help resolve them. Some random merge-strategy-of-the-day is 
just bling-bling. 

The reason people like merge strategies is that it's a nice area for some 
mental masturbation. You can create all these fancy examples. And then can 
ignore the fact that most real merge problems end up being two people 
changing the same code in different ways, that just need manual merging.

Don't get me wrong - if somebody does a nice automated merge for git, it's 
a good thing, but it's probably much more important to try to integrate 
something like xxdiff to a git workflow. And _that_ level is probably 
where you want to have special language-based coloring etc to further help 
things out.

So keep your eyes on the ball. And "automatic merge" isn't it.

		Linus

Re: LCA2006 Git/Cogito tutorial

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Sun, 23 Oct 2005, Junio C Hamano wrote:
>> 
>> Even if we did that, we are still doing 3-way merge; git-merge
>> framework may not mesh very well when we want to use something
>> like codeville merge which is not based on 3-way.
>
> Oh, the git merge is about a million times better than any silly weave 
> merge with extra BonusPoints and MagicCapitalizedNames.
>
> Why? Because if you want to be slow and careful, you can always just 
> create the weave after-the-fact and do a weave merge.

Yes, I know that as the one who did the convention between
git-merge and merge strategy backends.  The convention feeds two
(or more) heads and the common ancestors git-merge already
figured out to the strategy backends.

The current callers only feed commits for "$heads" parameters,
so the merge strategy backends are free to figure out the common
ancestor or even generate weave on the fly, but an unwritten
rule was that strategy backends are expected to do something
sensible even when the "common ancestors" and "heads" fed to
them are tree objects, which was my comment about 3-way was
about.

Re: LCA2006 Git/Cogito tutorial

[Linus Torvalds]

On Sun, 23 Oct 2005, Junio C Hamano wrote:
> 
> The current callers only feed commits for "$heads" parameters,
> so the merge strategy backends are free to figure out the common
> ancestor or even generate weave on the fly, but an unwritten
> rule was that strategy backends are expected to do something
> sensible even when the "common ancestors" and "heads" fed to
> them are tree objects, which was my comment about 3-way was
> about.

Ahh. Yes, if you use raw trees, you're screwed - you can only ever do a 
3-way merge, since you can't try to figure out any history.

I agree that the "tree only" case is interesting too - it's how you can 
merge trees that may be related content-wise but don't share a history (eg 
the same project maintained in separate source trees), and it's obviously 
how you can merge totally unrelated projects (eg the gitk merge). At the 
same time, I think that's a different kind of merge, in general. And we 
definitely shouldn't limit ourselves to things where such merges work.

Yes, tree-merges are wonderful, and they work really quite well, but I 
definitely want to keep the window open for merges that end up taking the 
full history into account.

I just don't think they are nearly as important as some people seem to 
think. They should be a very special and unusual case, rather than 
something you expect to happen.

		Linus

Re: LCA2006 Git/Cogito tutorial

[Martin Langhoff]

On 10/24/05, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sun, Oct 23, 2005 at 05:33:43PM CEST, I got a letter
> where Horst von Brand <vonbrand@inf.utfsm.cl> told me that...
> > Martin Langhoff (CatalystIT) <martin@catalyst.net.nz> wrote:
> > [...]
> > >     MERGE ERROR: : Not handling case  ->  ->
> >
> > It happens when a new file with the same name appears in both parents. For
> > example, we both see the need for a README file, and then I pull from you
> > and try to merge into my version.
>
> It certainly shouldn't happen with precisely that error message - there
> should be at least something written between the arrows. And yes, there
> are unhandled cases like that, as I wrote in one of my other mails.

As I painfully discovered later, I had updated my tree at the wrong
time, and got caught with a cg-Xmerge.sh that had lost all its
parameters over the numbered params/named params transition. I got a
fresh checkout, rebased my local patches, and life is good again.

Sorry about the noise!


martin

Re: LCA2006 Git/Cogito tutorial

[Petr Baudis]

Dear diary, on Mon, Oct 24, 2005 at 03:35:43AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> Oh, the git merge is about a million times better than any silly weave 
> merge with extra BonusPoints and MagicCapitalizedNames.
> 
> Why? Because if you want to be slow and careful, you can always just 
> create the weave after-the-fact and do a weave merge.

This doesn't make sense. Those silly weave merges only describe what to
do with the weave to do the merge, not how you got the weave in the
first place.

> So we should spend time on making it easy to see what the clash was, and 
> on tools to help resolve them. Some random merge-strategy-of-the-day is 
> just bling-bling. 

The *primary* reason for new merge strategies is not reducing number
of conflicts, but actually being able to force a conflict at places
where it isn't crystal-clear what the resolution should be (but not
conflicting where it should be clear), and especially at places where
the three-way merge *silently* gets it *wrong* without throwing any
conflicts. And weren't it you who wanted a conservative merge strategy
which wouldn't ever do 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.

Re: LCA2006 Git/Cogito tutorial

[Fredrik Kuivinen]

On Fri, Oct 21, 2005 at 11:15:51AM +0200, Petr Baudis wrote:
> Dear diary, on Fri, Oct 21, 2005 at 04:59:06AM CEST, I got a letter
> where "Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> told me that...
> > Almost. No, truly, I'm very impressed with git-merge.sh, which first 
> > does the simple git-read-tree -m, and it can then try several merger 
> > scripts to resolve the index. The "smartest" merge resolver we have 
> > follows renames, but we could have language-specific and 
> > project-specific resolvers, for instance.
> 
> Yes, following renames is nice. But as long as it is three-way, it
> suffers of inherent and rather nasty problems. Well, I'm watching the
> weave merge effort and plan to give it a try to port it to GIT when I
> have some time.
> 

Which "inherent and rather nasty problems" are you referring to?

I do not know of any merge case which is either cleanly merged to the
wrong result by git-merge -s recursive, or cleanly merged when it
should be a conflict. (At least not if there aren't any directory
renames going on) If you know about such an example I would be very
interested in taking a look at it.

- Fredrik

Re: LCA2006 Git/Cogito tutorial

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Dear diary, on Mon, Oct 24, 2005 at 03:35:43AM CEST, I got a letter
> where Linus Torvalds <torvalds@osdl.org> told me that...
>> Oh, the git merge is about a million times better than any silly weave 
>> merge with extra BonusPoints and MagicCapitalizedNames.
>> 
>> Why? Because if you want to be slow and careful, you can always just 
>> create the weave after-the-fact and do a weave merge.
>
> This doesn't make sense. Those silly weave merges only describe what to
> do with the weave to do the merge, not how you got the weave in the
> first place.

True, but it should not be a problem that is made harder for you
to solve by the fact that our repository is not based on weaves.

Unless an weave-based SCM comes with an integrated editor that
records line insertion and deletion user actions and forces
users to use that editor and nothing else, it also has to work
on two whole files (pre- and post-modification) in order to find
the matching lines and figure out the weave to record, on top of
the history before pre-modification image.  I think you have the
same information as they have to create the weave after the fact
for each commit in that sense.

Re: LCA2006 Git/Cogito tutorial

[Linus Torvalds]

On Mon, 24 Oct 2005, Petr Baudis wrote:
> > 
> > Why? Because if you want to be slow and careful, you can always just 
> > create the weave after-the-fact and do a weave merge.
> 
> This doesn't make sense. Those silly weave merges only describe what to
> do with the weave to do the merge, not how you got the weave in the
> first place.

Do you think a weave is something magical that happens because the SCM 
keeps the files as a weave?

No.

The weave is _not_ a "a priori" thing. The only primary thing is the 
history of the file contents. Even a weave-based system will always create 
the weave out of the history - it just happens to also save the file in 
that woven format.

So if you have the history, you can always just re-create the weave. It's 
not rocket science. SCCS has been around for how many decades now?

And the thing is, because git does NOT keep the files in weave format, it 
can do the _normal_ case of a merge (same contents, never mind how they 
get there) much faster than anything else. The same-file merges are so 
unusual as to be unimportant - if it then takes a bit longer to handle 
them because you want to use a weave, hey, you're still ahead.

> The *primary* reason for new merge strategies is not reducing number
> of conflicts, but actually being able to force a conflict at places
> where it isn't crystal-clear what the resolution should be (but not
> conflicting where it should be clear), and especially at places where
> the three-way merge *silently* gets it *wrong* without throwing any
> conflicts. And weren't it you who wanted a conservative merge strategy
> which wouldn't ever do that?

A three-way merge is plenty conservative for me.

Any merge will always get some case wrong, exactly the same way any merge 
will always get some that require fixing up, even if a human might say 
"that's a stupid merge". Two patches add the same thing to different 
places (an unsorted array of PCI ID's or whatever), and pretty much any 
merge ever will silently "mismerge" it as far as a human is concerned. 
From a _technical_ point it was correct. In practice, it wasn't.

So when I say "conservative", I don't mean "can never mis-merge", because 
such a thing doesn't exist. No, "conservative" means that it seldom does 
it in practice, and that when it happens, you can at least understand why 
it happened.

A simple strategy that makes people understand what happened is often much 
better than a more complex one. And you should never underestimate the 
importance of peoples _expectations_. A three-way merge has a _huge_ 
advantage in that absolutely tons of people are used to what it does: even 
when they don't necessarily "understand" the merge (they never cared), if 
they've worked with CVS they've seen them before.

Don't get me wrong - a weave merge is pretty damn conservative too. I'm 
not down on weave merges, I just don't think that the difference is that 
huge in practice - the difference between a three-way merge and a weave 
merge is much smaller than the advantage of a good graphical tool and a 
good workflow.

That's really my argument here: automated merges aren't the end-all. I 
realize that a lot of SCM people think that three-way merges are old and 
boring and stupid, but the fact is, sometimes the old ways aren't the best 
ways, but sometimes they are old just because they are good enough.

		Linus