On 05/09/2014 10:00 PM, Lukas Slebodnik wrote:
On (09/05/14 15:09), Nikolai Kondrashov wrote:
> 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.
>
It was very bad assumption that patch which changed 215 files
( 7825 insertions, 7825 deletions) would be possible to cherry-pick
to older branch without any problem. This is a reason why script was written.
Sure. There is some misunderstanding going on, apparently.
I didn't make the assumption that we can just cherry-pick a huge
script-generated commit, and it was me who wrote that script, partly to avoid
that, before I joined the team :)
I'm just saying that, of course, I would have to re-run the script on the
older branch and then I would have to fix up whatever the script missed.
However, my original assumption was that if we have a monolithic commit with
scripted+manual changes, it wouldn't be easy to extract the fixup part from
it and I would have to redo it by hand on the older branch.
As I say in the previous message, I now realize extracting the fixup part
would be possible, provided the script works the same way.
> 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.
The script was included in commit message.
Sure, I put it there. I merely state a requirement for such system to work.
At least, you learnt something new and will not do the same mistake
in
future.
I wouldn't say it was learning, rather realizing there is a way.
Once again, I support "every commit builds" idea. I'm implementing CI to
make
that achievable, actually.
Neither it was my mistake much. I urged the maintainers to squash commits as
necessary and supported squashing manual changes into the scripted ones
explicitly. They didn't, probably to speed up the push and I decided to go
along the same way when backporting to make things simpler to track and
review.
I should probably stop defending myself now :)
Sincerely,
Nick