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
