Re: git MUST notify user when files will be deleted or overwritten by command

> 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