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 <dustin@spy.net>
| 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. ____________
