Re: [egit-dev] Improvement Suggestions / What's your opinion(s)?

[Robert Munteanu <robert.munteanu@xxxxxxxxx>]

Hi Markus,


On Mon, Nov 4, 2013 at 12:35 PM, Duft Markus <Markus.Duft@xxxxxxxxxx> wrote:
>
> Hey!
>
>
>
> Last Week at EclipseCon Europe some of use met, and I used the chance to propose some things rather useful for “us” (my company ;)). Here is a short wrap-up with the request for opinions/suggestions regarding those things :)
>
>
>
> ·         Some kind of (Java!) commit “checker”. What I mean by that is that we want to hook a piece of Java code into EGit that gets the chance to do some checks/verification on a commit. Christian and I talked a little about that and agreed that the most simple solution would be an extension point that is called right /after/ the commit happened, passing the final commit object. But this is merely first thoughts :)

I believe this would be of great value, allowing me to replicate git
commit hooks with ease. I typically have git commit hooks running
client-side, looking for policy violations, but of course that doesn't
work in Eclipse.

Robert

>
> ·         Configurable commit message template. For our company (just an example of course ;)) it is mandatory to have a “Request ID” placed in the message using a certain format. It would be great if this company specific header(s) would be configurable as a template, so that EGit automatically pre-fills the commit message input box(es) with that. As “advanced” version one could also think about variable expansions and such nasty things :D
>
> ·         Configuration possibilities to “disable/hide dangerous options”; Let me explain... We are working using multiple remotes to different repositories hosting software that is related. Some of our developers are not exceptionally “strong” :p. Now when they create local branches, and then press “Push to upstream...”, they simply do not know where this will go. They simply assume it will do what they expect (and this is wrong in at least 50% of the cases). Thus this is “dangerous” for us (specifically), as it may doom branches in repos that should not be touched at all by these things :| Thus (currently) we have a customized EGit, which differs from upstream just by commenting out different menu items from plugin.xml (Push to upstream, Pull, ...) which our developers have proven to not be able to handle them correctly.
>
> ·         Warning when amending a merge from somebody else, or better: configuration option to prevent amending made by somebody else; this is a /really/ bad situation some of our developers managed to get into. They fetched, merged, conflicted, and pressed amend after spending hours to merge. This would put their changes made during “this” merge into a merge commit from upstream (or: somewhere else). Now they cannot push this (of course), and they’re lost, as they cannot get their changes back out from that commit ... :|
>
>
>
> Open for discussion now :) Please leave your opinions and suggestions on how to tackle those kind of things. I’d really love to hear them :) From what we’ve talked at EclipseCon it seems that there are other large companies (*wave to SAP* :)) that have similar problems... maybe there are more?
>
>
>
> I will be glad to develop those features when I find time, but time is a really rare thing for me. So if somebody steps up and implements some or all of those things: I’d owe you a beer or two :D
>
>
>
> Regards,
>
> Markus
>
>
> --
> Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
> Sitz der Gesellschaft: Friesach bei Graz
> UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
> Firmenbuchgericht: Landesgericht für Zivilrechtssachen Graz
>
> _______________________________________________
> egit-dev mailing list
> egit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/egit-dev
>



-- 
http://robert.muntea.nu/