* Magnus Hagander <magnus@hagander.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@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
