{"thread":{"id":"17293","subject":"Short \"git commit $file\" syntax fails in the face of a resolved conflict","startedAt":"2009-01-21T21:00:36Z","lastAt":"2009-01-23T17:01:32Z","messageCount":17,"participants":["Asheesh Laroia","Michael J Gruber","Nathan Yergler","Johannes Sixt","Nanako Shiraishi","Junio C Hamano","Pieter de Bie"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"101451","messageId":"alpine.DEB.2.00.0901211549070.15860@vellum.laroia.net","threadId":"17293","inReplyTo":null,"subject":"Short \"git commit $file\" syntax fails in the face of a resolved conflict","fromName":"Asheesh Laroia","fromEmail":"asheesh@asheesh.org","sentAt":"2009-01-21T21:00:36Z","receivedAt":"2009-01-21T21:00:36Z","isPatch":false,"sender":{"key":"asheesh@asheesh.org","avatar":"https://avatars.githubusercontent.com/u/25457?v=4"},"body":"I have found what seems to be a bug in the short \"git commit $file\" mode \nof interaction with git. To reproduce it, you can:\n\n1. Create a repository with some content.\n\n \t$ (mkdir a ; cd a ; git init ; echo hi > file ; git add file ; git commit -m 'initial commit')\n \tInitialized empty Git repository in /tmp/playground.2009-01-21.w15613/a/.git/\n \tCreated initial commit 276d6eb: initial commit\n \t 1 files changed, 1 insertions(+), 0 deletions(-)\n \t create mode 100644 file\n\n2. Clone that repository.\n\n \t$ git clone a b\n \tInitialized empty Git repository in /tmp/playground.2009-01-21.w15613/b/.git/\n\n3. Create changes in \"a\" that are not yet cloned into \"b\".\n\n \t$ (cd a ; echo ho > file ; git add file ; git commit -m update)\n \tCreated commit 91deff9: update\n \t 1 files changed, 1 insertions(+), 1 deletions(-)\n\n4. Make changes in \"b\", the clone.\n\n \t$ echo lol > file\n \t$ git add file ; git commit -m 'Some changes'\n \tCreated commit 5d74b5b: Some changes\n \t 1 files changed, 1 insertions(+), 1 deletions(-)\n\n5. Fetch and merge (AKA pull) from the first repo.\n\n \t$ git pull\n \tremote: Counting objects: 5, done.\n \tremote: Total 3 (delta 0), reused 0 (delta 0)\n \tUnpacking objects: 100% (3/3), done.\n \tFrom /tmp/playground.2009-01-21.w15613/a/\n \t   276d6eb..91deff9  master     -> origin/master\n \tAuto-merged file\n \tCONFLICT (content): Merge conflict in file\n \tAutomatic merge failed; fix conflicts and then commit the result.\n\n6. Resolve the conflict (in our case, by discarding the changes in the \"b\" \nclone).\n\n \t$ echo ho > file\n\n7. Commit the resolved conflict.\n\nNOTE: The normal way to do step 6 is to \"git add file ; git commit -m \nyay\". But I will now try to use the \"git commit file\" shorthand:\n\n \t$ git commit file -m 'Resolved conflict'\n \tfatal: cannot do a partial commit during a merge.\n\n8. Declare a bug.\n\nI believe that the \"git commit file\" command issued in step 6 should have \nworked as well as the \"git add file ; git commit\" that us old-time git \nusers do.\n\n9. Discuss on the git list.\n\nDo y'all agree that the git behavior is strange and unnecessarily \nuser-impeding here?\n\nCheers!\n\n-- Asheesh.\n\nP.S. I'm not the one who ran into the bad behavior here; Nathan (CC:d) is \nthe one who did. You don't have to keep him CC:d, though.\n\n-- \nAvoid gunfire in the bathroom tonight.\n"},{"id":"101458","messageId":"49779521.9040208@drmicha.warpmail.net","threadId":"17293","inReplyTo":"alpine.DEB.2.00.0901211549070.15860@vellum.laroia.net","subject":"Re: Short \"git commit $file\" syntax fails in the face of a resolved conflict","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-01-21T21:35:29Z","receivedAt":"2009-01-21T21:35:29Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Asheesh Laroia venit, vidit, dixit 01/21/09 22:00:\n> I have found what seems to be a bug in the short \"git commit $file\" mode \n> of interaction with git. To reproduce it, you can:\n> \n> 1. Create a repository with some content.\n> \n>  \t$ (mkdir a ; cd a ; git init ; echo hi > file ; git add file ; git commit -m 'initial commit')\n>  \tInitialized empty Git repository in /tmp/playground.2009-01-21.w15613/a/.git/\n>  \tCreated initial commit 276d6eb: initial commit\n>  \t 1 files changed, 1 insertions(+), 0 deletions(-)\n>  \t create mode 100644 file\n> \n> 2. Clone that repository.\n> \n>  \t$ git clone a b\n>  \tInitialized empty Git repository in /tmp/playground.2009-01-21.w15613/b/.git/\n> \n> 3. Create changes in \"a\" that are not yet cloned into \"b\".\n> \n>  \t$ (cd a ; echo ho > file ; git add file ; git commit -m update)\n>  \tCreated commit 91deff9: update\n>  \t 1 files changed, 1 insertions(+), 1 deletions(-)\n> \n> 4. Make changes in \"b\", the clone.\n> \n>  \t$ echo lol > file\n>  \t$ git add file ; git commit -m 'Some changes'\n>  \tCreated commit 5d74b5b: Some changes\n>  \t 1 files changed, 1 insertions(+), 1 deletions(-)\n> \n> 5. Fetch and merge (AKA pull) from the first repo.\n> \n>  \t$ git pull\n>  \tremote: Counting objects: 5, done.\n>  \tremote: Total 3 (delta 0), reused 0 (delta 0)\n>  \tUnpacking objects: 100% (3/3), done.\n>  \tFrom /tmp/playground.2009-01-21.w15613/a/\n>  \t   276d6eb..91deff9  master     -> origin/master\n>  \tAuto-merged file\n>  \tCONFLICT (content): Merge conflict in file\n>  \tAutomatic merge failed; fix conflicts and then commit the result.\n> \n> 6. Resolve the conflict (in our case, by discarding the changes in the \"b\" \n> clone).\n> \n>  \t$ echo ho > file\n> \n> 7. Commit the resolved conflict.\n> \n> NOTE: The normal way to do step 6 is to \"git add file ; git commit -m \n> yay\". But I will now try to use the \"git commit file\" shorthand:\n> \n>  \t$ git commit file -m 'Resolved conflict'\n>  \tfatal: cannot do a partial commit during a merge.\n> \n> 8. Declare a bug.\n> \n> I believe that the \"git commit file\" command issued in step 6 should have \n> worked as well as the \"git add file ; git commit\" that us old-time git \n> users do.\n> \n> 9. Discuss on the git list.\n> \n> Do y'all agree that the git behavior is strange and unnecessarily \n> user-impeding here?\n> \n> Cheers!\n> \n> -- Asheesh.\n> \n> P.S. I'm not the one who ran into the bad behavior here; Nathan (CC:d) is \n> the one who did. You don't have to keep him CC:d, though.\n> \n\nYou want git commit -i:\n\n       -i, --include\n           Before making a commit out of staged contents so far, stage\nthe contents of paths given on the command line as well.\n           This is usually not what you want unless you are concluding a\nconflicted merge.\n\nWithout -i, git commit path ignores the index, which would be bad in the\nmiddle of a merge, which is why git refuses to do so. You may argue for\ngit commit to use -i automatically here, but I don't think it's a good idea.\n\nSo, out of\n1) git add path && git commit\n2) git commit path\n3) git commit -i path\nonly 1) and 3) are always equivalent.\n\nMichael\n"},{"id":"101459","messageId":"c1a864630901211346j4b702fb3tcc5a098ed7e1541d@mail.gmail.com","threadId":"17293","inReplyTo":"49779521.9040208@drmicha.warpmail.net","subject":"Re: Short \"git commit $file\" syntax fails in the face of a resolved conflict","fromName":"Nathan Yergler","fromEmail":"nathan@creativecommons.org","sentAt":"2009-01-21T21:46:02Z","receivedAt":"2009-01-21T21:46:02Z","isPatch":false,"sender":{"key":"nathan@creativecommons.org","avatar":null},"body":"Can you elaborate on why doing -i automatically is a bad idea in this\ncase?  [It may really be, I don't pretend to have enough knowledge\nabout git's internals to make a reasoned argument.]  This was\nunexpected behavior for me as I'd always experienced \"git add path &&\ngit commit\" and \"git commit path\" as being equivalent and so I assumed\nthey would work equivalently in this situation.\n\nNathan\n\nOn Wed, Jan 21, 2009 at 1:35 PM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Asheesh Laroia venit, vidit, dixit 01/21/09 22:00:\n>> I have found what seems to be a bug in the short \"git commit $file\" mode\n>> of interaction with git. To reproduce it, you can:\n>>\n>> 1. Create a repository with some content.\n>>\n>>       $ (mkdir a ; cd a ; git init ; echo hi > file ; git add file ; git commit -m 'initial commit')\n>>       Initialized empty Git repository in /tmp/playground.2009-01-21.w15613/a/.git/\n>>       Created initial commit 276d6eb: initial commit\n>>        1 files changed, 1 insertions(+), 0 deletions(-)\n>>        create mode 100644 file\n>>\n>> 2. Clone that repository.\n>>\n>>       $ git clone a b\n>>       Initialized empty Git repository in /tmp/playground.2009-01-21.w15613/b/.git/\n>>\n>> 3. Create changes in \"a\" that are not yet cloned into \"b\".\n>>\n>>       $ (cd a ; echo ho > file ; git add file ; git commit -m update)\n>>       Created commit 91deff9: update\n>>        1 files changed, 1 insertions(+), 1 deletions(-)\n>>\n>> 4. Make changes in \"b\", the clone.\n>>\n>>       $ echo lol > file\n>>       $ git add file ; git commit -m 'Some changes'\n>>       Created commit 5d74b5b: Some changes\n>>        1 files changed, 1 insertions(+), 1 deletions(-)\n>>\n>> 5. Fetch and merge (AKA pull) from the first repo.\n>>\n>>       $ git pull\n>>       remote: Counting objects: 5, done.\n>>       remote: Total 3 (delta 0), reused 0 (delta 0)\n>>       Unpacking objects: 100% (3/3), done.\n>>       From /tmp/playground.2009-01-21.w15613/a/\n>>          276d6eb..91deff9  master     -> origin/master\n>>       Auto-merged file\n>>       CONFLICT (content): Merge conflict in file\n>>       Automatic merge failed; fix conflicts and then commit the result.\n>>\n>> 6. Resolve the conflict (in our case, by discarding the changes in the \"b\"\n>> clone).\n>>\n>>       $ echo ho > file\n>>\n>> 7. Commit the resolved conflict.\n>>\n>> NOTE: The normal way to do step 6 is to \"git add file ; git commit -m\n>> yay\". But I will now try to use the \"git commit file\" shorthand:\n>>\n>>       $ git commit file -m 'Resolved conflict'\n>>       fatal: cannot do a partial commit during a merge.\n>>\n>> 8. Declare a bug.\n>>\n>> I believe that the \"git commit file\" command issued in step 6 should have\n>> worked as well as the \"git add file ; git commit\" that us old-time git\n>> users do.\n>>\n>> 9. Discuss on the git list.\n>>\n>> Do y'all agree that the git behavior is strange and unnecessarily\n>> user-impeding here?\n>>\n>> Cheers!\n>>\n>> -- Asheesh.\n>>\n>> P.S. I'm not the one who ran into the bad behavior here; Nathan (CC:d) is\n>> the one who did. You don't have to keep him CC:d, though.\n>>\n>\n> You want git commit -i:\n>\n>       -i, --include\n>           Before making a commit out of staged contents so far, stage\n> the contents of paths given on the command line as well.\n>           This is usually not what you want unless you are concluding a\n> conflicted merge.\n>\n> Without -i, git commit path ignores the index, which would be bad in the\n> middle of a merge, which is why git refuses to do so. You may argue for\n> git commit to use -i automatically here, but I don't think it's a good idea.\n>\n> So, out of\n> 1) git add path && git commit\n> 2) git commit path\n> 3) git commit -i path\n> only 1) and 3) are always equivalent.\n>\n> Michael\n>\n"},{"id":"101507","messageId":"4978202C.3090703@viscovery.net","threadId":"17293","inReplyTo":"c1a864630901211346j4b702fb3tcc5a098ed7e1541d@mail.gmail.com","subject":"Re: Short \"git commit $file\" syntax fails in the face of a resolved conflict","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-01-22T07:28:44Z","receivedAt":"2009-01-22T07:28:44Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Please don't top-post.\n\nNathan Yergler schrieb:\n> Can you elaborate on why doing -i automatically is a bad idea in this\n> case?  [It may really be, I don't pretend to have enough knowledge\n> about git's internals to make a reasoned argument.]  This was\n> unexpected behavior for me as I'd always experienced \"git add path &&\n> git commit\" and \"git commit path\" as being equivalent and so I assumed\n> they would work equivalently in this situation.\n\nThey are not equivalent. 'git add path && git commit' commits changes to\npath *in addition* to what is already staged before you run this command\nsequence. But 'git commit path' commits *only* changes to path, leaving\nother changes that might be staged uncommitted.\n\nIt may become obvious why the latter behavior is unwanted if a merge is in\nprogress: The merge left changes (and conflicts) in the index; but with\n'git commit path' you say that you are not interested in what the index has.\n\n-- Hannes\n"},{"id":"101513","messageId":"49783998.1040400@drmicha.warpmail.net","threadId":"17293","inReplyTo":"c1a864630901211346j4b702fb3tcc5a098ed7e1541d@mail.gmail.com","subject":"Re: Short \"git commit $file\" syntax fails in the face of a resolved conflict","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-01-22T09:17:12Z","receivedAt":"2009-01-22T09:17:12Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Nathan Yergler venit, vidit, dixit 21.01.2009 22:46:\n> Can you elaborate on why doing -i automatically is a bad idea in this\n> case?  [It may really be, I don't pretend to have enough knowledge\n> about git's internals to make a reasoned argument.]  This was\n> unexpected behavior for me as I'd always experienced \"git add path &&\n> git commit\" and \"git commit path\" as being equivalent and so I assumed\n> they would work equivalently in this situation.\n\nBecause it makes it hard to follow the discussion.\n\nWhy shouldn't I?\n\nFist of all: Please don't top post.\n\n;)\n\nThat being said: As Johannes 6t explained (in agreement with git help\ncommit), \"git commit path\" - which is synonymous with \"git commit -o\npath\" is a way of bypassing the index. Think of \"Oh wait, I wanted to\ncommit that before I commit what I'm preparing right now.\". Now,\nbypassing the index is no big deal, but bypassing a merge in progress\nis, because a merge in progress leaves more traces than just the index\nstate (e.g. MERGE_HEAD). That's also why this use case is mentioned\nexplicitly in the man page... In fact, rereading that man page (and\ntesting things to be on the safe side) I have to correct myself: Out of\n\n1) git add path && git commit\n2) git commit path\n3) git commit -i path\n\nnone are equivalent! 1) and 3) are equivalent if and only if \"path\" is\nknown to git already: git commit -i does not add new paths.\n2) and 3) are equivalent if and only if the index is empty (no changes\nstaged). The question \"When are 1) and 2)\" equivalent is left as an\nexercise in elementary logic. ;)\n\nCheers,\nMichael\n"},{"id":"101587","messageId":"20090123094509.6117@nanako3.lavabit.com","threadId":"17293","inReplyTo":"4978202C.3090703@viscovery.net","subject":"Re: Short \"git commit $file\" syntax fails in the face of a resolved conflict","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-01-23T00:45:09Z","receivedAt":"2009-01-23T00:45:09Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Johannes Sixt <j.sixt@viscovery.net>:\n\n> Please don't top-post.\n>\n> Nathan Yergler schrieb:\n>> Can you elaborate on why doing -i automatically is a bad idea in this\n>> case?  [It may really be, I don't pretend to have enough knowledge\n>> about git's internals to make a reasoned argument.]  This was\n>> unexpected behavior for me as I'd always experienced \"git add path &&\n>> git commit\" and \"git commit path\" as being equivalent and so I assumed\n>> they would work equivalently in this situation.\n>\n> They are not equivalent. 'git add path && git commit' commits changes to\n> path *in addition* to what is already staged before you run this command\n> sequence. But 'git commit path' commits *only* changes to path, leaving\n> other changes that might be staged uncommitted.\n>\n> It may become obvious why the latter behavior is unwanted if a merge is in\n> progress: The merge left changes (and conflicts) in the index; but with\n> 'git commit path' you say that you are not interested in what the index has.\n\nYour explanation is a good answer to Nathan's misunderstanding; \"git add path && git commit\" and \"git commit path\" are different.\n\nBut Nathan's first sentence is a different matter. I do not think it is coming from the same confusion, and I think the question is a valid one. Your answer does not explain why it is a bad idea to change the behavior of \"git commit path\" to what \"git commit -i path\" does during a merge.\n\nThe answer of course can be \"because it changes the behavior people are very much used to.\"\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"101601","messageId":"alpine.DEB.2.00.0901222101520.14992@vellum.laroia.net","threadId":"17293","inReplyTo":"20090123094509.6117@nanako3.lavabit.com","subject":"Re: Short \"git commit $file\" syntax fails in the face of a resolved conflict","fromName":"Asheesh Laroia","fromEmail":"asheesh@asheesh.org","sentAt":"2009-01-23T02:55:25Z","receivedAt":"2009-01-23T02:55:25Z","isPatch":false,"sender":{"key":"asheesh@asheesh.org","avatar":"https://avatars.githubusercontent.com/u/25457?v=4"},"body":"On Fri, 23 Jan 2009, Nanako Shiraishi wrote:\n\n> Your explanation is a good answer to Nathan's misunderstanding; \"git add \n> path && git commit\" and \"git commit path\" are different.\n>\n> But Nathan's first sentence is a different matter.\n\nThanks for seeing this!\n\n> I do not think it is coming from the same confusion, and I think the \n> question is a valid one. Your answer does not explain why it is a bad \n> idea to change the behavior of \"git commit path\" to what \"git commit -i \n> path\" does during a merge.\n\nDuring a merge where the file called \"file\" is in conflict, I don't see \nwhy the internal mechanism of how a merge gets resolved is important to \nusers like Nathan.\n\nSure, the index is nice, but let's look at the choices here.  When he runs\n$ git commit file -m 'fixed conflict'\ngit can do one of two things:\n\n(a) Fail with an obscure (or less obscure) error message, or\n(b) Succeed.\n\nThe way in which it can suceed is unambiguous. Now, in the case of more \nthan one file being in conflict, it makes sense to abort; success isn't \npossible. But in this case, no one really benefits from the user having to \ntype something else to have the command actually succeed.\n\nThose are my thoughts.\n\n> The answer of course can be \"because it changes the behavior people are \n> very much used to.\"\n\nI don't think anyone is \"very much used to\" this error message, or that \nmaking something succeed in the only possible way is going to confuse \nanyone. If you're worried about confusing people, git could print a note \nlike:\n\n \t$ git commit file -m \"Fixed conflict\"\n \tNOTE: Merge was in progress. If you have more than one file in conflict\n \tin a future merge, be sure to \"git add\" each file separately and then\n \tcommit them all at once.\n \tCreated commit 12ede36: Fixed conflict\n \t 0 files changed, 0 insertions(+), 0 deletions(-)\n \t create mode 100644 file\n \t$\n\n-- Asheesh.\n\n-- \nIn the Spring, I have counted 136 different kinds of weather inside of\n24 hours.\n \t\t-- Mark Twain, on New England weather\n"},{"id":"101614","messageId":"7viqo64kfo.fsf@gitster.siamese.dyndns.org","threadId":"17293","inReplyTo":"20090123094509.6117@nanako3.lavabit.com","subject":"Re: Short \"git commit $file\" syntax fails in the face of a resolved conflict","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-23T06:15:39Z","receivedAt":"2009-01-23T06:15:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi <nanako3@lavabit.com> writes:\n\n> But Nathan's first sentence is a different matter. I do not think it is\n> coming from the same confusion, and I think the question is a valid\n> one. Your answer does not explain why it is a bad idea to change the\n> behavior of \"git commit path\" to what \"git commit -i path\" does during a\n> merge.\n>\n> The answer of course can be \"because it changes the behavior people are\n> very much used to.\"\n\n[jc: how many times do I have to ask you to wrap your lines, by the way?]\n\nI tend to agree that \"very much used to\" argument carries much weight, but\nI'll be sending a three-patch series to weatherbaloon the idea.\n"},{"id":"101615","messageId":"7vbpty4kby.fsf_-_@gitster.siamese.dyndns.org","threadId":"17293","inReplyTo":"7viqo64kfo.fsf@gitster.siamese.dyndns.org","subject":"[PATCH 1/3] Add \"partial commit\" tests during a conflicted merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-23T06:17:53Z","receivedAt":"2009-01-23T06:17:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"We are supposed to reject \"--only path...\" aka \"a partial commit\" during a\nconflicted merge resolution, and accept \"--include path...\" aka \"an also\ncommit\" in such a case.\n\nRecent git (since v1.3.0) always assumes that \"git commit\" with paths but\nwithout --only nor --include requests the \"--only\" semantics, but there is\na discussion that it might be a good idea to assume \"--include\" semantics\nduring a merge.\n\nThe last test this commit adds expects such a behaviour and marked as\n\"expect_failure\".  It will be changed by the third patch in the series.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n t/t7501-commit.sh |   44 ++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 44 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t7501-commit.sh b/t/t7501-commit.sh\nindex b4e2b4d..0c10105 100755\n--- a/t/t7501-commit.sh\n+++ b/t/t7501-commit.sh\n@@ -365,4 +365,48 @@ test_expect_success 'amend using the message from a commit named with tag' '\n \n '\n \n+test_expect_success 'setup merge commit with paths test' '\n+\tgit reset --hard &&\n+\tgit checkout HEAD^0 &&\n+\techo frotz >file &&\n+\ttest_tick &&\n+\tgit add file &&\n+\tgit commit -a -m \"one side says frotz\" &&\n+\tgit tag one-side-says-frotz &&\n+\tgit reset --hard HEAD^ &&\n+\techo nitfol >file &&\n+\ttest_tick &&\n+\tgit add file &&\n+\tgit commit -a -m \"the other side says nitfol\" &&\n+\tgit tag the-other-side-says-nitfol\n+'\n+\n+test_expect_success 'reject --only during a merge' '\n+\tgit checkout HEAD^0 &&\n+\tgit reset --hard the-other-side-says-nitfol &&\n+\ttest_must_fail git merge one-side-says-frotz &&\n+\techo yomin-only >file &&\n+\ttest_must_fail git commit -m merge --only file &&\n+\tgit reset --hard\n+'\n+\n+test_expect_success 'allow --include during a merge' '\n+\tgit checkout HEAD^0 &&\n+\tgit reset --hard the-other-side-says-nitfol &&\n+\ttest_must_fail git merge one-side-says-frotz &&\n+\techo yomin-include >file &&\n+\tgit commit -m merge --include file &&\n+\tgit reset --hard\n+'\n+\n+test_expect_failure 'assume --include during a merge' '\n+\tgit checkout HEAD^0 &&\n+\tgit reset --hard the-other-side-says-nitfol &&\n+\ttest_must_fail git merge one-side-says-frotz &&\n+\techo yomin-assumed >file &&\n+\tgit add file &&\n+\tgit commit -m merge file &&\n+\tgit reset --hard\n+'\n+\n test_done\n-- \n1.6.1.265.g9a013\n"},{"id":"101616","messageId":"7v63k64k9z.fsf_-_@gitster.siamese.dyndns.org","threadId":"17293","inReplyTo":"7viqo64kfo.fsf@gitster.siamese.dyndns.org","subject":"[PATCH 2/3] builtin-commit: shorten eye-sore overlong lines","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-23T06:19:04Z","receivedAt":"2009-01-23T06:19:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This does not change anything other than the way the variable to hold\nan informative message thrown in the commit log buffer is assigned.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n * This does not really belong to the series in the sense that it is\n   needed to implement the new semantics, but these long lines have always\n   bothered me.\n\n builtin-commit.c |   27 +++++++++++++++++++++++++--\n 1 files changed, 25 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex 7aaa530..d861263 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -71,6 +71,29 @@ static int use_editor = 1, initial_commit, in_merge;\n static const char *only_include_assumed;\n static struct strbuf message;\n \n+enum {\n+\tMSG_AMEND_CLEVER,\n+\tMSG_ASSUME_PARTIAL,\n+};\n+\n+static void set_partial_commit_message(int msgnum)\n+{\n+\tconst char *msg;\n+\n+\tswitch (msgnum) {\n+\tcase MSG_AMEND_CLEVER:\n+\t\tmsg = \"Clever... amending the last one with dirty index.\";\n+\t\tbreak;\n+\tcase MSG_ASSUME_PARTIAL:\n+\t\tmsg = \"Explicit paths specified without -i nor -o; assuming --only paths...\";\n+\t\tbreak;\n+\tdefault:\n+\t\tdie(\"Oops (%d) is not a valid message number\", msgnum);\n+\t\tbreak;\n+\t}\n+\tonly_include_assumed = msg;\n+}\n+\n static int opt_parse_m(const struct option *opt, const char *arg, int unset)\n {\n \tstruct strbuf *buf = opt->value;\n@@ -788,9 +811,9 @@ static int parse_and_validate_options(int argc, const char *argv[],\n \tif (argc == 0 && (also || (only && !amend)))\n \t\tdie(\"No paths with --include/--only does not make sense.\");\n \tif (argc == 0 && only && amend)\n-\t\tonly_include_assumed = \"Clever... amending the last one with dirty index.\";\n+\t\tset_partial_commit_message(MSG_AMEND_CLEVER);\n \tif (argc > 0 && !also && !only)\n-\t\tonly_include_assumed = \"Explicit paths specified without -i nor -o; assuming --only paths...\";\n+\t\tset_partial_commit_message(MSG_ASSUME_PARTIAL);\n \tif (!cleanup_arg || !strcmp(cleanup_arg, \"default\"))\n \t\tcleanup_mode = use_editor ? CLEANUP_ALL : CLEANUP_SPACE;\n \telse if (!strcmp(cleanup_arg, \"verbatim\"))\n-- \n1.6.1.265.g9a013\n"},{"id":"101618","messageId":"7vy6x235ky.fsf_-_@gitster.siamese.dyndns.org","threadId":"17293","inReplyTo":"7viqo64kfo.fsf@gitster.siamese.dyndns.org","subject":"[PATCH 3/3] git commit: pathspec without -i/-o implies -i semantics during a merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-23T06:21:49Z","receivedAt":"2009-01-23T06:21:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"git commit paths...\" has been a short-hand for \"git commit -o paths...\"\nsince v1.3.0 and let you create a commit skipping any other updated state\nstaged in the index.  The \"--only\" semantics (aka \"partial commit\") is\nalways wrong during a conflicted merge resolution, and we rejected both\n\"git commit paths...\"  and \"git commit -o paths...\"  forms during a merge.\n\nOn the other hand, \"git commit -i paths...\" (aka \"an also commit\", which\nasks to commit what you staged in the index, and also the paths you may or\nmay not have git-add'ed) is accepted, as it is a way to register the\ncontents you fixed up to the index and commit the result.\n\nThis makes \"git commit paths...\" form default to \"git commit -i paths\"\nsemantics only during a merge, restoring the pre-v1.3.0 behaviour.  The\ncodepath to create a non-merge commit is not affected and still defaults\nto the \"--only\" semantics.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n builtin-commit.c  |   14 ++++++++++++--\n t/t7501-commit.sh |    2 +-\n 2 files changed, 13 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex d861263..4cb1985 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -74,6 +74,7 @@ static struct strbuf message;\n enum {\n \tMSG_AMEND_CLEVER,\n \tMSG_ASSUME_PARTIAL,\n+\tMSG_ASSUME_ALSO_DURING_MERGE\n };\n \n static void set_partial_commit_message(int msgnum)\n@@ -87,6 +88,9 @@ static void set_partial_commit_message(int msgnum)\n \tcase MSG_ASSUME_PARTIAL:\n \t\tmsg = \"Explicit paths specified without -i nor -o; assuming --only paths...\";\n \t\tbreak;\n+\tcase MSG_ASSUME_ALSO_DURING_MERGE:\n+\t\tmsg = \"Paths specified without -i nor -o during a merge; assuming -i\";\n+\t\tbreak;\n \tdefault:\n \t\tdie(\"Oops (%d) is not a valid message number\", msgnum);\n \t\tbreak;\n@@ -812,8 +816,14 @@ static int parse_and_validate_options(int argc, const char *argv[],\n \t\tdie(\"No paths with --include/--only does not make sense.\");\n \tif (argc == 0 && only && amend)\n \t\tset_partial_commit_message(MSG_AMEND_CLEVER);\n-\tif (argc > 0 && !also && !only)\n-\t\tset_partial_commit_message(MSG_ASSUME_PARTIAL);\n+\tif (argc > 0 && !also && !only) {\n+\t\tif (!in_merge)\n+\t\t\tset_partial_commit_message(MSG_ASSUME_PARTIAL);\n+\t\telse {\n+\t\t\tset_partial_commit_message(MSG_ASSUME_ALSO_DURING_MERGE);\n+\t\t\talso = 1;\n+\t\t}\n+\t}\n \tif (!cleanup_arg || !strcmp(cleanup_arg, \"default\"))\n \t\tcleanup_mode = use_editor ? CLEANUP_ALL : CLEANUP_SPACE;\n \telse if (!strcmp(cleanup_arg, \"verbatim\"))\ndiff --git a/t/t7501-commit.sh b/t/t7501-commit.sh\nindex 0c10105..68892de 100755\n--- a/t/t7501-commit.sh\n+++ b/t/t7501-commit.sh\n@@ -399,7 +399,7 @@ test_expect_success 'allow --include during a merge' '\n \tgit reset --hard\n '\n \n-test_expect_failure 'assume --include during a merge' '\n+test_expect_success 'assume --include during a merge' '\n \tgit checkout HEAD^0 &&\n \tgit reset --hard the-other-side-says-nitfol &&\n \ttest_must_fail git merge one-side-says-frotz &&\n-- \n1.6.1.265.g9a013\n"},{"id":"101621","messageId":"49796D0C.5070408@viscovery.net","threadId":"17293","inReplyTo":"7vbpty4kby.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/3] Add \"partial commit\" tests during a conflicted merge","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-01-23T07:09:00Z","receivedAt":"2009-01-23T07:09:00Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> +test_expect_success 'setup merge commit with paths test' '\n> +\tgit reset --hard &&\n> +\tgit checkout HEAD^0 &&\n> +\techo frotz >file &&\n> +\ttest_tick &&\n> +\tgit add file &&\n> +\tgit commit -a -m \"one side says frotz\" &&\n> +\tgit tag one-side-says-frotz &&\n> +\tgit reset --hard HEAD^ &&\n> +\techo nitfol >file &&\n> +\ttest_tick &&\n> +\tgit add file &&\n> +\tgit commit -a -m \"the other side says nitfol\" &&\n> +\tgit tag the-other-side-says-nitfol\n> +'\n> +\n> +test_expect_success 'reject --only during a merge' '\n> +\tgit checkout HEAD^0 &&\n> +\tgit reset --hard the-other-side-says-nitfol &&\n> +\ttest_must_fail git merge one-side-says-frotz &&\n> +\techo yomin-only >file &&\n> +\ttest_must_fail git commit -m merge --only file &&\n\nI don't see why this must fail: 'file' is the only file that is different\nfrom HEAD. Yes, currently we fail; but if something is about to be\nchanged, then this can change as well.\n\n> +\tgit reset --hard\n> +'\n> +\n> +test_expect_success 'allow --include during a merge' '\n> +\tgit checkout HEAD^0 &&\n> +\tgit reset --hard the-other-side-says-nitfol &&\n> +\ttest_must_fail git merge one-side-says-frotz &&\n> +\techo yomin-include >file &&\n> +\tgit commit -m merge --include file &&\n> +\tgit reset --hard\n> +'\n> +\n> +test_expect_failure 'assume --include during a merge' '\n> +\tgit checkout HEAD^0 &&\n> +\tgit reset --hard the-other-side-says-nitfol &&\n> +\ttest_must_fail git merge one-side-says-frotz &&\n> +\techo yomin-assumed >file &&\n> +\tgit add file &&\n> +\tgit commit -m merge file &&\n> +\tgit reset --hard\n> +'\n\nIf I read the test case correctly, there is only 'file' that is different\nfrom HEAD, and it had a conflict. But IMO, the test should stress the\npoint that after the conflicted merge there are at least two files that\nare different from HEAD, one was trivially merged, and the other had a\nconflict.\n\n-- Hannes\n"},{"id":"101622","messageId":"7vab9i331g.fsf@gitster.siamese.dyndns.org","threadId":"17293","inReplyTo":"49796D0C.5070408@viscovery.net","subject":"Re: [PATCH 1/3] Add \"partial commit\" tests during a conflicted merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-23T07:16:43Z","receivedAt":"2009-01-23T07:16:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j.sixt@viscovery.net> writes:\n\n>> +test_expect_success 'reject --only during a merge' '\n>> +\tgit checkout HEAD^0 &&\n>> +\tgit reset --hard the-other-side-says-nitfol &&\n>> +\ttest_must_fail git merge one-side-says-frotz &&\n>> +\techo yomin-only >file &&\n>> +\ttest_must_fail git commit -m merge --only file &&\n>\n> I don't see why this must fail: 'file' is the only file that is different\n> from HEAD. Yes, currently we fail; but if something is about to be\n> changed, then this can change as well.\n\nNot at all.\n\nAvoiding --only is to prevent a much more dangerous glitch.\n\nSuppose you and the other have two paths diverged, and one merges cleanly\nand the other results in conflict.  When \"git merge\" gives control back to\nyou, the cleanly merged result is ALREADY IN THE INDEX.\n\nNow you futz with the other path, and say\n\n\tgit commit --only other\n\nWhat --only tells git is \"I do not care what I've staged in the index.\nStart from the contents of HEAD commit, and update the index entry at these\npaths (and these path _ONLY_), and commit the contents registered in the\nindex.\n\nThat is why --include is the only sane semantics during a conflicted\nmerge.  I thought you should know better, as you were the one who gave the\nexplanation to Nathan, which triggered Nana's response, which resulted in\nthis series.\n"},{"id":"101624","messageId":"4979727F.80007@viscovery.net","threadId":"17293","inReplyTo":"7vab9i331g.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/3] Add \"partial commit\" tests during a conflicted merge","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-01-23T07:32:15Z","receivedAt":"2009-01-23T07:32:15Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> Johannes Sixt <j.sixt@viscovery.net> writes:\n> \n>>> +test_expect_success 'reject --only during a merge' '\n>>> +\tgit checkout HEAD^0 &&\n>>> +\tgit reset --hard the-other-side-says-nitfol &&\n>>> +\ttest_must_fail git merge one-side-says-frotz &&\n>>> +\techo yomin-only >file &&\n>>> +\ttest_must_fail git commit -m merge --only file &&\n>> I don't see why this must fail: 'file' is the only file that is different\n>> from HEAD. Yes, currently we fail; but if something is about to be\n>> changed, then this can change as well.\n> \n> Not at all.\n\nRead again what I said: 'file' is the *ONLY* file that is different from\nHEAD. Why should an explicit --only not work in this case?\n\n> Avoiding --only is to prevent a much more dangerous glitch.\n[...]\n\nWe are in total agreement about what you said in the rest of the message.\n\nI'm proposing that, during a merge, if --only was given (or remains the\nimplicit choice), then we compare the index with HEAD, and if nothing\noutside the given pathspec differs from HEAD, then allow the commit.\n\n-- Hannes\n"},{"id":"101626","messageId":"7vskna1nes.fsf@gitster.siamese.dyndns.org","threadId":"17293","inReplyTo":"4979727F.80007@viscovery.net","subject":"Re: [PATCH 1/3] Add \"partial commit\" tests during a conflicted merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-23T07:39:39Z","receivedAt":"2009-01-23T07:39:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j.sixt@viscovery.net> writes:\n\n> Read again what I said: 'file' is the *ONLY* file that is different from\n> HEAD. Why should an explicit --only not work in this case?\n\nI know what you said.\n\nIf you study the codepath, the code does not know nor care if 'file' is\nthe only one or if there are other changed paths.\n\nToo much additional code is needed and for too little gain.\n"},{"id":"101648","messageId":"53513726-CE1C-4487-B775-440C6DC93DD8@ai.rug.nl","threadId":"17293","inReplyTo":"7vy6x235ky.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH 3/3] git commit: pathspec without -i/-o implies -i semantics during a merge","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2009-01-23T09:51:41Z","receivedAt":"2009-01-23T09:51:41Z","isPatch":true,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 23 jan 2009, at 06:21, Junio C Hamano wrote:\n\n> This makes \"git commit paths...\" form default to \"git commit -i paths\"\n> semantics only during a merge, restoring the pre-v1.3.0 behaviour.   \n> The\n> codepath to create a non-merge commit is not affected and still  \n> defaults\n> to the \"--only\" semantics.\n\nDo you really want to do this? I think this is a pretty large change\nthat can bite users if they don't know about this -- for example,  \nbecause\nthey forgot that they are in a merge (it happens..).\n\nFWIW, I'd much rather see a useful error message than this change. If\nthis change does get in, I think it should be well-documented in the\nman pages as well as in the release notes.\n\n- Pieter\n"},{"id":"101665","messageId":"7vy6x2vtw3.fsf@gitster.siamese.dyndns.org","threadId":"17293","inReplyTo":"53513726-CE1C-4487-B775-440C6DC93DD8@ai.rug.nl","subject":"Re: [PATCH 3/3] git commit: pathspec without -i/-o implies -i semantics during a merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-23T17:01:32Z","receivedAt":"2009-01-23T17:01:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pieter de Bie <pdebie@ai.rug.nl> writes:\n\n> On 23 jan 2009, at 06:21, Junio C Hamano wrote:\n>\n>> This makes \"git commit paths...\" form default to \"git commit -i paths\"\n>> semantics only during a merge, restoring the pre-v1.3.0 behaviour.\n>> The\n>> codepath to create a non-merge commit is not affected and still\n>> defaults\n>> to the \"--only\" semantics.\n>\n> Do you really want to do this? I think this is a pretty large change\n> that can bite users if they don't know about this -- for example,\n> because\n> they forgot that they are in a merge (it happens..).\n>\n> FWIW, I'd much rather see a useful error message than this change. If\n> this change does get in, I think it should be well-documented in the\n> man pages as well as in the release notes.\n\nAs I said already in an earlier message in this thread, this is only a\nweatherballoon series to help facilitate the discussion, and I am not\nstrongly in favor of this.  In fact, if I were, I would have done that\nlong time ago around v1.3.0, because there was a discussion about doing\nthis and the concensus back then was that the command changing the default\nbehaviour between -i and -o was too confusing, even though it may be\ndwimming better.\n\nThe onus is upon those who argued that \"commit paths\" should default to\nthe --include semantics during a merge resolution in this thread to\nimprove the documentation, if they want this to go forward.\n"}]}