{"thread":{"id":"4369","subject":"git reset --hard not removing some files","startedAt":"2006-06-01T16:00:52Z","lastAt":"2006-06-04T09:31:21Z","messageCount":14,"participants":["Martin Waitz","Sean","Linus Torvalds","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"21058","messageId":"20060601160052.GK14325@admingilde.org","threadId":"4369","inReplyTo":null,"subject":"git reset --hard not removing some files","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-06-01T16:00:52Z","receivedAt":"2006-06-01T16:00:52Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nI have the following problem:\n\n\nnbg1l001:~/src/git > git branch\n* master\n  next\n  origin\nnbg1l001:~/src/git > git checkout -b test\nnbg1l001:~/src/git > git status\n# On branch refs/heads/test\nnothing to commit\nzsh: exit 1     git status\nnbg1l001:~/src/git > git reset --hard v1.3.3\nnbg1l001:~/src/git > git status\n# On branch refs/heads/test\n#\n# Untracked files:\n#   (use \"git add\" to add to commit)\n#\n#       git-quiltimport\n#       git-upload-tar\nnothing to commit\nzsh: exit 1     git status\nnbg1l001:~/src/git > git reset --hard master\nnbg1l001:~/src/git > git status\n# On branch refs/heads/test\nnothing to commit\nzsh: exit 1     git status\n\nnbg1l001:~/src/git > git --version\ngit version 1.3.3.g0825d\n\n\nHowever, the complete test suite and especially t7101-reset.sh succeed.\nAny ideas?\n\n-- \nMartin Waitz\n"},{"id":"21059","messageId":"BAYC1-PASMTP04B113F61282BAE465D7F0AE900@CEZ.ICE","threadId":"4369","inReplyTo":"20060601160052.GK14325@admingilde.org","subject":"Re: git reset --hard not removing some files","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-06-01T16:13:04Z","receivedAt":"2006-06-01T16:13:04Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 1 Jun 2006 18:00:52 +0200\nMartin Waitz <tali@admingilde.org> wrote:\n\nRemoved your prompt just to make it a bit more readable:\n\n> $ git branch\n> * master\n>   next\n>   origin\n>\n> $ git checkout -b test\n>\n> $ git status\n> # On branch refs/heads/test\n> nothing to commit\n\nThe generated files \"git-quiltimport\" and \"git-upload-tar\" exist at\nthis point.  They are both untracked files and aren't listed because\nthey have entries in the .gitignore file.\n\n> $ git reset --hard v1.3.3\n>\n> $ git status\n> # On branch refs/heads/test\n> #\n> # Untracked files:\n> #   (use \"git add\" to add to commit)\n> #\n> #       git-quiltimport\n> #       git-upload-tar\n> nothing to commit\n\nResetting to version 1.3.3 gets you an old version of the .gitignore\nfile which doesn't ignore these two untracked files.  Reset --hard\ndoesn't remove them because it only deals with tracked files.  Thus,\nthey show up in your status report.\n\n> $ git reset --hard master\n> $ git status\n> # On branch refs/heads/test\n> nothing to commit\n\nReturning to the current version gets you an updated .gitignore and the\ntwo files are no longer listed even though they still exist.\n\n> $ git --version\n> git version 1.3.3.g0825d\n\nThis is the expected behavior regardless of version.\n\nSean\n"},{"id":"21060","messageId":"Pine.LNX.4.64.0606010918060.5498@g5.osdl.org","threadId":"4369","inReplyTo":"20060601160052.GK14325@admingilde.org","subject":"Re: git reset --hard not removing some files","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-01T16:21:38Z","receivedAt":"2006-06-01T16:21:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 1 Jun 2006, Martin Waitz wrote:\n> \n> I have the following problem:\n\nIt's not a problem, it's a feature.\n\n> nbg1l001:~/src/git > git branch\n> * master\n>   next\n>   origin\n> nbg1l001:~/src/git > git checkout -b test\n> nbg1l001:~/src/git > git status\n> # On branch refs/heads/test\n> nothing to commit\n> zsh: exit 1     git status\n> nbg1l001:~/src/git > git reset --hard v1.3.3\n> nbg1l001:~/src/git > git status\n> # On branch refs/heads/test\n> #\n> # Untracked files:\n> #   (use \"git add\" to add to commit)\n> #\n> #       git-quiltimport\n> #       git-upload-tar\n\nThose files were _never_ tracked.\n\nWhat happened is that when you switched to an earlier version, you _also_ \nswitched the \".gitignore\" file to the earlier version, and that older \n.gitignore file doesn't have those two (newer) binaries listed as being \nignored.\n\nAnd \"git reset\" won't be deleting files it doesn't track (it had _better_ \nnot touch them), even more so when it has been told to ignore them, so it \nmakes total sense to _not_ delete them when doing that reset.\n\n\t\t\tLinus\n"},{"id":"21061","messageId":"e5n7lv$3tl$1@sea.gmane.org","threadId":"4369","inReplyTo":"BAYC1-PASMTP04B113F61282BAE465D7F0AE900@CEZ.ICE","subject":"Re: git reset --hard not removing some files","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-06-01T17:21:19Z","receivedAt":"2006-06-01T17:21:19Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sean wrote:\n\n> On Thu, 1 Jun 2006 18:00:52 +0200\n> Martin Waitz <tali@admingilde.org> wrote:\n> \n>> $ git reset --hard v1.3.3\n>>\n>> $ git status\n>> # On branch refs/heads/test\n>> #\n>> # Untracked files:\n>> #   (use \"git add\" to add to commit)\n>> #\n>> #       git-quiltimport\n>> #       git-upload-tar\n>> nothing to commit\n> \n> Resetting to version 1.3.3 gets you an old version of the .gitignore\n> file which doesn't ignore these two untracked files.  Reset --hard\n> doesn't remove them because it only deals with tracked files.  Thus,\n> they show up in your status report.\n\nDo you think it is _frequently_ asked question, worth adding\nto http://git.or.cz/gitwiki/GitFaq ?\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"21062","messageId":"BAYC1-PASMTP02F2FF1D978A880AFDDA1DAE900@CEZ.ICE","threadId":"4369","inReplyTo":"e5n7lv$3tl$1@sea.gmane.org","subject":"Re: git reset --hard not removing some files","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-06-01T19:21:52Z","receivedAt":"2006-06-01T19:21:52Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 01 Jun 2006 19:21:19 +0200\nJakub Narebski <jnareb@gmail.com> wrote:\n\n> Do you think it is _frequently_ asked question, worth adding\n> to http://git.or.cz/gitwiki/GitFaq ?\n\nHi Jakub,\n\nNot sure if it needs to be in the FAQ at this point, but i guess it couldn't\nhurt either.  The man page actually mentions that --hard deals with tracked\nfiles.  An extra example or a more explicit notice about untracked files\nmight be helpful though.\n\nSean\n"},{"id":"21094","messageId":"e5os3i$ei1$1@sea.gmane.org","threadId":"4369","inReplyTo":"BAYC1-PASMTP02F2FF1D978A880AFDDA1DAE900@CEZ.ICE","subject":"Re: git reset --hard not removing some files","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-06-02T08:16:04Z","receivedAt":"2006-06-02T08:16:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sean wrote:\n\n> On Thu, 01 Jun 2006 19:21:19 +0200\n> Jakub Narebski <jnareb@gmail.com> wrote:\n> \n>> Do you think it is _frequently_ asked question, worth adding\n>> to http://git.or.cz/gitwiki/GitFaq ?\n> \n> Not sure if it needs to be in the FAQ at this point, but i guess it couldn't\n> hurt either.  \n\nAdded. See: http://git.or.cz/gitwiki/GitFaq#reset-hard-leaving-files\nFeel free to add examples, correct information, rework it etc.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"21095","messageId":"20060602093736.GL14325@admingilde.org","threadId":"4369","inReplyTo":"Pine.LNX.4.64.0606010918060.5498@g5.osdl.org","subject":"Re: git reset --hard not removing some files","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-06-02T09:37:36Z","receivedAt":"2006-06-02T09:37:36Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Thu, Jun 01, 2006 at 09:21:38AM -0700, Linus Torvalds wrote:\n> Those files were _never_ tracked.\n\nYou are right, I used the wrong demonstration to show my problem.\nI had one problem like this in the linux-kernel and tried to\nreproduce them in the git repository but did it wrong...\n\nGIT reset seems to have a problem when a file is tracked and ignored\nat the same time.\n\nThis fails:\n\ndiff --git a/t/t7101-reset.sh b/t/t7101-reset.sh\nindex a919140..865e0f6 100755\n--- a/t/t7101-reset.sh\n+++ b/t/t7101-reset.sh\n@@ -21,10 +21,12 @@ test_expect_success \\\n      cp ../../COPYING path1/COPYING &&\n      cp ../../COPYING COPYING &&\n      cp ../../COPYING path0/COPYING-TOO &&\n+     echo COPYING > .gitignore &&\n      git-add path1/path2/COPYING &&\n      git-add path1/COPYING &&\n      git-add COPYING &&\n      git-add path0/COPYING-TOO &&\n+     git-add .gitignore &&\n      git-commit -m change -a'\n\n test_expect_success \\\n\n\nThis hit me as the Linux kernel .gitignore includes \".*\" which matches\nall the .gitignore files and so they are not removed when you go\nback to 2.6.13.  But with the new git checks regarding files in\nthe working dir, git then refuses to pull in newer Linux versions\nbecause it would overwrite \".gitignore\".\n\n-- \nMartin Waitz\n"},{"id":"21096","messageId":"BAYC1-PASMTP11DBD87560470F1DA42426AE910@CEZ.ICE","threadId":"4369","inReplyTo":"20060602093736.GL14325@admingilde.org","subject":"Re: git reset --hard not removing some files","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-06-02T10:08:20Z","receivedAt":"2006-06-02T10:08:20Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Fri, 2 Jun 2006 11:37:36 +0200\nMartin Waitz <tali@admingilde.org> wrote:\n\nHi Martin,\n\n> GIT reset seems to have a problem when a file is tracked and ignored\n> at the same time.\n\nI tried to reproduce this problem, but couldn't.\n\n> This fails:\n> \n> diff --git a/t/t7101-reset.sh b/t/t7101-reset.sh\n> index a919140..865e0f6 100755\n> --- a/t/t7101-reset.sh\n> +++ b/t/t7101-reset.sh\n> @@ -21,10 +21,12 @@ test_expect_success \\\n>       cp ../../COPYING path1/COPYING &&\n>       cp ../../COPYING COPYING &&\n>       cp ../../COPYING path0/COPYING-TOO &&\n> +     echo COPYING > .gitignore &&\n>       git-add path1/path2/COPYING &&\n>       git-add path1/COPYING &&\n>       git-add COPYING &&\n>       git-add path0/COPYING-TOO &&\n> +     git-add .gitignore &&\n>       git-commit -m change -a'\n> \n>  test_expect_success \\\n\nThis fails because git-add refuses to mark an ignored file as tracked.\nSo in your altered test above the COPYING file is never tracked.\ngit-reset then does the proper thing and refuses to remove it.  So it's\nstill not demonstrating the case you mention below.\n \n> This hit me as the Linux kernel .gitignore includes \".*\" which matches\n> all the .gitignore files and so they are not removed when you go\n> back to 2.6.13.  But with the new git checks regarding files in\n> the working dir, git then refuses to pull in newer Linux versions\n> because it would overwrite \".gitignore\".\n\nStrange.. this little test shows that tracked files that are ignored\ndo get removed when resetting --hard...\n\n$ mkdir tryit ; cd tryit\n$ git init-db\ndefaulting to local storage area\n\n$ touch one ; git add one\n$ git commit -a -m\"Initial\"\nCommitting initial tree 5fcffbd6e4c5c5b8d81f5e9314b20e338e3ffff5\n\n$ touch .gitignore\n$ git add .gitignore\n$ git commit -a -m\"now we have gitignore\"\n\n$ echo '.*' >> .gitignore\n$ git commit -a -m'now git ignores all .* files'\n\n$ ls -l .gitignore\n-rw-r--r-- 1 sean sean 3 Jun  2 06:01 .gitignore\n\n$ git reset --hard master~2\n$ ls -l .gitignore\nls: .gitignore: No such file or directory\n\n\nSean\n"},{"id":"21101","messageId":"20060602141724.GM14325@admingilde.org","threadId":"4369","inReplyTo":"20060602060820.8eebe391.seanlkml@sympatico.ca","subject":"Re: git reset --hard not removing some files","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-06-02T14:17:24Z","receivedAt":"2006-06-02T14:17:24Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Fri, Jun 02, 2006 at 06:08:20AM -0400, Sean wrote:\n> Strange.. this little test shows that tracked files that are ignored\n> do get removed when resetting --hard...\n\nok, git must be behaving correctly then, I don't know what problem I ran into.\nMust have been some kind of user error...\n\n-- \nMartin Waitz\n"},{"id":"21102","messageId":"7vhd33d2q2.fsf@assigned-by-dhcp.cox.net","threadId":"4369","inReplyTo":"Pine.LNX.4.64.0606010918060.5498@g5.osdl.org","subject":"Re: git reset --hard not removing some files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-02T14:57:57Z","receivedAt":"2006-06-02T14:57:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> On Thu, 1 Jun 2006, Martin Waitz wrote:\n>> \n>> I have the following problem:\n>\n> It's not a problem, it's a feature.\n>...\n> Those files were _never_ tracked.\n\nI would agree in the reproduction recipe Martin gave there is no\nproblem but feature, but at the same time I suspect the recent\n\"reset --hard simplification\" has introduced a true regression.\n\n        $ mkdir test || exit\n        $ cd test || exit\n        $ git init-db\n        defaulting to local storage area\n        $ echo init >file0\n        $ echo init >file1\n        $ git add file0 file1\n        $ git commit -m initial\n        Committing initial tree de84dc367842fdbbb3acad3b3ed252f8c984296f\n        $ git branch side\n        $ rm -f file1\n        $ echo second >file2\n        $ git add file2\n        $ git commit -a -m 'master adds file2 and deletes file1'\n        $ git checkout side\n        $ echo modified >file1\n        $ git commit -a -m 'side edits file1'\n        $ git checkout master\n        $ ls\n        file0  file2\n        $ git pull . side\n        Trying really trivial in-index merge...\n        fatal: Merge requires file-level merging\n        Nope.\n        Merging HEAD with 7934c9c383f611cf2b9895a46cf95b815569beef\n        Merging: \n        b684570dc1141552d0da950a18f2d84a3ffadbc1 master adds file2 and deletes file1 \n        7934c9c383f611cf2b9895a46cf95b815569beef side edits file1 \n        found 1 common ancestor(s): \n        598d6491f72b6057ca87683d43cf64b08d90ddaf initial \n        CONFLICT (delete/modify): file1 deleted in HEAD and modified in 7934c9c383f611cf2b9895a46cf95b815569beef. Version 7934c9c383f611cf2b9895a46cf95b815569beef of file1 left in tree. \n\n        Automatic merge failed; fix conflicts and then commit the result.\n        $ git ls-files -u\n        100644 b1b716105590454bfc4c0247f193a04088f39c7f 1\tfile1\n        100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 3\tfile1\n        $ ls\n        file0  file1  file2\n        $ git reset --hard\n        $ ls\n        file0  file1  file2\n\nWe used to remove file1 from the working tree in this case.  One\nof the most important reason to use \"git reset --hard\" is to\nrecover from a conflicted, failed merge.  \n\nLeaving file1 in the working tree around in this case has\nunpleasant consequences.  After the above:\n\n\t$ git checkout side\n\tfatal: Untracked working tree file 'file1' would be overwritten by merge.\n"},{"id":"21129","messageId":"7vy7we8w1h.fsf@assigned-by-dhcp.cox.net","threadId":"4369","inReplyTo":"7vhd33d2q2.fsf@assigned-by-dhcp.cox.net","subject":"Re: git reset --hard not removing some files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-03T08:48:10Z","receivedAt":"2006-06-03T08:48:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> I would agree in the reproduction recipe Martin gave there is no\n> problem but feature, but at the same time I suspect the recent\n> \"reset --hard simplification\" has introduced a true regression.\n> ...\n>         $ git ls-files -u\n>         100644 b1b716105590454bfc4c0247f193a04088f39c7f 1\tfile1\n>         100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 3\tfile1\n>         $ ls\n>         file0  file1  file2\n>         $ git reset --hard\n>         $ ls\n>         file0  file1  file2\n>\n> We used to remove file1 from the working tree in this case.  One\n> of the most important reason to use \"git reset --hard\" is to\n> recover from a conflicted, failed merge.  \n\nI think this patch fixes the regression.  Comments?\n\n-- >8 --\nread-tree --reset: update working tree file for conflicted paths.\n\nThe earlier \"git reset --hard\" simplification stopped removing\nleftover working tree files from a failed automerge, when\nswitching back to the HEAD version that does not have the\npaths.\n\nThis patch, instead of removing the unmerged paths from the\nindex, drops them down to stage#0 but marks them with mode=0\n(the same \"to be deleted\" marker we internally use for paths\ndeleted by the merge).  one_way_merge() function and the\nfunctions it calls already know what to do with them -- if the\ntree we are reading has the path the working tree file is\noverwritten, and if it doesn't the working tree file is\nremoved.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n builtin-read-tree.c |   19 +++++++++++++++----\n 1 files changed, 15 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin-read-tree.c b/builtin-read-tree.c\nindex 716f792..71edaf6 100644\n--- a/builtin-read-tree.c\n+++ b/builtin-read-tree.c\n@@ -753,6 +753,8 @@ static int read_cache_unmerged(void)\n {\n \tint i, deleted;\n \tstruct cache_entry **dst;\n+\tint unmerged = 0;\n+\tstruct cache_entry *last = NULL;\n \n \tread_cache();\n \tdst = active_cache;\n@@ -760,16 +762,22 @@ static int read_cache_unmerged(void)\n \tfor (i = 0; i < active_nr; i++) {\n \t\tstruct cache_entry *ce = active_cache[i];\n \t\tif (ce_stage(ce)) {\n-\t\t\tdeleted++;\n+\t\t\tunmerged++;\n+\t\t\tif (last && !strcmp(ce->name, last->name)) {\n+\t\t\t\tdeleted++;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tinvalidate_ce_path(ce);\n-\t\t\tcontinue;\n+\t\t\tlast = ce;\n+\t\t\tce->ce_mode = 0;\n+\t\t\tce->ce_flags &= ~htons(CE_STAGEMASK);\n \t\t}\n \t\tif (deleted)\n \t\t\t*dst = ce;\n \t\tdst++;\n \t}\n \tactive_nr -= deleted;\n-\treturn deleted;\n+\treturn unmerged;\n }\n \n static void prime_cache_tree_rec(struct cache_tree *it, struct tree *tree)\n@@ -850,7 +858,10 @@ int cmd_read_tree(int argc, const char *\n \t\t\tcontinue;\n \t\t}\n \n-\t\t/* This differs from \"-m\" in that we'll silently ignore unmerged entries */\n+\t\t/* This differs from \"-m\" in that we'll silently ignore\n+\t\t * unmerged entries and overwrite working tree files that\n+\t\t * correspond to them.\n+\t\t */\n \t\tif (!strcmp(arg, \"--reset\")) {\n \t\t\tif (stage || merge)\n \t\t\t\tusage(read_tree_usage);\n"},{"id":"21136","messageId":"Pine.LNX.4.64.0606030802560.5498@g5.osdl.org","threadId":"4369","inReplyTo":"7vy7we8w1h.fsf@assigned-by-dhcp.cox.net","subject":"Re: git reset --hard not removing some files","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-03T15:11:52Z","receivedAt":"2006-06-03T15:11:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 3 Jun 2006, Junio C Hamano wrote:\n> \n> I think this patch fixes the regression.  Comments?\n\nThe approach looks fine, but with your changes, the \"deleted\" flag makes \nno sense any more and looks redundant. It's not actually used for anything \nexcept deciding if we need to re-write the active_cache[] thing, and you \nmigth as well use either \"last\" or \"unmerged\" for that.\n\n(yeah, \"last\" and \"unmerged\" becomes non-null one entry earlier than \n\"deleted\", but that's actually just confusing, I think, and now depends on \nthe fact that we don't have to re-write the first entry).\n\nThe whole \"*dst++ = ce\" _could_ be unconditional, the only reason I made \nit conditional at all is to avoid dirtying the mmap when not necessary (ie \nit's a performance optimization, and it's not one where that off-by-one \nmatters).\n\nSo I think you could make it clearer by dropping \"deleted\" entirely, and \njust making the store be conditional on \"last\".\n\n\t\t\tLinus\n"},{"id":"21192","messageId":"20060604091601.GN14325@admingilde.org","threadId":"4369","inReplyTo":"7vhd33d2q2.fsf@assigned-by-dhcp.cox.net","subject":"Re: git reset --hard not removing some files","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-06-04T09:16:02Z","receivedAt":"2006-06-04T09:16:02Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Fri, Jun 02, 2006 at 07:57:57AM -0700, Junio C Hamano wrote:\n> I would agree in the reproduction recipe Martin gave there is no\n> problem but feature, but at the same time I suspect the recent\n> \"reset --hard simplification\" has introduced a true regression.\n\nThis may have been the bug that bit me.\nThanks for finding it although I was not able to reproduce it myself!\n\n-- \nMartin Waitz\n"},{"id":"21196","messageId":"7vfyilclna.fsf@assigned-by-dhcp.cox.net","threadId":"4369","inReplyTo":"20060604091601.GN14325@admingilde.org","subject":"Re: git reset --hard not removing some files","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-04T09:31:21Z","receivedAt":"2006-06-04T09:31:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Waitz <tali@admingilde.org> writes:\n\n> hoi :)\n>\n> On Fri, Jun 02, 2006 at 07:57:57AM -0700, Junio C Hamano wrote:\n>> I would agree in the reproduction recipe Martin gave there is no\n>> problem but feature, but at the same time I suspect the recent\n>> \"reset --hard simplification\" has introduced a true regression.\n>\n> This may have been the bug that bit me.\n> Thanks for finding it although I was not able to reproduce it myself!\n\nI found this somewhat the hard way myself.  I have:\n\n        [pull]\n                twohead = resolve\n\nin my .git/config -- IOW, I usually do not use recursive\nstrategy myself.  When a merge with resolve strategy fails (and\nwith recent trend to busyboxify git commands, many merges\nbetween my topics and \"next\" and/or \"master\" do), I relied on\n\"reset --hard\" followed by the same merge of the topic using\n\"pull -s recursive\" to recover things, but it didn't.  When\npulling a branch with builtin-*.c names into another branch with\nolder names, regressed \"reset --hard\" left builtin-*.c files\nbehind, and then the next merge attempt complained by saying my\nuntracked working tree files would be overwritten X-<.\n"}]}