{"thread":{"id":"64608","subject":"[RFC] reset --hard: warn before discarding staged content with no commit history","startedAt":"2025-12-10T15:01:41Z","lastAt":"2025-12-15T07:23:03Z","messageCount":13,"participants":["Koutsouflakis Stefanos","Junio C Hamano","Eric Sunshine","Johannes Sixt","D. Ben Knoble","Štefan Balog"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"531978","messageId":"a5wKtD6Tn0gzcba1IEUhukYnXPHxMwPq6puQKIPywmjNufi5vc6vX-v5BpPJ7qj_zZsuXF5FiS2gbpsurWmVjoWHtMm8A-kAbaZyjMfrTcs=@proton.me","threadId":"64608","inReplyTo":null,"subject":"[RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"Koutsouflakis Stefanos","fromEmail":"koutsouflakis.stefanos@proton.me","sentAt":"2025-12-10T15:01:36Z","receivedAt":"2025-12-10T15:01:41Z","isPatch":false,"sender":{"key":"koutsouflakis.stefanos@proton.me","avatar":null},"body":"When running \"git reset --hard\" in a repository where staged content\nhas never been committed, the staged files are lost. This seems like a case where requiring --force could be helpful.\n\nReproduction:\n\n mkdir test && cd test\n git init\n echo \"hello\" > a.txt\n git add .\n git reset --hard\n\nResult: a.txt is removed from both the index and working tree.\nWhile the blob temporarily remains as a dangling object (recoverable\nvia \"git fsck --lost-found\" until garbage collection), this is not a\nrealistic safety net as the filename is lost and most users are\nunaware of this recovery mechanism.\n\nThe most likely scenario is a user initializing a Git repository in an\nexisting project. They have a folder with files they've been working on,\nrun \"git init\", then \"git add .\" to stage everything. A mistyped or\nmisunderstood command later, their entire project is wiped out.\n\nProposed behavior:\n\nWhen \"git reset --hard\" would discard staged content that does not\nexist in any commit (i.e., the blob has no reachable reference),\nprint a warning and require confirmation or --force:\n\n warning: the following staged files have never been committed\n and will be permanently lost:\n a.txt\n use --force to proceed, or commit first\n\nThis would be consistent with Git's general trend toward safer\ndefaults.\n\nQuestions for discussion:\n\n1. Is this safety check worth the added complexity?\n\n2. Are there workflows where this would be annoying? (can't think of any but I might be missing something).\n\nI'm happy to work on a patch if there's interest.\n\nThanks,\nStefanos\n"},{"id":"532013","messageId":"xmqqldj9g0pj.fsf@gitster.g","threadId":"64608","inReplyTo":"a5wKtD6Tn0gzcba1IEUhukYnXPHxMwPq6puQKIPywmjNufi5vc6vX-v5BpPJ7qj_zZsuXF5FiS2gbpsurWmVjoWHtMm8A-kAbaZyjMfrTcs=@proton.me","subject":"Re: [RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-11T03:24:24Z","receivedAt":"2025-12-11T03:24:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Koutsouflakis Stefanos writes:\n\n> When running \"git reset --hard\" in a repository where staged\n> content has never been committed, the staged files are lost. This\n> seems like a case where requiring --force could be helpful.\n\nThe thinking has always been \"'--hard' means what it says! HARD\nremoves things harder than other modes---there is need to add\n'--force' to it\".\n\nSo, I dunno.\n"},{"id":"532014","messageId":"CAPig+cSep7+i2R-DDK+B6p6c3gy2Ehvm4U5N_PwSR-yZF3n1hA@mail.gmail.com","threadId":"64608","inReplyTo":"xmqqldj9g0pj.fsf@gitster.g","subject":"Re: [RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2025-12-11T03:59:51Z","receivedAt":"2025-12-11T04:00:03Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Dec 10, 2025 at 10:24 PM Junio C Hamano wrote:\n> Koutsouflakis Stefanos writes:\n> > When running \"git reset --hard\" in a repository where staged\n> > content has never been committed, the staged files are lost. This\n> > seems like a case where requiring --force could be helpful.\n>\n> The thinking has always been \"'--hard' means what it says! HARD\n> removes things harder than other modes---there is need to add\n> '--force' to it\".\n\nPresumably, you meant \"there is *no* need\" rather than \"there is need\".\n"},{"id":"532017","messageId":"xmqqcy4lfv3k.fsf@gitster.g","threadId":"64608","inReplyTo":"CAPig+cSep7+i2R-DDK+B6p6c3gy2Ehvm4U5N_PwSR-yZF3n1hA@mail.gmail.com","subject":"Re: [RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-11T05:25:35Z","receivedAt":"2025-12-11T05:25:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> On Wed, Dec 10, 2025 at 10:24 PM Junio C Hamano wrote:\n>> Koutsouflakis Stefanos writes:\n>> > When running \"git reset --hard\" in a repository where staged\n>> > content has never been committed, the staged files are lost. This\n>> > seems like a case where requiring --force could be helpful.\n>>\n>> The thinking has always been \"'--hard' means what it says! HARD\n>> removes things harder than other modes---there is need to add\n>> '--force' to it\".\n>\n> Presumably, you meant \"there is *no* need\" rather than \"there is need\".\n\nThanks. I rewrote the paragraph a few times and somehow losing the\ncrucial negation from there..\n"},{"id":"532043","messageId":"0lbeTWjDGq8hINMi-lj65HLgAIlUNZe_tzANStd9xxHQqAyZaEnaA0yPzVeY_VcReQIKNjY7eBEUGwMGvlbZ-0W0QZpux22cIHnosa0eX_k=@proton.me","threadId":"64608","inReplyTo":"xmqqldj9g0pj.fsf@gitster.g","subject":"Re: [RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"Koutsouflakis Stefanos","fromEmail":"koutsouflakis.stefanos@proton.me","sentAt":"2025-12-11T11:53:37Z","receivedAt":"2025-12-11T11:53:43Z","isPatch":false,"sender":{"key":"koutsouflakis.stefanos@proton.me","avatar":null},"body":"On Wed, Dec 10, 2025 at 10:24 PM Junio C Hamano wrote:\n> Koutsouflakis Stefanos writes:\n> > When running \"git reset --hard\" in a repository where staged\n> > content has never been committed, the staged files are lost. This\n> > seems like a case where requiring --force could be helpful.\n>\n> The thinking has always been \"'--hard' means what it says! HARD\n> removes things harder than other modes---there is need to add\n> '--force' to it\".\n\nI agree that \"--hard\" conveys serious intent. But I would argue there is a meaningful difference between \"lose your uncommitted changes\" and \"lose your entire project\".\n\nTo be clear, I'm addressing a very narrow scenario:\nthe user has run init on an existing codebase, staged files\nwith git add, but has not yet made a first commit. Running\nreset --hard at this point destroys the entire project\nwith no realistic recovery path. This is almost certainly\nnever intentional.\n\nThanks,\nStefanos\n\n\n"},{"id":"532044","messageId":"d318c46c-fbc3-4e47-8c3f-165ca9a26225@kdbg.org","threadId":"64608","inReplyTo":"0lbeTWjDGq8hINMi-lj65HLgAIlUNZe_tzANStd9xxHQqAyZaEnaA0yPzVeY_VcReQIKNjY7eBEUGwMGvlbZ-0W0QZpux22cIHnosa0eX_k=@proton.me","subject":"Re: [RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2025-12-11T12:22:30Z","receivedAt":"2025-12-11T12:22:39Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 11.12.25 um 12:53 schrieb Koutsouflakis Stefanos:\n> On Wed, Dec 10, 2025 at 10:24 PM Junio C Hamano wrote:\n>> The thinking has always been \"'--hard' means what it says! HARD\n>> removes things harder than other modes---there is [no] need to add\n>> '--force' to it\".\n> \n> I agree that \"--hard\" conveys serious intent. But I would argue\n> there is a meaningful difference between \"lose your uncommitted\n> changes\" and \"lose your entire project\".\n> \n> To be clear, I'm addressing a very narrow scenario:\n> the user has run init on an existing codebase, staged files\n> with git add, but has not yet made a first commit. Running\n> reset --hard at this point destroys the entire project\n> with no realistic recovery path. This is almost certainly\n> never intentional.\nI would argue that bad \"tutorials\" and \"recipes\" are to blame. I have\nseen far too many that casually suggest `git reset --hard` without\nwarning and in an easy to copy-and-paste format.\n\nWouldn't the following slightly different scenario warrant a similar\nsafety net:\n\n git commit --allow-empty -m \"Initial commit\"\n git add .\n git reset --hard\n\nThat said, I have some sympathy for the case. Would it be palatable to\nhave `git reset --hard` refuse to do anything if the destination tree is\nempty?\n\n-- Hannes\n\n"},{"id":"532050","messageId":"lVqXkS_Nc_hxtxMq3nevB6dCfPgh-qw9A6dLROQqGqN1_iqDONXeGQmp91hGmVTmaSIqGy5QVMC5OuzJmuULP-rUWcqBSv_L8pnLgPjoDsM=@proton.me","threadId":"64608","inReplyTo":"d318c46c-fbc3-4e47-8c3f-165ca9a26225@kdbg.org","subject":"Re: [RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"Koutsouflakis Stefanos","fromEmail":"koutsouflakis.stefanos@proton.me","sentAt":"2025-12-11T16:33:08Z","receivedAt":"2025-12-11T16:33:15Z","isPatch":false,"sender":{"key":"koutsouflakis.stefanos@proton.me","avatar":null},"body":"On Thursday, December 11th, 2025 at 14:34, Johannes Sixt wrote:\n\n> Am 11.12.25 um 12:53 schrieb Koutsouflakis Stefanos:\n> \n> > On Wed, Dec 10, 2025 at 10:24 PM Junio C Hamano gitster@pobox.com wrote:\n> > \n> > > The thinking has always been \"'--hard' means what it says! HARD\n> > > removes things harder than other modes---there is [no] need to add\n> > > '--force' to it\".\n> > \n> > I agree that \"--hard\" conveys serious intent. But I would argue\n> > there is a meaningful difference between \"lose your uncommitted\n> > changes\" and \"lose your entire project\".\n> > \n> > To be clear, I'm addressing a very narrow scenario:\n> > the user has run init on an existing codebase, staged files\n> > with git add, but has not yet made a first commit. Running\n> > reset --hard at this point destroys the entire project\n> > with no realistic recovery path. This is almost certainly\n> > never intentional.\n> \n> I would argue that bad \"tutorials\" and \"recipes\" are to blame. I have\n> seen far too many that casually suggest `git reset --hard` without\n> warning and in an easy to copy-and-paste format.\n\nAgreed. Many users copy-paste their way through Git or use commands\nthey don't fully understand. That's not the ideal way to interact with \nGit, but they don't deserve do be punished.\n \n> That said, I have some sympathy for the case. Would it be palatable to\n> have `git reset --hard` refuse to do anything if the destination tree is\n> empty?\n> \n> -- Hannes\n\nGood point. Checking for an empty destination tree seems to be\nthe better approach. \nRefusing to proceed (without providing the option of bypassing \nit with --force) also seems reasonable, maybe with a helpful \nmessage explaining the reason. \nOn a second thought \"--hard --force\" is a bit redundant, \nlike \"rm -rf --really-delete\".\n\nThanks,\nStefanos\n"},{"id":"532056","messageId":"xmqqzf7ocrhk.fsf@gitster.g","threadId":"64608","inReplyTo":"d318c46c-fbc3-4e47-8c3f-165ca9a26225@kdbg.org","subject":"Re: [RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-12T03:24:07Z","receivedAt":"2025-12-12T03:24:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Wouldn't the following slightly different scenario warrant a similar\n> safety net:\n>\n> git commit --allow-empty -m \"Initial commit\"\n> git add .\n> git reset --hard\n\nYes, I think everybody has lost new files not in an empty tree but\nmore often (1) create a new file and add it, (2) make modifications\nto existing files, (3) compile, test, debug, get frustrated, and\nfinally (4) decide to give up and start from scratch, with \"reset\n--hard\". When (1) is much larger than (2), the sense of loss is\nbig.\n\n> That said, I have some sympathy for the case. Would it be palatable to\n> have `git reset --hard` refuse to do anything if the destination tree is\n> empty?\n\nI doubt that special casing an empty tree would fly well.\n\nIt is tempting to special case removals, but then I sill am not sure\nit is good to do nothing and fail the command after determining that\nthe operation is a common pitfall of removing a new file that\nappears nowhere else. Unconditionally going interactive is a no-no.\n\nAnd I do not have any better ideas. Other than just failing, that is.\nBut that leads to nonsense combination \"--hard --force\", just as\nidiotic combination as \"rm -f -i\" :-/\n"},{"id":"532095","messageId":"CALnO6CC=JpKBwJbLDeBkEF5e3SnqzEXwNH_W3S5Bzhz3DD14MQ@mail.gmail.com","threadId":"64608","inReplyTo":"a5wKtD6Tn0gzcba1IEUhukYnXPHxMwPq6puQKIPywmjNufi5vc6vX-v5BpPJ7qj_zZsuXF5FiS2gbpsurWmVjoWHtMm8A-kAbaZyjMfrTcs=@proton.me","subject":"Re: [RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-12-12T22:14:28Z","receivedAt":"2025-12-12T22:14:40Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Wed, Dec 10, 2025 at 10:04 AM Koutsouflakis Stefanos\n wrote:\n>\n> When running \"git reset --hard\" in a repository where staged content\n> has never been committed, the staged files are lost. This seems like a case where requiring --force could be helpful.\n>\n> Reproduction:\n>\n> mkdir test && cd test\n> git init\n> echo \"hello\" > a.txt\n> git add .\n> git reset --hard\n>\n> Result: a.txt is removed from both the index and working tree.\n> While the blob temporarily remains as a dangling object (recoverable\n> via \"git fsck --lost-found\" until garbage collection), this is not a\n> realistic safety net as the filename is lost and most users are\n> unaware of this recovery mechanism.\n>\n> The most likely scenario is a user initializing a Git repository in an\n> existing project. They have a folder with files they've been working on,\n> run \"git init\", then \"git add .\" to stage everything. A mistyped or\n> misunderstood command later, their entire project is wiped out.\n>\n> Proposed behavior:\n>\n> When \"git reset --hard\" would discard staged content that does not\n> exist in any commit (i.e., the blob has no reachable reference),\n> print a warning and require confirmation or --force:\n>\n> warning: the following staged files have never been committed\n> and will be permanently lost:\n> a.txt\n> use --force to proceed, or commit first\n>\n> This would be consistent with Git's general trend toward safer\n> defaults.\n>\n> Questions for discussion:\n>\n> 1. Is this safety check worth the added complexity?\n>\n> 2. Are there workflows where this would be annoying? (can't think of any but I might be missing something).\n>\n> I'm happy to work on a patch if there's interest.\n>\n> Thanks,\n> Stefanos\n>\n\nPerhaps useful for future readers who are looking for ways to recover\nthe objects: https://blog.plover.com/prog/git-reset-disaster.html\n\n-- \nD. Ben Knoble\n"},{"id":"532144","messageId":"Ai2bA2Zt8bsexgQEIKg1vK7-SNNhTlsmmFp_gOJp8IKX9dJME7UC97EtqRhAUfD00sFmqRdHg9xgGW82rikrLIDUIswrUPr3RKm-LQgGuNY=@proton.me","threadId":"64608","inReplyTo":"xmqqzf7ocrhk.fsf@gitster.g","subject":"Re: [RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"Koutsouflakis Stefanos","fromEmail":"koutsouflakis.stefanos@proton.me","sentAt":"2025-12-14T13:29:54Z","receivedAt":"2025-12-14T13:29:59Z","isPatch":false,"sender":{"key":"koutsouflakis.stefanos@proton.me","avatar":null},"body":"On Friday, December 12th, 2025 at 05:25, Junio C Hamano wrote:\n\n> I doubt that special casing an empty tree would fly well.\n\nI might be missing something, could you say more about \nwhat makes this problematic? \nIf it is about breaking existing workflows: any script that \nautomates either of the two use-cases discussed would be relying \non behavior that is almost certainly unintended. Such scripts \nwould fail, but without data loss, and give authors a clear \nsignal to fix a likely bug. \n\n> And I do not have any better ideas. Other than just failing, that is.\n> But that leads to nonsense combination \"--hard --force\", just as\n> idiotic combination as \"rm -f -i\" :-/\n\nThere might be other ways to mitigate this, e.g.:\na) Refuse with a fatal error and hint the user\n to remove staged content with \"git rm --cached -r .\"\nb) Autostash with a warning \n\nThanks,\nStefanos\n"},{"id":"532146","messageId":"CAJq5WQ5+LBNR11gC+XPT6Z1ZZQZ0HLXxtZdRDoS+wpDjAy2itA@mail.gmail.com","threadId":"64608","inReplyTo":"Ai2bA2Zt8bsexgQEIKg1vK7-SNNhTlsmmFp_gOJp8IKX9dJME7UC97EtqRhAUfD00sFmqRdHg9xgGW82rikrLIDUIswrUPr3RKm-LQgGuNY=@proton.me","subject":"Re: [RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"Štefan Balog","fromEmail":"stevobalog123@gmail.com","sentAt":"2025-12-14T13:45:09Z","receivedAt":"2025-12-14T13:45:23Z","isPatch":false,"sender":{"key":"stevobalog123@gmail.com","avatar":"https://gravatar.com/avatar/05ccd2c83f93dc863c81035a018ce5eed17162cd3c0664215cbb07f4da71c74f?d=mp&s=160"},"body":"Dôvera, spolupráca, jednota !\nJedina cesta posunu genetického kódu a vyvoja pre zlepšenie kvality života\nľudí a spoločnosti v ktorej víťazí dokonalá súhra dôvery viery a nádeje v\nlepší svet v symbióze s kozmom.\n\nWorld Rescue Organization\n\nDňa ne, 14. dec 2025, 14:30 Koutsouflakis Stefanos <\nkoutsouflakis.stefanos@proton.me> napísal(a):\n\n> On Friday, December 12th, 2025 at 05:25, Junio C Hamano \n> wrote:\n>\n> > I doubt that special casing an empty tree would fly well.\n>\n> I might be missing something, could you say more about\n> what makes this problematic?\n> If it is about breaking existing workflows: any script that\n> automates either of the two use-cases discussed would be relying\n> on behavior that is almost certainly unintended. Such scripts\n> would fail, but without data loss, and give authors a clear\n> signal to fix a likely bug.\n>\n> > And I do not have any better ideas. Other than just failing, that is.\n> > But that leads to nonsense combination \"--hard --force\", just as\n> > idiotic combination as \"rm -f -i\" :-/\n>\n> There might be other ways to mitigate this, e.g.:\n> a) Refuse with a fatal error and hint the user\n> to remove staged content with \"git rm --cached -r .\"\n> b) Autostash with a warning\n>\n> Thanks,\n> Stefanos\n>\n>\n"},{"id":"532154","messageId":"xmqqwm2o8x0v.fsf@gitster.g","threadId":"64608","inReplyTo":"Ai2bA2Zt8bsexgQEIKg1vK7-SNNhTlsmmFp_gOJp8IKX9dJME7UC97EtqRhAUfD00sFmqRdHg9xgGW82rikrLIDUIswrUPr3RKm-LQgGuNY=@proton.me","subject":"Re: [RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-14T23:27:12Z","receivedAt":"2025-12-14T23:27:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Koutsouflakis Stefanos writes:\n\n> On Friday, December 12th, 2025 at 05:25, Junio C Hamano wrote:\n>\n>> I doubt that special casing an empty tree would fly well.\n>\n> I might be missing something, could you say more about \n> what makes this problematic? \n\nInconsistency.\n\nTreating \"newly added files\" specifically is making the behaviour\ninconsistent with others already, but doing so only when you haven't\ncreated a commit or after doing \"checkout/switch --orphan\", which is\nessentially what special-casing an empty tree case is about, makes\nit even more inconsistent.\n\n> If it is about breaking existing workflows: any script that \n> automates either of the two use-cases discussed would be relying \n> on behavior that is almost certainly unintended.\n\nI do not think that is the reason for \"special casing an empty tree\nwould not fly well\", but I have to say your view is too narow. I do\nrely on \"reset --hard && clean -f -x\" working in order to make the\nworking tree spiffy clean, and I somehow doubt I am in the minority.\nAnd \"reset --hard\" MUST not fail in such a case.\n\n> Such scripts \n> would fail, but without data loss, and give authors a clear \n> signal to fix a likely bug. \n\nAnd most authors will consider the \"bug\" to be fixed is in the\ndegraded behaviour of \"reset --hard\". that does not do what is\nwritten on the label Then what?\n\n"},{"id":"532165","messageId":"inl6W-7dpE2-dCPugnjAM-X01zhKAp5niQNigtqe5EVKEMEy1KEPFegzDC1zjpm7etuqAoVjg1gUd8_5vFO90LhaGmzLc3HJTE4MREXtzH8=@proton.me","threadId":"64608","inReplyTo":"xmqqwm2o8x0v.fsf@gitster.g","subject":"Re: [RFC] reset --hard: warn before discarding staged content with no commit history","fromName":"Koutsouflakis Stefanos","fromEmail":"koutsouflakis.stefanos@proton.me","sentAt":"2025-12-15T07:22:54Z","receivedAt":"2025-12-15T07:23:03Z","isPatch":false,"sender":{"key":"koutsouflakis.stefanos@proton.me","avatar":null},"body":"On Monday, December 15th, 2025 at 01:27, Junio C Hamano wrote:\n\n> Inconsistency.\n> \n> Treating \"newly added files\" specifically is making the behaviour\n> inconsistent with others already, but doing so only when you haven't\n> created a commit or after doing \"checkout/switch --orphan\", which is\n> essentially what special-casing an empty tree case is about, makes\n> it even more inconsistent.\n> \n> > If it is about breaking existing workflows: any script that\n> > automates either of the two use-cases discussed would be relying\n> > on behavior that is almost certainly unintended.\n> \n> \n> I do not think that is the reason for \"special casing an empty tree\n> would not fly well\", but I have to say your view is too narow. I do\n> rely on \"reset --hard && clean -f -x\" working in order to make the\n> working tree spiffy clean, and I somehow doubt I am in the minority.\n> And \"reset --hard\" MUST not fail in such a case.\n> \n> > Such scripts\n> > would fail, but without data loss, and give authors a clear\n> > signal to fix a likely bug.\n> \n> \n> And most authors will consider the \"bug\" to be fixed is in the\n> degraded behaviour of \"reset --hard\". that does not do what is\n> written on the label Then what?\n\nThat actually makes sense. For tools as versatile as Git, it is\nsometimes hard to see the bigger picture and the different ways \nof people using it. \nI'll drop the proposal, and thanks everyone for your time.\n\n-- Stefanos\n"}]}