Dustin Sallings wrote:
> 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.
The difference here is that instead of submitting a patch for review,
which is then frozen, the branch owner can (and that means some will, no
matter what your intentions are) keep modifying the branch during the
review process, other than just keeping it in sync with conflicting
changes to the trunk. How do you plan to prevent that?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
