Re: [frogs] lilycontrib.tcl

[Carl Sorensen <c_sorensen@xxxxxxx>]

On 11/1/09 9:33 AM, "Graham Percival" <graham@xxxxxxxxxxxxxxxxx> 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!