On 05/05/2014 10:36 PM, Lukas Slebodnik wrote:
On (01/05/14 00:51), Nikolai Kondrashov wrote:
> One thing, though: having the script-generated patches separate certainly made
> cherry-picking easier and faster.
>
The patches were pushed, so we can continue with this discussion.
The only way how to make chery-picking easier is to have better merging
algorithm in version control syste. The script generated patches solve problem
with back porting changes to diverged branches.
I am not against script generated patches. I like scripting, it simplifies my
life. My idea was to have script which will fix(convert) 99% of cases and
the last 1% of corner cases can be solved easily by hand.
Sometimes it is easier to fix the last 1% of problems by hand rather than
spending days with creating a robust conversion script. But the main point is
to include hand made changes to the generated patch and not to the separate
patch. With this approach work is simplified with script and we don't lost
benefit "every patch builds"
The reason why I would sacrifice the "every patch builds" rule, originally,
was to simplify backporting to older branches, which would likely be
different and thus simply cherry-picking the monolithic (scripted+manual
changes) commit would not be possible to do with confidence, and re-running
the script would be necessary (which I did with this backport).
In that case, my idea was, keeping manual changes separate would allow us to
simply cherry-pick them, without having to extract them from the monolithic
commit by hand or to do them again.
However, now I realize that we could have simply ran the script on the commit
before the original and made a diff to extract manual changes, which we could
have then applied on the older tree, after running the script there.
So, yes, it is possible to have "every patch builds" and also to backport
scripted+manual patches reliably. The script in question would better be
included with such commits, though.
Sincerely,
Nick