> The author of "[PATCH] (1/?) Fix “invalid read” valgrind errors" has
> admitted that this patch is not correct, so it should not be included.

Have I? It is correct, but it does not fix all errors.

> "[PATCH] (15/?) More possible memory leak fixes and error checking"
> creates the new macro DICTKEY_CHECK_EMPTY that is removed afterwards
> by "[PATCH] (28/?) Remove some possible memory leaks", so patch 15
> should not be included as well.

DICTKEY_CHECK_EMPTY is not the only thing that was changed in that patch.

> You seem to imply in your answer to my patch review, that in order to
> review one of your patch, one should read all the (not yet accepted)
> patches following this patch. So there are patches that fix patches
> that fix patches in the python interface :-(

One cannot write complicated code without bugs. If Bram used mercurial not only 
as a replacement for a ftp with patches it would be better: then all this 
sequence would be just one merge commit with all the history kept.

> This constraint makes any
> patch review useless, since you can never be sure that the review you
> are doing is not overriden by one of your batch of patches submitted
> the next day.

Here I tried to have “patches patching patches” as a reply to original one. 
This does not apply for generic (== fixing problems in existing functions) bug 
fixing patches though. It appears though that (27/?) should be (22.5/?).



I know that what I have in this thread is not the perfect example of the pull 
request. Given the need of sending PR as a series of patches what would you 
suggest to have here assuming you want both keep history (and probably exclude 
some of the patches) and possibility to fix problems?

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Raspunde prin e-mail lui