On Wed, 13 Apr 2016 17:34:00 +0300
Konstantin Khomoutov <[email protected]> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
