On 7/13/10 5:41 PM, "Graham Percival" <gra...@percival-music.ca> wrote:
> On Tue, Jul 13, 2010 at 05:30:38PM -0600, Carl Sorensen wrote:
>> Because it changes the syntax, I need to change documentation text,
>> documentation examples in english, french, spanish, and german (plus
>> potentially in hungarian and japanese), documentation snippets, regression
>> tests, web examples, and convert-ly. Every one of these files needs a
>> version. (And I haven't yet mentioned changes.tely).
>
> Hmm, I hadn't thought of that.
>
>> How the mao am I supposed to get a patch reviewed? I prepared the patch for
>> 2.13.27, then updated it for 2.13.28, and now we're at 2.13.29. The review
>> cycle is *longer* than the release cycle! I suppose there's some way to use
>> xargs to fund the files changed in the patch and automatically (using sed)
>> change every occurrence of 2.13.28 to 2.13.29, but I don't have the bash
>> script-fu to do this.
>
> If you have the patch as a single file, then (in vim) it would be
> %s/2.13.28/2.13.29/g
Ahh, this provides a workable idea.
>
> But if you're working on a separate branch (as is right and proper
> for a major change), then I'm not certain how to go about it. I'm
> looking forward to opinions.
git diff master > version-patch
sed s/2.13.28/2.13.29/g <version-patch >new-version-patch
git checkout master
git branch -f new-version
git checkout new-version
git apply new-version-patch
git diff old-branch > update-version-patch
git checkout old-branch
git apply update-version-patch
git branch -D new-version
I think this will work. It's quite a few commands, but much less than
editing 41 files!
Thanks,
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
