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

[Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>]

Hi Markus,

Am 04.11.2013 um 02:35 schrieb Duft Markus <Markus.Duft@xxxxxxxxxx>:

·         Configurable commit message template. 

Do you know what system the "Request ID“ is coming from? The thing is that Mylyn does already do that. It integrates with EGit and customizes the commit message according to a configurable template (per workspace or per project). If you have a connector to the target system, then it can also populate things like task/issue number/id, title, etc.

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

I wonder if it’s worth to implement this in EGit. I think it means a lot of additional logic in the code. Make the decisions about what is easy and what is not is also a non trivial task (IMO) because there are many opinions usually. Besides, they can still download a graphical Git client or the command line and mess up the repo on a server the same way. I really think you should better spend time on tweaking the server side in order to prevent those bad things from happening. For example, at Eclipse we use a hook script that does not allow things like delete and force-push for main branches. Committers can still do this to their own branches. Once it’s implemented at that level, it will work with all clients.

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

I run into the EGit merge hell myself occasionally. I wonder if a warning helps or if EGit needs a much stronger usability when performing merges/rebases. Currently, it’s easy for a developer to get lost. I think it will help if EGit could guide the user and inform him about about what state a repository is. This could be incorporated into things like the commit dialog, etc.

-Gunnar

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx