{"thread":{"id":"49756","subject":"\"git checkout\" safety feature","startedAt":"2018-11-04T19:29:16Z","lastAt":"2018-11-05T15:34:25Z","messageCount":5,"participants":["Matthias Urlichs","Junio C Hamano","Jeff King","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"362411","messageId":"6afef19d-08f6-9cce-a491-3a49808c57ec@urlichs.de","threadId":"49756","inReplyTo":null,"subject":"\"git checkout\" safety feature","fromName":"Matthias Urlichs","fromEmail":"matthias@urlichs.de","sentAt":"2018-11-04T19:12:54Z","receivedAt":"2018-11-04T19:29:16Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi,\n\nA recent discussion on LWN https://lwn.net/Articles/770642/ noted that\n\"git checkout \" does not warn if one if the files has\nbeen modified locally, nor is there an option to do so.\n\nIMHO that should be fixed, preferably by somebody who knows git's\ninternals well enough to do so in half an hour ;-)\n\n-- \n-- Matthias Urlichs\n\n\n"},{"id":"362437","messageId":"xmqqk1lsl448.fsf@gitster-ct.c.googlers.com","threadId":"49756","inReplyTo":"6afef19d-08f6-9cce-a491-3a49808c57ec@urlichs.de","subject":"Re: \"git checkout\" safety feature","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-11-05T01:12:07Z","receivedAt":"2018-11-05T01:12:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\nMatthias Urlichs writes:\n\n> A recent discussion on LWN https://lwn.net/Articles/770642/ noted that\n> \"git checkout \" does not warn if one if the files has\n> been modified locally, nor is there an option to do so.\n>\n> IMHO that should be fixed, preferably by somebody who knows git's\n> internals well enough to do so in half an hour ;-)\n\n\"git checkout \" is a feature to overwrite local\nchanges. It is what you use when you make a mess editing the files\nand want to go back to a known state. Why should that feature be\ndestroyed?\n\n"},{"id":"362456","messageId":"fdedc47b-8661-9451-b4ef-12ec6bd13c04@urlichs.de","threadId":"49756","inReplyTo":"xmqqk1lsl448.fsf@gitster-ct.c.googlers.com","subject":"Re: \"git checkout\" safety feature","fromName":"Matthias Urlichs","fromEmail":"matthias@urlichs.de","sentAt":"2018-11-05T06:24:42Z","receivedAt":"2018-11-05T06:25:15Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi,\n> \"git checkout \" is a feature to overwrite local\n> changes. It is what you use when you make a mess editing the files\n> and want to go back to a known state. Why should that feature be\n> destroyed?\n\nNot destroyed, but optionally made finger-fumble-save – like \"alias rm\nrm -i\".\n\n-- \n-- Matthias Urlichs\n\n\n"},{"id":"362471","messageId":"20181105065136.GN25864@sigill.intra.peff.net","threadId":"49756","inReplyTo":"fdedc47b-8661-9451-b4ef-12ec6bd13c04@urlichs.de","subject":"Re: \"git checkout\" safety feature","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-11-05T06:51:36Z","receivedAt":"2018-11-05T06:51:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 05, 2018 at 07:24:42AM +0100, Matthias Urlichs wrote:\n\n> Hi,\n> > \"git checkout \" is a feature to overwrite local\n> > changes. It is what you use when you make a mess editing the files\n> > and want to go back to a known state. Why should that feature be\n> > destroyed?\n> \n> Not destroyed, but optionally made finger-fumble-save – like \"alias rm\n> rm -i\".\n\nThere are a couple of destructive commands left in Git (e.g., this one,\nand \"git reset --hard\" is another). I didn't dig up archive references,\nbut the topic of safety valves has come up many times over the years.\nThe discussion usually ends with the notion that instead of warning\nthat the operation is destructive (because that gets annoying when its\npurpose is to be destructive), we should make it possible to undo a\nmistake.\n\nSo in this case, that would mean saving the working tree file to a blob\nbefore we obliterate it.\n\nSee similar discussion in:\n\n https://public-inbox.org/git/CACsJy8C5QOLvg4pzy_pThQoyGh9ohdeVHXsuYwQHQypn3oBxkw@mail.gmail.com/\n\nfor example.\n\n-Peff\n"},{"id":"362489","messageId":"CACsJy8CAL37btX12ASXtzyQeD91nwz8q-hyQtgr4+Xf6iYcdbA@mail.gmail.com","threadId":"49756","inReplyTo":"20181105065136.GN25864@sigill.intra.peff.net","subject":"Re: \"git checkout\" safety feature","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-11-05T15:33:54Z","receivedAt":"2018-11-05T15:34:25Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Nov 5, 2018 at 7:53 AM Jeff King wrote:\n>\n> On Mon, Nov 05, 2018 at 07:24:42AM +0100, Matthias Urlichs wrote:\n>\n> > Hi,\n> > > \"git checkout \" is a feature to overwrite local\n> > > changes. It is what you use when you make a mess editing the files\n> > > and want to go back to a known state. Why should that feature be\n> > > destroyed?\n> >\n> > Not destroyed, but optionally made finger-fumble-save – like \"alias rm\n> > rm -i\".\n>\n> There are a couple of destructive commands left in Git (e.g., this one,\n> and \"git reset --hard\" is another). I didn't dig up archive references,\n> but the topic of safety valves has come up many times over the years.\n> The discussion usually ends with the notion that instead of warning\n> that the operation is destructive (because that gets annoying when its\n> purpose is to be destructive), we should make it possible to undo a\n> mistake.\n>\n> So in this case, that would mean saving the working tree file to a blob\n> before we obliterate it.\n>\n> See similar discussion in:\n>\n> https://public-inbox.org/git/CACsJy8C5QOLvg4pzy_pThQoyGh9ohdeVHXsuYwQHQypn3oBxkw@mail.gmail.com/\n>\n> for example.\n\nThat work is still ongoing (slowly). I realized that reflog code was\nburied deep in files-backend.c and would not make sense to reuse in\nits current form. So I had to move the code to a common place, which\nadds more work. But it will be coming! Hopefully before 2020 at my\nusual development speed.\n\nWhile we're at it, I've been running something with that \"index\nreflog\" (no pruning) for a month with lots of \"add -p\" and the file\nsize is just 163KB, so the reflog format seems promising for this\npurpose.\n-- \nDuy\n"}]}