Re: git: uh-oh - Mailing list pgsql-hackers

On Wed, Aug 18, 2010 at 12:18 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> Tom Lane wrote:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>> The "exclusive" possibility is to ignore the fact that some of the
>>> content of B4 came from trunk and to pretend that FILE1 just appeared
>>> out of nowhere in commit B4 independent of the FILE1 in TRUNK:
>>
>>> T0 -- T1 -- T2 -------- T3 -- T4        TRUNK
>>>        \
>>>         B1 -- B2 -- B3 -- B4            BRANCH1
>>
>>> This is also wrong, because it doesn't reflect the true lineage of FILE1.
>>
>> Maybe not, but that *is* how things appeared in the CVS history, [...]
>
> I forgot to point out that "the CVS history" looks nothing like this,
> because the CVS history is only defined file by file.  So the CVS
> history of FILE0 might look like this:
>
>  1.0 - 1.1 ------ 1.2 ----------------- 1.3 ----- 1.4        TRUNK
>        \
>         1.1.2.1 -- 1.1.2.2 -- 1.1.2.3 -- 1.1.2.4            BRANCH1
>
> whereas the history of FILE1 probably looks more like this:
>
>                  1.1 ----------------- 1.2 ----- 1.3        TRUNK
>                                         \
>                                          1.2.2.1 -- 1.2.2.2 BRANCH1
>
> (here I've tried to put corresponding commits in the same relative
> location) and there might be a FILE2 that looks like this:
>
>  1.0 ------------ 1.1 --------------------------- 1.2        TRUNK
>                   \
>                    *no commit here*                         BRANCH1
>
> Perhaps this makes it clearer why creating a single git history requires
> some compromises.

I think we all understand that the conversion process may create some
artifacts.  Also, since I think this has not yet been mentioned, I
really appreciate you being willing to jump into this discussion and
possibly try to write some code to help us get what we want.

I think what is frustrating is that we have a mental image of what the
history looks like in CVS based on what we actually do, and it doesn't
look anything like the history that cvs2git created.  You can to all
kinds of crazy things in CVS, like tag the whole tree and then move
the tags on half a dozen individual files forward or backward in time,
or delete the tags off them altogether.  But we believe (perhaps
naively) that we haven't done those things, so we're expecting to get
a simple linear history without merges, and definitely without commits
from one branch jumping into the midst of other branches.  What was
really alarming to me about what I found yesterday is that - even
after reading your explanation - I can't understand why it did that.
I think it's human nature to like it when good things happen to us and
to dislike it when bad things happen to us, but we tend to hate the
bad things a lot more when we feel like we didn't deserve it.  If
you're going 90 MPH and get a speeding ticket, you may be steamed, but
at some level you know you deserved it.  If you were going 50 MPH on a
road where the speed limit is 55 MPH and the cop tickets you for 60
MPH, even the most mild-mannered driver may feel an urge to say
something less polite than "thank you, officer".  Hence our
consternation.  Perhaps there is some way to tilt your head so that
these merge commits are the Right Thing To Do, but to me at least it
feels extremely weird and inexplicable.  If at some point, we had
taken the majority of the deltas between 9.0 and 8.3 and put them into
8.3 and the converter said "oh, that's a merge", well, we might want
an option to turn that behavior off, but at least it would be clear
why it happened.  But the merge commit that got fabricated here almost
by definition has to be ignoring the vast bulk of the activity on one
side, which just doesn't feel right.

To what degree does your proposed solution (an "exclusive" option)
resemble "don't ever create merge commits"?

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