Re: PostgreSQL Developer meeting minutes up

Поиск
Список
Период
Сортировка
От Markus Wanner
Тема Re: PostgreSQL Developer meeting minutes up
Дата
Msg-id 20090602174630.15801asig06rqjpy@mail.bluegap.ch
обсуждение исходный текст
Ответ на Re: PostgreSQL Developer meeting minutes up  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

Quoting "Tom Lane" <tgl@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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: PostgreSQL Developer meeting minutes up
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Managing multiple branches in git