Re: [egit-dev] Added commands for keybinding

[Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>]

(I re-added egit-dev to the to-list)

söndagen den 14 mars 2010 13.00.48 skrev  denstar:
> On Sun, Mar 14, 2010 at 3:30 AM, Robin Rosenberg wrote:
> > söndagen den 14 mars 2010 10.11.23 skrev  denstar:
> 
> ...
> 
> > I like keybindings too, but never had the time to decide on what keys
> > to use. There is the issue of finding an unused and preferrable easy to
> > remember set of bindings.
> 
> Yup, we struggle with the same issue on Subclipse.
> 
> I went with "M3+M4+G M3+M4+V C" for commit, "M3+M4+G M3+M4+V I" for
> ignore, and then "M3+M4+G M3+M4+C I" for "compare with index" (note
> the switch from V to C, as there will probably be more ways of
> comparing resources).
> 
> This is some of the toughest stuff to hammer out tho, coding aside.
> 
> >> Should I just send a patch for review or some-such?  I've created a
> >> github repo at:
> >
> > Our preferred way is that you submbit a well-defined set of patches to
> > gerrit.  See http://wiki.eclipse.org/EGit/Contributor_Guide.
> 
> I thought Git sorta made patches a "thing of the past" so to speak.  :)p

Not at all. Git is kind of patch automation system. 

> >> http://github.com/denuno/egit
> >>
> >> In case that's easiest.
> >
> > Your branch at Github is full of build artifacts and the commit messages
> > don't describe what you are doing. Take a look at the EGit history to get
> > some examples.
> 
> Yes.  I just slapped that sucker up there, and I'm glad I did, as I
> managed to screw up my local sources thinking I could reset just the
> selected resources.  Um, it doesn't work that way.  :)
> 
> I'm at least passingly familiar with SVN, so I know how lame artifacts
> can be.  I would have forked from the eclipse repo if github had that
> feature, tho I'd expected that what I had would have all the ignores
> and whatnot that it needed.  Still pretty green.  :)
> 
> I'm in love with Mylyn, so normally there'd at least be links to
> tickets and whatnot.  It was a stuck-in-craw-want,
> prompting-spur-of-the-moment few-hour one-off type deal.

Never, ever, just commit everything. Stage each change and check
that the change are what you think they were. That's the Git way. 

Mylyn + Egit is a wet dream, that we have not been realized yet. 

> I wasn't sure if this route would pan out, but I should be developing
> better habits regardless.  Thank you for the examples!
> 
> > Some general hints:
> > If you want to re-format, keeps that as a separate commit as we in
> > general do not accept reformatting changes mixed with other changes.
> 
> D'oh!  Again, I thought that I was safe hitting ctrl+shift+F as much
> as I wanted, due to the stuff I'd read about a strict formatting
> policy (which I freaking love, since Eclipse will do it for me).  I
> see that unused imports get flagged... what about adding a "format
> source on save" deal to the project settings?

> I didn't really do my usual due-diligence, due to sorta mixing up my
> sources, and generally coming to grips with something pretty new to
> me.  I've never really gotten into like, Mercurial, or stuff besides
> CVS and SVN, really.
> 
> > Each commit should result in a next working version of EGit and add
> > javadoc comment to new public and protected methods. Javadoc
> > comments are not needed for methods that have javadoc in the superclass
> > or interface.
> 
> Sounds good.
> 
> Everything is still working in my local debug instance, and I don't
> see anything hanging out uncommitted or different from what I had,
> but-- when I install the plugin into a "real" instance of Eclipse, I'm
> getting a "resources are mixed" error that I just don't get in the
> debug instance.
> 
> Eh.  Such is life.  I'm doing a bunch of coding in the debug instance
> anyways, to test some other plugins I work on and whatnot.  Too much
> dogfood. :)
> 
> I want it in all my instances tho.
> 
> >> I'm super new to Git in general.  As in weeks of experience.  And 95%
> >> of what I've done with Git, I've done through EGit. :)
> >
> > That's nice to hear. We need contributors that use it heavily, since that
> > leads to easy-of-use patches.
> 
> I freaking *live* in Eclipse.  Working with some projects using Git
> now, so... in at least some way, I'm gotten. :)
> 
> >> I'm not even sure how to create a patch yet, honestly.  I'll RTFM that
> >> bridge when I cross it.
> >
> > You need to do a bit of history rewriting to get your commits in shape.
> > Using git gui to commit partial changes is also a useful tool to rewrite
> 
> Now you're scaring me.  Rewriting history?!?!?!  You guys are nuts.
> 
> Although I need to learn that aspect badly, I don't mind making a diff
> and ditching what all I have and re-applying it.  Mostly it's just a
> bunch of XML (it doesn't seem like there are formatting rules for
> XML?), and like one handler class, containing some really ugly (but
> short!) code (uses reflection, even (so I didn't have to code up a
> bunch of variants)).
> 
> If I did change the formatting on an existing class, it must have been
> the RepositoryAction one.  Bah!
> 
> What do you think about the approach in general tho?  The change to
> RepositoryAction is kinda ugly too, but I didn't want a selection
> listener firing off all the time when it only needs the info when the
> command/action executes.

I've noticed that selection is not as straight forward as I thought it was. 
Many of the standard actions in Eclipse include consider the resource 
currently being edited as the "selected" resource. We don't, but we 
probably should. Solving that might lessen our need for a selection
listener. Performance-wise the trigger is probably (hmm) harmless,
but if we don't need it, all the better. Not having a listener might lead to 
actions having to check every time a menu is selected instead.

> And just a general question:  It seems like the plugin has a
> relatively high requirement of Eclipse (3.4, tho I'd push to change
> that and just target [maybe] 3.5,/3.6/etc.).  Not surprising, as it's
> new.  What is surprising is that it looks like a lot of pre 3.3 stuff
> is being used.  Actions vs. commands, not extending
> org.eclipse.ui.menu, etc..
>
> I'm just a hobbyist, by far no plugin guru, but I have learned some
> stuff by watching Subclipse, and working more in-depth with some other
> plugins-- one thing I learned is that it's awesome when you can target
> a more mature *cough* API. :)
> 
> I'm sure everybody feels that way tho, which is why I'm wondering.
> "How long has this plugin been in development?", he says, realizing he
> could just look up that plausible line of reasoning.  But is targeting
> eclipses below 3.5 needed?

All 3.3 stuff can be replace with 3.4 stuff, but we don't do that just because 
we can. We try to support the current release, the previous release and 
usually the version under development if possible, with priority given to the 
released versions. With that policy we well drop 3.4 support when Eclipse 3.6 
is out. When we get bundled with eclipse we may be less friendly to older 
versions.

> I'm getting punchy.  I'll close with something I meant to say
> initially, and that's how easy it was to build everything from source.
>  It was smooth, and clicking the "build all" in the site.xml deal just
> worked.  I appreciate that.
> 
> Seems like it's a pretty active project, too.  I really appreciate that. 
>  :)

Good. And the number of contributors are growing steadily and most patches
are good.

-- robin