Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] Improvement Suggestions / What's your opinion(s)?

> Some kind of (Java!) commit “checker”.

A similar mechanism, much simpler, is used by the Eclipse CVS client.
It allows to abort a commit if resources it contains have warnings or
errors [1]. I assume you would like to take one step further.

[1] see the Prompting tab description here:
http://help.eclipse.org/kepler/topic/org.eclipse.platform.doc.user/reference/ref-19cvs.htm?cp=0_4_1_16

On Tue, Nov 5, 2013 at 12:06 AM, Robin Rosenberg
<robin.rosenberg@xxxxxxxxxx> wrote:
>
>
> ----- 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
> _______________________________________________
> egit-dev mailing list
> egit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/egit-dev


Back to the top