git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Kevin Daudt <me@ikke.info>
To: Dimitri Joukoff <dimitri.joukoff@griffithuni.edu.au>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: git MUST notify user when files will be deleted or overwritten by command
Date: Sat, 9 Mar 2019 11:48:12 +0100	[thread overview]
Message-ID: <20190309104812.GA3403@alpha> (raw)
In-Reply-To: <SYXPR01MB09577F5C4555C9068B606E11DD4E0@SYXPR01MB0957.ausprd01.prod.outlook.com>

On Sat, Mar 09, 2019 at 10:19:03AM +0000, Dimitri Joukoff wrote:
> Hi,
> 
> As a relatively novice user of git, there have been far too many times
> that I have lost data, sometimes quite a lot.  So this proposal is about
> catering for the less experienced users and averting fits of anger and
> frustration.  The only reason my computer still works is because my
> sub-conscious mind stops me from smashing it or throwing it against a
> wall.  It seems my sub-conscious mind has a pragmatic view of the world
> and understands that whilst I may receive instantaneous satisfaction at
> the time, in the long term, the pain will be far worse, and thus
> prevents me from doing something rash.
> 

Yes, it can be very frustrating to lose things you did not intend to
lose, so making sure your tooling limits the chances of that happing is
certainly a worthwile goal.

> 
> Below is the detail of my proposal: > 
> Whenever a command is issued in git that will cause git to overwrite or
> delete *ANY* files whose current state isn't already recorded in the
> repository, git should prompt the user to confirm the operation. This
> includes untracked files as well as files that are in the 'not staged'
> and 'staged' lists.
> 
> To make the consequences of the command transparent, the confirmation
> should include a list of files that will be affected (perhaps in a
> similar way to how git status works).  The scope of the files listed
> must match the scope of the command to be executed.  No hidden changes,
> no side-effects.
> 
> Saying no to the confirmation should abort the command.
> 
> It may be useful to allow confirmation of individual files, but as a
> novice user, I can't argue this point objectively, nor reason about its
> implications and complexity.
> 
> This feature should be enabled by default whenever a clone or init
> operation are performed.
> 
> The user should be able to progressively reduce the range of commands
> and amount of confirmation interactions that take place.  The
> configuration technique could follow the already established procedure
> for other configurable data in git.  So this could be done globally for
> the user, or locally within each repository.
> 
> 
> As a novice user, there may be further useful extensions of this idea,
> about which I'm unable to reason.  So I welcome further elaboration of
> the idea discussed above.
> 
> 
> Best regards,
> Dimitri.
> 

A lot of confirmations only result in people automatically dismissing
them (confirmation saturation), missing the goal of what you intend.

Instead of asking for confirmation, it's much better to allow people to
undo these mistakes. You see the same pattern in gmail for example,
where they hardly ask you for any confirmation, but instead show an undo
button that allows you to undo the last operation. In my opinion this is
a better way to go then to add confirmations everywhere.

I know this has come up on the git mailing list more often, but I cannot
find a relevant thread at this moment.

Kevin

  reply	other threads:[~2019-03-09 10:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-09 10:19 git MUST notify user when files will be deleted or overwritten by command Dimitri Joukoff
2019-03-09 10:48 ` Kevin Daudt [this message]
2019-03-09 12:19   ` Duy Nguyen
2019-03-09 22:39   ` Randall S. Becker
2019-03-09 23:54     ` Philip Oakley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190309104812.GA3403@alpha \
    --to=me@ikke.info \
    --cc=dimitri.joukoff@griffithuni.edu.au \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).