Re: [frogs] lilycontrib.tcl

[Graham Percival <graham@xxxxxxxxxxxxxxxxx>]

On Sat, Oct 31, 2009 at 08:51:24PM -0600, Carl Sorensen wrote:
> I've now got a new version of lilycontrib.tcl.

Nice!

> It will update the repository with or without rebasing.

What does that mean?
(I'm not asking you to explain it to me; I'd like the tool to do
this.  Something like instead of having a rebase button, it says
"nuke my changes!" or whatever it is that rebase does)

I'm not being facetious here -- I honestly don't know, and don't
care, what rebase is.  Even though people have tried to explain it
to me 3 or 4 times, as well as pointing me at "fantastic"
tutorials half a dozen times.  People (especially me :)  will
learn something if they *want* to learn it.  But if *I* can be
useful to lilypond without knowing what "rebase" means, I
definitely don't think we should expect newbies to learn about it.


In other words, when would a user want to enable (or disable?) the
rebase thing?  IIRC from the CG, we always want to use it unless
you're writing translations?  If that's correct, then why not call
it "Updating translations" or something like that?

(or potentially we could have two different, but almost-identical
scripts?  One for normal contributors, one for translators, with
the appropriate rebase stuff defined behind the scenes?)

> It will run git mergetool to enable merge conflict resolution.

Clicking this gives me
  Git aborted: child process exited abnormally
and in the console, it says
  merge tool candidates: meld kiff3 ... blah blah...
  opendiff: file not found


Again, I'm not totally clear about what "reconcile merge errors"
does... I mean, whenever "git pull -r" fails for me, I just move
my modified files away, do a "git rebase --hard origin master",
then start looking at diffs.

For an introductory tool, I'm not certain we need anything more
complicated than this.  These people will know even less about git
than me, after all.  :)

> It has an Abort changes button that will copy all of the locally changed
> files to ./aborted_edits, then resets to origin/master.

Nice!  I'd be tempted to call this "nuke everything from orbit;
that's the only way to be certain", but that's a bit too long for
a button.

> I think it's ready for release.  Can any of you try testing it to see if you
> think  it works?  I'd welcome any feedback you have.

I had to add:
  git commit -a -m "Update from lilycontrib"
to the top of
  proc patch_from_origin {} {

I'm not certain if you want it before the global vars, or before
the other config / rebase stuffs... but as far as I know, we
definitely need such a command.

If there's an easy way to prompt the user to type a commit message
from within the gui, then I'm certainly not opposed to that, but I
don't consider this a vital feature.  The people receiving these
patches (me, you, Trevor, etc) can easily change the commit
messages.

NB: we *don't* need any "git add" or "git rm".  That would add too
much complexity; if a new contributor needs a new file, we can add
a stub for him or her.

Cheers,
- Graham

---

----
Join the Frogs!