[MPlayer-dev-eng] [PATCH] GUI: Corrections for display of video size and track number, playlist

[Ingo Brückl]

Reimar Döffinger wrote on Fri, 30 Nov 2012 09:19:45 +0100:

> On 30 Nov 2012, at 09:07, Ingo Brückl <ib at wupperonline.de> wrote:

>> Hans-Dieter Kosch wrote on Fri, 30 Nov 2012 03:09:14 +0100:
>>
>>> Reimar Döffinger wrote:
>>>> On Thu, Nov 29, 2012 at 01:54:47AM +0100, Hans-Dieter Kosch wrote:
>>>>> The reason for I did it in one step is that I do 'svn diff' against
>>>>> the latest SVN revision. If I split it, and one diff is treated, the
>>>>> line numbers in the next diff are incorrect.
>>>>
>>>> Note that incorrect line numbers are not a problem (one of the reasons
>>>> for using unified diff format), as long as that is all.
>>
>>> Yes, I know. The 'patch' program handles huge line deviations as long as
>>> enough context is provided (and a human can handle even more). But it
>>> seems inconvenient to me for human reading.
>>
>> This is exactly why patches covering only one issue a time are preferred.

> But (slightly) wrong line numbers are not a problem for readability?
> Or do you think they are?

No, not at all.

> I split patches manually all the time and never cared about not-quite-right
> line numbers.

Me neither.

Maybe I've answered two times with a different focus in mind. I didn't refer
to line numbers (the @@ stuff?), but to context (the three additional lines
before and after the patch).

I think that Hans-Dieter's main problem is that you cannot easily collect a
patch series (or a number of patches) with svn and test it step by step if
you cannot commit intermittently. If there are several issues in the same
file(s) you can only copy the file(s) to get successive patches afterwards.

With my answers to this subject, I wanted to express that one-issue-a-time
patches help preserving both context and readability as well as they can help
with the svn patch series problem (as long as they affect different files)
while big patches (unless committed) are blocking (i.e. changing the context
for) small, new ones.

That's all with pure svn, of course, and why git was invented.

Ingo