git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Philip Oakley <philipoakley@iee.org>
To: "Randall S. Becker" <rsbecker@nexbridge.com>,
	'Kevin Daudt' <me@ikke.info>,
	'Dimitri Joukoff' <dimitri.joukoff@griffithuni.edu.au>
Cc: git@vger.kernel.org
Subject: Re: git MUST notify user when files will be deleted or overwritten by command
Date: Sat, 9 Mar 2019 23:54:27 +0000	[thread overview]
Message-ID: <dddaf761-29f0-36ce-c0c1-04e59d6c7bc9@iee.org> (raw)
In-Reply-To: <000401d4d6c8$f68bb020$e3a31060$@nexbridge.com>

On 09/03/2019 22:39, Randall S. Becker wrote:
> On March 9, 2019 5:48, Kevin Daudt wrote:
>> 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.
>> 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.
> First, I really do not like the idea of confirmations. This could complicate
> scripting and would drive much of the work I do with git in Jenkins up a
> wall. You would need access to stdin for almost anything.
>
> Second, I think an automatic undo has merit and could further differentiate
> git from other DVCS and VCS systems. My thought is along the lines of
> starting with the stash concept for each undo - almost like an auto-stash.
> Basically, any time you perform a working-directory modifying operation, a
> stash-like commit is added to the repository at HEAD (possibly ignoring
> .gitignore or precious files, like --include-untracked but in a config like
> undo.untracked=on, to avoid needing to remember to do this). I envision it
> being a stash without modifying the working-directory or changing the
> repository state other than the "undo" unlike what stash does.
>
> Considering the performance hit this *will* cause, I would want an option to
> not do this (say, undo.enable=on/off, off by default unless there was some
> newbie metric <j/k>, or maybe undo.fearful=high <j/k>), and a limit to the
> number of undoes (undo.limit=n), and an auto-drop capability so that when
> you finally commit, you have the option to drop the undoes of the previous
> parent commit (undo.autoclean=on/off), or limit it to cleaning after more
> than one commit is done beyond the commit where the undo exists
> (undo.autoclean=n).
>
> Deriving an "undo" off of a specific parent commit (HEAD), instead of
> deriving "undoes" on each other, might be helpful in resolving the question
> of how to you roll off (get rid of) undoes over time - making it just based
> on the time of the snapshot and how many you want to keep. The reason I
> would hang it off of a HEAD commit is that a checkout/switch would preserve
> the undo stack so that when you returned to a branch, its undo stack would
> be available, like stash.
>
> I would also see an impact on gc, potentially, to clean up old undoes beyond
> a specific date.
>
> This might need to start as a modification to stash, like --keep-index, but
> more like taking picture, for example, --snapshot-only. Once you had that,
> building an undo stack should be straight-forward, and undoing would be
> virtually the same as a stash apply (might even *be* stash apply if the
> "undo" and stash were somehow the same thing conceptually). We're probably
> also talking about a new command and subcommands, very similar to the stash
> structure but querying either from HEAD or a specified commitish. If I only
> had the time... ;)
>
> Just my musings.
>
> Randall

The key word to look for on the discussion list is 'precious'.

Have a look at the various discussions 
https://public-inbox.org/git/?q=precious

There are quite a number of files that are otherwise trashable that one 
would not want endless confirmations for - it is a tricky task.

--

Philip


      reply	other threads:[~2019-03-09 23:54 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
2019-03-09 12:19   ` Duy Nguyen
2019-03-09 22:39   ` Randall S. Becker
2019-03-09 23:54     ` Philip Oakley [this message]

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=dddaf761-29f0-36ce-c0c1-04e59d6c7bc9@iee.org \
    --to=philipoakley@iee.org \
    --cc=dimitri.joukoff@griffithuni.edu.au \
    --cc=git@vger.kernel.org \
    --cc=me@ikke.info \
    --cc=rsbecker@nexbridge.com \
    /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).