Hi,
Quoting "Tom Lane" <t...@sss.pgh.pa.us>:
FWIW, the tool that I customarily use (cvs2cl) considers commits on
different branches to be "the same" if they have the same commit message
and occur sufficiently close together (within a few minutes). My
committing habits have been designed around that behavior for years,
and I believe other PG committers have been doing likewise.
Yeah, that's how I see things as well.
I would consider a git conversion to be less useful to me, not more,
if it insists on showing me such cases as separate commits --- and if
it then adds useless "merge" messages on top of that, I'd start to get
seriously annoyed.
Hm.. well, in git, there's no such thing as a commit that spans
multiple branches. So it's impossible to fulfill both of your wishes
here.
parsecvs creates multiple independent commits in such a case.
cvs2git creates a single commit and propagates this to the back
branches with merge commits (however, only if new files are added,
otherwise it does the same as parsecvs).
What we want here is a readable equivalent of the CVS history, not
necessarily something that is theoretically an exact equivalent.
Understood. However, readability depends on the user's habits. But
failing to merge due to a lacking conversion potentially hurts
everybody who wants to merge.
Having used merging (in combination with renaming) often enough, I'd
certainly be pretty annoyed if merges suddenly begin to bring up
spurious file duplicates.
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
