On Mar 24, 2004, at 20:29, Tom Lane wrote:
Not here. You want me to trust some bit of code (with absolutely zero understanding of the source text it's hacking on) to figure out how to resolve conflicting patches? That sounds like a recipe for big-time unhappiness.
The idea is that it's the responsibility of the branch owner to keep it up-to-date. For example, I've got a branch of tla (an arch implementation) I made soon after I started using it in order to add a command I wanted and refactor a bit of the insides. Over time, a lot of stuff has changed, but I still want my stuff to work, so as I update my branch against head of line, I make minor changes to it as things go.
The difference is that instead of having a patch sitting in a queue somewhere suffering from bit-rot, you've got a pointer to a branch that you can merge when you get around to it. You can still view it as a diff if you want, but the diff you get six months after the original submission may be quite a bit different from what you would've got at the beginning if a lot of the code around it has changed.
It's definitely not a magic tool that makes bad code good and conflicting patches happy. It solves other problems, though. Many of the problems you don't realize you have until you go back to something else and try to do something simple like undo all of the changes you've made since your last checkin.
-- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <[EMAIL PROTECTED]> | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
