lilycontib.tcl

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

lilycontib.tcl

Carl Sorensen
You may recall that Johannes Schindler created a very simple gui to git that
was customized for LilyPond, so that a new contributor could get started
with no fuss.

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.

It *does not* have any commit functionality.

I'd like to ask any of you who are willing to try it out, and see if it's
helpful.

You can find it at
http://code.google.com/p/lilypond/issues/detail?id=854&q=lilycontrib

You will need to save the file in your home directory. You should probably
change the line in the file that reads


set lily_dir $env(HOME)/lilypond

to

set lily_dir $env(HOME)/lilypond-test

if you already have a git copy of lilypond.

In order for this to work, you will need to have git and wish.  But I think
git depends on tcl, so if you have git you should have wish.

To start the application, type

wish lilycontrib.tcl

This will open a window.  You can then fetch lilypond, or pull it at any
time by clicking on the appropriate button.

You can make changes to any file you want, then commit the changes (using
either the command line or git gui).

Once you have commited the changes, you can create a patch set relative to
origin/master by clicking on the patch button.

Please give it a try, and tell me if you think it's helpful.

Thanks,

Carl



---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: lilycontib.tcl

Graham Percival
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

Resolving any conflicts will be much too hard for casual
non-technical contributors -- mao, it's too hard for *me*!
The above steps should be all that's necessary.

Cheers,
- Graham

---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: lilycontrib.tcl

Carl Sorensen



On 10/6/09 4:14 PM, "Graham Percival" <[hidden email]> 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


lilycontrib.tcl (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: lilycontrib.tcl

Graham Percival
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!

Reply | Threaded
Open this post in threaded view
|

Re: lilycontrib.tcl

Carl Sorensen



On 11/1/09 9:33 AM, "Graham Percival" <[hidden email]> 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


---

----
Join the Frogs!

Reply | Threaded
Open this post in threaded view
|

Re: lilycontrib.tcl

Carl Sorensen
In reply to this post by Graham Percival

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


lilycontrib.tcl (9K) Download Attachment