On Wed, 13 Apr 2016 17:34:00 +0300
Konstantin Khomoutov <flatw...@users.sourceforge.net> wrote:

[...]
> I should add that in my opinion, I'd better work towards having a
> written down policy on how to use the public repositories,
> *explained* and handed down to your developers.  I mean, if a
> developer tries a push which fails, and so they simple-mindedly
> "re-try" it with the "--force" command-line option (or some check box
> ticked in some GUI client) then that developer was not properly
> trained because they did not think about the reason their normal push
> failed.
> 
> I mean, it's like trying to have some technical means to prevent
> drivers from driving on the opposite side of the road; instead, the
> drivers should be trained to drive on the correct side of the road
> before their driving license is issued.

To make my point more clear... This is a recurring "problem" in fact:
from time to time someone pops up and asks, say, why `git clean` won't
ask the user about potentially dangerous operations when the user
passes it one of '-x' or '-f' options or both.  Or why force pushes are
allowed, or why `git reset --hard` does not warn etc.

There are opposite opinions on these matters: some people insist on
that "good UI" must ask the user every time if something potentially
dangerous is about to happen.  Other people, me included, think that
there's a problem with this approach: people quickly learn to answer
"yes" when asked.

As it happens, I do support "end users" with their problems with
various bits of software and I know how *quickly* they learn to dismiss
any amount of warnings.

So my point is that the best you can do is to train your users:

1) They have to understand the data model of the history managed by Git.

   They should have clear idea about what's the difference between
   the "fast-forward" push ("normal") and "non-fast-forward" (that one
   requiring using the "--force").

   They should understand the repercussions of force pushing which
   occur even if the original history was replaced with logically
   the same history -- but with different commits (say, what may result
   from an innocently-looking rebase).  Reading the "Recovering from
   upstream rebase" section of the `git rebase` manual page is a must.

2) With this knowledge under their belts, they should be trained to
   follow certain protocol when they *think* they need a force push.

   In its simplest form, they should turn to their team lead or
   something like this.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to