>>> 5) 2010-01-13 20:14 UTC+0100
>>> it doesn't apply because it must be applied to lines added by
>>> "2010-01-13 09:37 UTC+0100 Przemyslaw Czerpak" that was not marked as
>>> TOMERGE that added some similar lines in the same lines confusing the
>>> patch system. Should I MERGE it ?
>> 
>> This change is not marked as TOMERGE, so you shouldn't.
> 
> But 2010-01-13 20:14 UTC+0100 adds a line in function
> hb_hashGetCItemPtr() added in "2010-01-13 09:37".... or we add both or
> none...

In 2010-01-13 09:37, only one sub-change is marked as 
TOMERGE, the file harbour/contrib/hbclipsm/environ.c.

>> Thank you. My only comment is that nobody ever told
>> that patches should or would apply cleanly :( There are
>> cases when things has to be done manually. IMO it's
>> almost impossible to design daily "life" around making
>> back-porting patches a no-brainer. [I've went through
>> it in 1.0.1, which I did fully manually BTW.]
> 
> I'm doing it quite manually to extract commits and hunks.
> 
> But you are a "core" developer, I'm just helping and I can't know if a
> patch is really a bug fix or something else...

Yeah I know, it can get difficult, that's why 
we should use these marks.

> For example in one of your patches (about unicode overflow protection)
> there were changes to win_prn3  (TEXT(0)) not listed in the Changelog
> and I can't know if they are needed or not... in anay case, they don't
> apply..

Which commit was that?

>> Based on merging experiences we may try to create some
>> basic committing rules to help the process though, but
>> IMO there is no way to _fully_ avoid automatic merge issues.
> 
> Yes, for example if you set a [TOMERGE 2.0] label for previous
> commits, the comit message should be
> Added [TOMERGE 2.0] to rev XY
> and not "updated previous Changelog...."

Should be, but I can't promise that, since it 
takes a lot of time to do these lookups and keep 
it precise on every occasion. Anyway I may stop 
to mark changes as TOMERGE afterwards, I do this 
as convenience, but if it makes things worse, 
it's much easier to drop it. After all in other 
projects I just can see any notion os TOMERGE 
marks. Maybe there exist superior workflow for 
this.

Brgds,
Viktor

_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to