Hi,
Quoting "Marko Kreen" <markokr@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