Re: PostgreSQL Developer meeting minutes up

Hi,

Quoting "Aidan Van Dyk" <aidan(at)highrise(dot)ca>:
> Sure, and we can all construct example where that move is both right and
> wrong...

Huh? The problem is the file duplication. The move is an action of a
committer - it's neither right nor wrong in this example.

I cannot see any use case for seemingly random files poping up out of
nowhere, just because git doesn't know how to merge two files after a
mv and a merge.

> But the point is that in PostgreSQL, (and that may be mainly
> because we're using CVS), merges *aren't* something that happens.
> Patches are written against HEAD (master) and then back-patched...

..which can (and better is) represented as a merge in git (for the
sake of comfortable automated merging).

> If you want to turn PostgreSQL devellopment on it's head, then we can
> switch this around, so that patches are always done on the oldest
> branch, and fixes always merged "forward"...

I'd consider that good use of tools, yes. However, I realize that this
probably is pipe-dreaming...

> But the fact is, everyone using CVS wants a "linear history"..... All
> they care about is "cvs update...wait...cvs update ... time ... cvs
> update ..."... Everything *was* linear to them. Any "merge" type things
> certaily wasn't intentional in CVS...

..no, it just wasn't possible in CVS. Switching to git, people soon
want "merge type things". Heck, it's probably *the* reason for
switching to git.

> So much better that it makes the history as useless as CVS... I think
> one of the reasons people are wanting tomove from CVS to git is that it
> makes things *better*...

Yes, especially merging. Please don't cripple that ability just
because CVS once upon a time enforced a linear history.

> The "exact" history will *always* be
> available, right in CVS if people need it.

Agreed. Please note that I mostly talk about a more correct
representation *of history*, as it happened. This has nothing to do
with single commits per file.

> It's a balance... We're moving because we want *better* tools and
> access, not the same "mess that CVS is".

Agreed. And please cut as many of its burdens of the past, like
linearity. History is not linear and has never been. But I'm stopping
now before getting overly philosophic...

Regards

Markus Wanner