From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Greg Stark <stark(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Markus Wanner <markus(at)bluegap(dot)ch>, Marko Kreen <markokr(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL Developer meeting minutes up |
Date: | 2009-06-03 14:36:22 |
Message-ID: | 20090603143622.GL23972@yugib.highrise.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Magnus Hagander <magnus(at)hagander(dot)net> [090603 10:13]:
>
> Right, if it adds additional metadata that lets the tools do their magic
> better, and it's still easy to filter out, I don't see a downside.
Note, that it could (and likely will) have a downside when you get to
doing real merge-based development... A "merge" means that *all* changes
in *both* parents have been combined in *this* commit. And all merge
tools depend on this. That's the directed part of the "DAG" in git. So
if you want to be working in a way that the merge tools work, you
*don't* have master/HEAD merged into REL8_2_STABLE. You can have
REL8_2_STABLE merged into master/head.
I'll concede that in GIT, it's flexible (some say arbitrary) enough that
you can *construct* the DAG otherwise, but then you've done something in
such a fashion that the DAG has no bearing on "real merging", and thus
you loose all the power of DAGs "merge tracking" when working on new
real merging....
a.
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
From | Date | Subject | |
---|---|---|---|
Next Message | Aidan Van Dyk | 2009-06-03 14:38:31 | Re: PostgreSQL Developer meeting minutes up |
Previous Message | Ron Mayer | 2009-06-03 14:33:48 | Re: Managing multiple branches in git |