{"thread":{"id":"9854","subject":"Re: [PATCH] git-commit: Allow partial commit of file removal.","startedAt":"2007-09-14T23:34:33Z","lastAt":"2007-09-14T23:34:33Z","messageCount":1,"participants":["Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"53082","messageId":"7vveac95yu.fsf@gitster.siamese.dyndns.org","threadId":"9854","inReplyTo":"7vzlzqieko.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-commit: Allow partial commit of file removal.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-14T23:34:33Z","receivedAt":"2007-09-14T23:34:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Gerrit Pape <pape@smarden.org> writes:\n>\n>> On Wed, Sep 12, 2007 at 04:04:22PM -0700, Junio C Hamano wrote:\n>>>  * In my earlier reply to Gerrit, I hinted that we need to\n>>>    update the pathspec semantics in ls-tree to properly fix this\n>>>    issue.  I cheated here and have ls-files apply its pathspec\n>>>    semantics to the entries from HEAD as well.\n>>\n>> This fixes the problem reported through http://bugs.debian.org/437817\n>> just fine, thanks.  Is this an interims-fix, or should the new option\n>> be documented?\n>\n> I honestly am not convinced it is the right fix.  It has a few\n> holes in the logic.\n>\n> Most notably, I think \"git rm --cached A; git commit A\" would\n> not work.\n\nI managed to convince myself that not committing the removal of\nA in that case is a _good_ thing, unless somebody comes up with\na good counterexample this will most likely go to 'master' over\nthe weekend and then to 'maint'.\n\nAny partial commit \"git commit <paths>...\" is saying:\n\n\tI might have changed stuff in the index and also have\n\tchanges in the working tree.  But I do not care about\n\tthe changes between HEAD and the index.  Honestly, I do\n\tnot understand the index at all, and I do not care about\n\twhat I staged earlier to the named paths either.  Take\n\tthe current state of these paths from my work tree and\n\tmake a commit relative to the HEAD.\n\nSo, if you do:\n\n\t$ edit new-file old-file\n        $ rm gone-file\n        $ git rm missing-file\n        $ git rm --cached disappeared-file\n\t$ git add new-file ;# was not in HEAD\n        $ edit new-file old-file\n\nThen:\n\n\t$ git commit new-file old-file\n\nhonors what is in the work tree and picks up the later edits,\nlargely ignoring the changes to the index.\n\nRemoval should work the same way to be consistent.\n\n\t$ git commit gone-file\n\t$ git commit missing-file\n\t$ git commit disappeared-file\n\nshould remove the former two but leave the last one alone, as\nyou _do_ still have disappeared-file in the work tree.\n\nAs it happens, the version I sent will error out on the last one\n(disappeared-file case).  I think the following patch on top of\nit \"fixes\" it, by adding it back to the index and including its\ncontents in the resulting commit.\n\n\n---\ndiff --git a/git-commit.sh b/git-commit.sh\nindex 5ea3fd0..bb113e8 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -404,7 +404,7 @@ t,)\n \t\t(\n \t\t\tGIT_INDEX_FILE=\"$NEXT_INDEX\"\n \t\t\texport GIT_INDEX_FILE\n-\t\t\tgit update-index --remove --stdin\n+\t\t\tgit update-index --add --remove --stdin\n \t\t) || exit\n \t\t;;\n \tesac\n"}]}