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