Hi,
Quoting "Marko Kreen" <mark...@gmail.com>:
Sorry, not going there. Just look at the state of VCS systems
that have prioritized academic issues insead of practicality...
(arch/darcs/monotone/etc..)
I already am there. And I don't want to go back, thanks. But my bias
for monotone certainly shines through, yes ;-)
--no-cross-branch-commits seems sort of that direction?
Yes, that could lead to the same defect. Uhm.. thank you for pointing
that out, I'm not gonna try it, sorry.
And what silly side effects are you talking about?
I'm talking about spurious file duplicates popping up after a rename
and a merge, see my example in this thread.
You consider it a mess, I consider it a better and more valid
representation of the mess that CVS is.
Note that merge is no file-level but tree level.
Depends on your point of view. Each file gets merged pretty
indivitually, but the result ends up in a single commit, yes.
Also note we don't
use branches for feature developement but for major version maintenance.
So? You think you are never going to merge?
So how can single file appearing in 2 branches means merge of 2 trees?
How can that be valid?
I'm not sure what you are questioning here.
I find it perfectly reasonable to build something on top of
REL8_3_STABLE and later on wanting to merge to REL8_4_STABLE. And I
don't want to manually merge my changes, just because of a rename in
8.4 and a bad decision during the migration to git.
(And no, I don't think any of the other git tools will help with this,
due to the academic-nitpick-reasons above).
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
