git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Experience with Recovering From User Error (And suggestions for improvements)

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Feb 18, 2015, 09:46 UTC
Message-ID
<54E45F74.6080907@drmicha.warpmail.net>
In-Reply-To
<54E1F0AF.1070403@active-4.com>
Armin Ronacher venit, vidit, dixit 16.02.2015 14:29:
Show 27 quoted lines
> Hi,
> 
> On 16/02/15 13:09, Ævar Arnfjörð Bjarmason wrote:
>> We should definitely make recovery like this harder, but is there a
>> reason for why you don't use "git reset --keep" instead of --hard?
> This was only the second time in years of git usage that the reset was 
> incorrectly done.  I suppose at this point I might try to retrain my 
> muscle memory to type something else :)
> 
>> If we created such hooks for "git reset --hard" we'd just need to
>> expose some other thing as that low-level operation (and break scripts
>> that already rely on it doing the minimal "yes I want to change the
>> tree no matter what" thing), and then we'd just be back to square one
>> in a few years when users started using "git reset --really-hard" (or
>> whatever the flag would be).
> I don't think that's necessary, I don't think it would make the 
> operation much slower to just make a dangling commit and write out a few 
> blobs.  The garbage collect will soon enough take care of that data 
> anyways.  But I guess that would need testing on large trees to see how 
> bad that goes.
> 
> I might look into the git undo thing that was mentioned.
> 
> 
> Regards,
> Armin
> 
Are you concerned about the index only, not unstaged worktree changes?

In this case, keeping a reflog for the index may help, and it would somehow fit into the overall concept.

Otherwise, we would basically need a full stash before a hard reset. That's not the first time where we could need a distinction between "command run by user" and "command run by script". For the former, we could allow overriding default options, re-aliasing internal commands, adding expensive safety hooks. For the latter we can't.

It's just that we don't have such a concept yet (other than checking tty).
Michael
Previous: Armin RonacherNext: Michael J Gruber
Message 6 of 11 in “Experience with Recovering From User Error (And suggestions for improvements)”
  1. Armin RonacherFeb 16, 2015
  2. Ævar Arnfjörð BjarmasonFeb 16, 2015
  3. Ævar Arnfjörð BjarmasonFeb 16, 2015
  4. Duy NguyenFeb 16, 2015
  5. Armin RonacherFeb 16, 2015
  6. Michael J GruberFeb 18, 2015
  7. Michael J GruberFeb 19, 2015
  8. stash: introduce checkpoint modeMichael J Gruber, Feb 19, 2015
  9. Kyle J. McKayFeb 19, 2015
  10. Junio C HamanoFeb 19, 2015
  11. Kyle J. McKayFeb 19, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.