On 19.01.2012 15:38, Julian Foad wrote:
> Branko Čibej wrote:
>
>> Instead of trying to invent ways to not make current reintegrate suck
>> rocks, I'd suggest taking a look at how other tools handle such repeated
>> merges between branches. Specifically, since git afficionados have so
>> much to say about how good merging in git is, especially compared to
>> Subversion, I'd be really interested to see if -- when you get down to
>> cases -- it can actually do anything that analyzing the diff3 results
>> (or, more likely, using diff4) can't already do.
> I have to ask, are you writing from a point of view of having a mental model in which simply analyzing diffs *could* achieve the requisite tracking results? Because I can't begin to see how.
No, I'm just trying to wrap my head around the concept of --reintegrate
in the first place. :)
What I mean is, no other tool I've ever used -- and I include CVS with
all its problems in this list -- has had or needed this concept. So I
must assume that something must be fundamentally wrong with our model of
merge tracking if we ended up having to add --reintegrate. I really
don't know /what/ could be wrong, but comparing what svn does to what
others do (I pushed git as an example because of its vocal proponents,
of course) might give a hint.
I grant it could turn out that there's nothing really wrong with the
model and that --reintegrate simply masks implementation problems that
you're tackling on a more fundamental level now.
-- Brane
Received on 2012-01-19 20:12:12 CET