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

[Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>]

----- Ursprungligt meddelande -----
> Från: "Gunnar Wagenknecht" <gunnar@xxxxxxxxxxxxxxx>
> Till: "Duft Markus" <Markus.Duft@xxxxxxxxxx>
> Kopia: "EGit developer discussion (egit-dev@xxxxxxxxxxx)" <egit-dev@xxxxxxxxxxx>
> Skickat: måndag, 4 nov 2013 14:52:18
> Ämne: Re: [egit-dev] Improvement Suggestions / What's your opinion(s)?
> 
> 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.

The danger is in that "Push to upstream" does not hint about what it is going
to do. There could be a dialog in between that tells the users what will
happen, a cancel button and a "don't ask me again" checkbox.

We also don't log operations, so when I ask the user, I can't be sure what
they really did.

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

Gerrit is also excellent for setting up a commit policy, like who can commit to
what branches. By using ref namespaces it's easy to separate master from integration
branches, development branches and feature branches. I.e. only CM can commit directly
to master and integration. 

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

Sounds like sane ideas here, both on preventing rebase below upstream and more
hints in the commit dialog. We do hint about the state in the package explorer 
and staging view, so why not in the commit dialog, which should really get proper
amend support also.

-- robin