Re: Rietveld workflow problems

[address@hidden]

On Sep 21, 2011, at 1:00 PM, Peekay Ex wrote:

> Hello,
> 
> On Wed, Sep 21, 2011 at 11:45 AM, David Kastrup <address@hidden> wrote:
>> Peekay Ex <address@hidden> writes:
>> 
>>> Hello,
>>> 
>>> On Wed, Sep 21, 2011 at 9:35 AM, address@hidden
>>> <address@hidden> wrote:
>>>> 
>>>> For what it's worth, I run into the same problem from time to time -
>>>> I recently sent an e-mail to the list about a 1-line patch to fix
>>>> kneed beams that I needed to apply for other work.
>>> 
>>> So, and this is a genuine question, why do you need to make a tiny
>>> patch so that a (next) larger patch works. Why not include the tiny
>>> patch in your larger patch (if that makes sense)?
>> 
>> Because it doesn't make sense to combine unrelated patches in that
>> manner.  You can't find them in the history then, and if the large patch
>> gets applied or reverted, the independent small patch has to go along.
>> 
>>> And without wishing to sound rude rude, are we just blaming the tool
>>> here for 'your preference' of work flow?
>> 
>> I prefer not editing tarballs as a means of source control, so git comes
>> in quite handy.  Of _course_ it is the task of tools to support
>> preferable work flows.  Now "generally preferable" is more important
>> than "individually preferred", and the list is the place where one would
>> argue the general merit of one's preferences.
>> 
>> So rude or not, I don't see the point in chastising Mike for explaining
>> his personal preferences and their reasons to the discussion.
> 
> There was no chastisement, the point I was trying to make is it seemed
> to me that some of the devs were trying to shoehorn a workflow into a
> 'system' (that being how we track and review patches) that they are
> not designed for.
> 

No worries!
It is true that the preferences I'm talking about are personal - a lot of my 
patches are gimungous, and they often need several tweaks to the code base just 
so I can work on them.  I don't mind using Reitveld, though - I've never ran 
into unsolvable problems because of it.

> As to it being an unrelated patch - how can it be unrelated if it is
> required in the first place for the 'next' patch to apply correctly?
> That sounds 'related' to me.
> 
> Again perhaps I am being too simplistic but if I make change to file A
> for Patch A and then I make a new Patch B which also includes file A
> change (from a new base) but also add file B does it matter that I
> have two patches that have the same file A? Doesn't it just overwrite
> the file with the same information (i.e. no change). Then if I want
> also to make Patch C (for something different to Patch B) but it also
> requires file A then, again can I just not just make Patch C with File
> A and File C and I'm still ok?

I think this sorta thing needs some git trickery that's way above my head.  
That said, the "no change" thing you're talking about is possible (I've applied 
patches to branches that have the changes in those patches already and git says 
"Merge made by recursive"), but this is only when the changes are line-for-line 
equivalent.  If they contain additional work, the merge needs to be done 
manually.

Long story short, I leave it to the wise discretion of Mr. Percival if we ever 
change hosting tools.  For the moment, I'm happy as a clam using consistent 
sloped beams across line breaks and glissando stems to write crazy string music.

Cheers,
MS