Re: [frogs] lilycontrib.tcl

[Carl Sorensen-3]

On 10/6/09 4:14 PM, "Graham Percival" <graham@...> wrote:

> On Sun, Oct 04, 2009 at 07:38:40PM -0600, Carl Sorensen wrote:
>> I modified that gui a bit, and now it has the ability to create a new local
>> repository, update the repository, and make patches relative to
>> origin/master.
>
> (I haven't tried it yet; maybe this weekend)
>
> I'd suggest a "panic" button, in case there's any conflicts.  This
> would:
> 1) move any user-modified files into a special directory
> (something like lilypond/my-changes/ ? )
> 2) git reset --hard origin/master

I've now got a new version of lilycontrib.tcl.

It creates a new local repository.

It will update the repository with or without rebasing.

It will run git mergetool to enable merge conflict resolution.

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

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.

Thanks,

Carl



_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[Graham Percival-3]

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


_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[Carl Sorensen-3]

On 11/1/09 9:33 AM, "Graham Percival" <graham@...> wrote:

> 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)

Thanks for the feedback.  I'll try to get a shorter description of it.
I think that I'll just create two different buttons, rather than a
button with a checkbox.

>
>> 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.  :)
>

Ahh, but if I can make git mergetool work automatically, it's magic.  You
get a window containing both files side by side, and you can scroll from one
conflict to the next, and choose whether you want option A or option B with
a mouse click.  It's much easier than your way of working, even for a
newbie.  But obviously, it has to work right (so back to the drawing board).


>> 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.

Thanks!  It took me much longer than I expected to make that work, but I
think the final functionality is right.

>
>> 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 {} {
>

See, my plan was to *not* have the GUI handle the commits.  I was planning
to have the commit take place out of the GUI, because there's so much that
can be done with commits.

But now I think I'll have a text field for the commit message, and a Make
New Commit button, and an Amend Previous Commit button.  That way, we can
take care of the two most common ways to handle commits.  And we'll avoid
the commit editor.

>
> 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.

Why not have an Add New File button with a filename text box?

I totally agree on the git rm.

It'll probably be a week before I can get the next version up due to work
commitments.  But I'll get another version up as soon as I can.

Thanks again for the feedback.

Carl



_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[Carl Sorensen-3]

Here's the next version of lilycontrib.tcl.

It has a commit button (with a box for a commit message), and an amend
commit button (to change the previous commit).

It has two update buttons: one (with rebase) for work on code or docs, and
the other (without rebase) for work on translation.

It also has two patch buttons:  one (with rebase for work on code or docs,
and the other (without rebase) for work on translations.

And it has a (hopefully better labeled) button to reset to origin.

I've commented out the mergetool button, because I haven't yet figured out
a good way to test it and see that it works properly.  And working it
properly is probably beyond the capability of the git novice, so it may
never get back in.

Anyway, another round of feedback based on current evaluations would be very
helpful.

Thanks,

Carl



_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel