Hi,

Quoting "Aidan Van Dyk" <ai...@highrise.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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to