On (09/05/14 22:21), Nikolai Kondrashov wrote:
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 :)
It is not about team, It is about open source and
contribution.
You can do the same mistake in another project.
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 already wrote, It was bad assumption. The script cabe perfect and convert
100% of messages on one branch, but there can be problems with older branches.
Older branches are(can be) very diverged. TThe fixup part needn't be available
in older branch and script can cause problem with totaly different debug
messages.
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.
I cannot see a reason why they should be squased explicitly and before
pushing.
You should have done it before sending patches.
We aren't used to modifying patches before pushing.
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 :)
Agree.
LS