> Still, implementing such mode is impossible in `git reset --hard` because it's being extensively used in scripts which must continue working unmodified.
I'm more upbeat about the possibilities here for a multi-graded option for capturing the user's prior tree, with it's user modified versions of the tracked files that will be overwritten being stored in the object store, and noted in a suitable reflog. Initial thought is that it's not a commit, rather it's just the tree and updated blobs, so they would be garbage collected eventually. Key factors will be the detection of it being a cli command vs being a script, so that the initial default could be to capture all `reset --hard` commands, softening to just those directly given on the command line (which maybe the general default - usual reasons), and then have one for capturing the --soft option (similar user mistakes), and finally the 'off' option. I suspect that the simplest way is to pick up the default based on the choice of remote workflow (i.e. if they use the simple workflow, then start with full capture. This UX (user experience) does turn up quite often so let's at least put in a few simple defences for those not yet fully aware of how Git works. On Monday, July 18, 2022 at 5:28:17 PM UTC+1 Konstantin Khomoutov wrote: > On Mon, Jul 18, 2022 at 07:16:28PM +0300, Konstantin Khomoutov wrote: > > [...] > > > Another solution which seems logical at the first glance is using the > "trash > > bin" feature is the OS provides it but it also has practical problems: > it is > > never the core feature provided by the kernel, and Git is not always > used by > > human beings through graphical user interfaces, and also Git uses lots > of > > files not intended to be dealt with by the user anyway (though > admittedly in > > your particular case moving the files to the trash can could help). > > May be a good middle ground could be using the "trash can" facility _if > possible_ with presenting a user with the summary of what unstaged files > to be > overwritten/removed. > > Still, implementing such mode is impossible in `git reset --hard` because > it's > being extensively used in scripts which must continue working unmodified. > > Adding a new command-line options forcing this work mode of the reset > command > to be extra-interactive will be of questionable utility as the user would > have > to type it in order to get this behavior. > > So, looks like it's a case for a new top-level command, I dunno. > Adding new "sensible" top-level commands for already existing behavior is > not > uncommon: `git switch` is a good example. > > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/e49beb96-3e26-4680-9b98-1802c024ba0en%40googlegroups.com.
