Re: git: uh-oh

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: git: uh-oh
Дата
Msg-id AANLkTikTGqJ=RN_56w-bck=654X2US+bSFkCNw7trSKF@mail.gmail.com
обсуждение исходный текст
Ответ на Re: git: uh-oh  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: git: uh-oh  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Aug 17, 2010 at 3:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I lack git-fu pretty completely, but I do have the CVS logs ;-).
> It looks like some of these commits that are being ascribed to the
> REL8_3_STABLE branch were actually only committed on HEAD.  For
> instance my commit in contrib/xml2 on 28 Feb 2010 21:31:57 was
> only in HEAD.  It was back-patched a few hours later (1 Mar 3:41),
> and that's also shown here, but the HEAD commit shouldn't be.

It looks to me like the commit I referenced in my original email is a
manufactured merge commit that completely rewrites the tree while
asserting that it doesn't do any such thing.

> I wonder whether the repository is completely OK and the problem
> is that this webpage isn't filtering the commits correctly.

No.  The repository itself has the same problem, or at least my clone
of it does.  I have to say I am totally underwhelmed by the quality of
the CVS-to-git conversion tools I've seen so far.  It's fine for Linus
to say that CVS will eat your data, but these tools were evidently
written with grossly inadequate error and sanity checks.  Whatever
we've been using for the incremental conversions doesn't seem to think
it's a problem if the new commit it's pushing doesn't make the head of
the tree match CVS HEAD, which seeems like a pretty darn obvious thing
to check for, and this tool evidently can't follow branch history
properly.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


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

Предыдущее
От: David Christensen
Дата:
Сообщение: Re: git: uh-oh
Следующее
От: Aidan Van Dyk
Дата:
Сообщение: Re: git: uh-oh