Re: [egit-dev] Added commands for keybinding

[denstar <valliantster@xxxxxxxxx>]

On Sun, Mar 14, 2010 at 2:48 PM, Robin Rosenberg wrote:
> (I re-added egit-dev to the to-list)

Heh.  I /rock!/    Bet it's not the last time, neither.

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

Patch with history, neh?

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

Ah.  That sounds a lot like the Subversion way too.  :)

I thought that using Git meant that Id really be able to "commit
early, commit often".  Pushing the history as well, seems like it can
tangle stuff if you're not careful.  I bet doing the whole "reset
(revert?  rebase?) / patch / commit" deal will come in handy here too.

I don't want to break the build, but it'd be nice to be able to commit
/somewhere/ with impunity, and maybe use tags or something for CI type
stuff.

I think I just need to get more comfortable with Git, as what I'm
aiming for sure seems possible.  Need more F'n manual reading, no
doubt.  :)

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

I work on a CFML editor, and I want to dig into the Mylyn stuff for it
at some point -- or maybe just piggy-back on DLTK or whatnot -- but I
haven't really played with writing stuff for Mylyn, myself.

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

A lot of the "resource" aware menus end up checking stuff every time
anyways, it seems, but you're right, a listener is mostly harmless, if
listening to the right stuff.

Ironically, the key bindings are working fine when the selection comes
from within an editor.  It's when it's a structured selection from the
navigator/etc., that it's struggling.

I just had an idea on fixing the hokey loop I'm using to get the
selected projects, which might fix the "mixed resources" error... odd
that the getSelectedProjects doesn't contain anything when the action
is executed by a command instead though.

What about a model listener?  Is there a "model"?  I'm sure I'll pick
this stuff up on the way, but is there a wiki that maybe has
information down these lines, that I should be looking at?

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

Excellent.  I thought this was a "new" project, and did absolutely no
research into the history or anything.  It's active, and I wanted
keybinding, so I just jumped in.

...
>  and most patches are good.

I'll try to make a good patch then.  Doesn't look like I'll have to
make any sweeping changes (said famously), so swapping it out for
better stuff shouldn't be bad, either.

Thanks for all the information!

:Den

-- 
Vice: Whatever was passion in the contemplation of man, being brought
forth by his will into action.
James Harrington