{"thread":{"id":"15932","subject":"Re: commiting while the current version is in conflict","startedAt":"2008-10-16T23:39:53Z","lastAt":"2008-10-17T09:36:28Z","messageCount":7,"participants":["Junio Hamano","Richard Hartmann","Junio C Hamano","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"93256","messageId":"7vy70of6t2.fsf@arte.twinsun.com","threadId":"15932","inReplyTo":null,"subject":"Re: commiting while the current version is in conflict","fromName":"Junio Hamano","fromEmail":"junio@twinsun.com","sentAt":"2008-10-16T23:39:53Z","receivedAt":"2008-10-16T23:39:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"> Judging from the code in the pre-commit script, git does not\n> keep conflict information in its metadata cache, but tries to guess\n> conflicts from the file's contents/ This seems to be a strange\n> thing to do, imo. What's the reason for this?\n\nBecause \n\n (0) You are wrong to assume that git does not keep conflict\n information; we can tell if the index is \"unmerged\" to see\n if you still have unresolved conflicts;\n\n (1) When the index is unmerged, git-commit will stop even\n before getting to pre-commit hook, so there is no point\n for pre-commit hook to check if the index is unmerged;\n\n (2) pre-commit hook is a last ditch effort to help ignorant\n users who have already done \"git add\" without thinking and\n lost the \"unmerged\" state. It has to look at and guess at\n the contents for that.\n"},{"id":"93270","messageId":"2d460de70810170021q5daa902er1e6e2fb6633400ec@mail.gmail.com","threadId":"15932","inReplyTo":"7vy70of6t2.fsf@arte.twinsun.com","subject":"Re: commiting while the current version is in conflict","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-10-17T07:21:52Z","receivedAt":"2008-10-17T07:21:52Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"On Fri, Oct 17, 2008 at 01:39, Junio Hamano wrote:\n\n> (0) You are wrong to assume that git does not keep conflict\n> information; we can tell if the index is \"unmerged\" to see\n> if you still have unresolved conflicts;\n\nThat information is already lost at the point when the\npre-commit hook is executed. Thus, I more or less had to\narrive at the wrong conclusion :)\n\n\n> (1) When the index is unmerged, git-commit will stop even\n> before getting to pre-commit hook, so there is no point\n> for pre-commit hook to check if the index is unmerged;\n\nI realize this, now.\n\n\n> (2) pre-commit hook is a last ditch effort to help ignorant\n> users who have already done \"git add\" without thinking and\n> lost the \"unmerged\" state. It has to look at and guess at\n> the contents for that.\n\nIgnoring the ad hominem attack, I would argue that the two\ndistinct mental concepts of 'I want to commit this in the next\ncommit' and 'I have resolved this conflict' should have two\ndistinct commands.\nTo err is human, which is why rm -i exists. Else, you could\njust use alias rm='rm -rf'.\n\nAlso, within certain boundaries, a tool should adapt to the\nuser, not vice versa.\n\nIn my opinion, a pre-add hook which is able to warn the user\nthat something they are about to add is still in conflict would\nbe best. The one piece of feedback I had up to now was\nvery positive.\n\n\nRichard\n"},{"id":"93277","messageId":"7vwsg7mxb6.fsf@gitster.siamese.dyndns.org","threadId":"15932","inReplyTo":"2d460de70810170021q5daa902er1e6e2fb6633400ec@mail.gmail.com","subject":"Re: commiting while the current version is in conflict","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-17T08:37:49Z","receivedAt":"2008-10-17T08:37:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Richard Hartmann\" writes:\n\n>> (2) pre-commit hook is a last ditch effort to help ignorant\n>> users who have already done \"git add\" without thinking and\n>> lost the \"unmerged\" state. It has to look at and guess at\n>> the contents for that.\n>\n> Ignoring the ad hominem attack, I would argue that the two\n\nEh, Sorry about that --- I did not mean \"ignorant\" in that sense. Perhaps\nreplacing the word with \"unfortunate\" would sound nicer?\n\n> To err is human, which is why rm -i exists. Else, you could\n> just use alias rm='rm -rf'.\n>\n> Also, within certain boundaries, a tool should adapt to the\n> user, not vice versa.\n\nDon't you realize that is what the hook is doing already? After making\nsuch an error, the definitive information is lost, because the user told\nthe tool that the resolution is done and the file is ready to be\ncommitted) by mistake. Even then the hook is trying its best to help the\nuser.\n\nReplace your \"rm=rm -rf\" sentence with \"why undelete exists\" and read it\nagain. No, filesystem undelete does not always work (disk block could\nhave been recycled for other files), but it could help you when you did\nremove a file you wanted to keep by mistake when it can.\n\nAs to pre-add hook, I am not enthused, but if somebody sends in a clean\npatch, I wouldn't be opposed to it at least in principle.\n"},{"id":"93280","messageId":"m3d4hzk2du.fsf@localhost.localdomain","threadId":"15932","inReplyTo":"2d460de70810170021q5daa902er1e6e2fb6633400ec@mail.gmail.com","subject":"Re: commiting while the current version is in conflict","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-17T09:16:35Z","receivedAt":"2008-10-17T09:16:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Richard Hartmann\" writes:\n\n> On Fri, Oct 17, 2008 at 01:39, Junio Hamano wrote:\n\n> > (2) pre-commit hook is a last ditch effort to help ignorant\n> > users who have already done \"git add\" without thinking and\n> > lost the \"unmerged\" state. It has to look at and guess at\n> > the contents for that.\n> \n> Ignoring the ad hominem attack, I would argue that the two\n> distinct mental concepts of 'I want to commit this in the next\n> commit' and 'I have resolved this conflict' should have two\n> distinct commands.\n>\n> To err is human, which is why rm -i exists. Else, you could\n> just use alias rm='rm -rf'.\n\n>From time to time somebody proposes to add a command which is used\nonly to say that given conflict got resolved, i.e. yet another\nporcelain \"around\" git-update-index plumbing (in addition to git-add,\ngit-mv and git-rm). One of problems is how to call it: git-resolve,\ngit-resolved, git-mark-resolved?\n\nBTW. while I usually use \"git commit -a\", when comitting merge commit\nI usually use explicit \"git add\" together \"git commit\" (without '-a').\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"93282","messageId":"2d460de70810170232o24fcd1d4pd1c7a7503e17b02@mail.gmail.com","threadId":"15932","inReplyTo":"7vwsg7mxb6.fsf@gitster.siamese.dyndns.org","subject":"Re: commiting while the current version is in conflict","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-10-17T09:32:29Z","receivedAt":"2008-10-17T09:32:29Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"On Fri, Oct 17, 2008 at 10:37, Junio C Hamano wrote:\n\n> Eh, Sorry about that --- I did not mean \"ignorant\" in that sense. Perhaps\n> replacing the word with \"unfortunate\" would sound nicer?\n\nA lot yes. No harm done, apologies for picking the bad interpretation\nof ignorant.\n\n\n> Don't you realize that is what the hook is doing already? After making\n> such an error, the definitive information is lost, because the user told\n> the tool that the resolution is done and the file is ready to be\n> committed) by mistake. Even then the hook is trying its best to help the\n> user.\n\nYou misunderstood me, there. I was thinking about the pre-add hook\nwhile writing the above. Doing anything at commit time is obviously\nwrong.\n\n\n> As to pre-add hook, I am not enthused, but if somebody sends in a clean\n> patch, I wouldn't be opposed to it at least in principle.\n\nAn implicit need for it does apparently exist. Else, the default hook for\npre-commit would not need to check for conflicts.\n\n\nRichard\n"},{"id":"93283","messageId":"2d460de70810170235q1c9211c3r1f56067e694b1ac@mail.gmail.com","threadId":"15932","inReplyTo":"m3d4hzk2du.fsf@localhost.localdomain","subject":"Re: commiting while the current version is in conflict","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-10-17T09:35:30Z","receivedAt":"2008-10-17T09:35:30Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"On Fri, Oct 17, 2008 at 11:16, Jakub Narebski wrote:\n\n> From time to time somebody proposes to add a command which is used\n> only to say that given conflict got resolved, i.e. yet another\n> porcelain \"around\" git-update-index plumbing (in addition to git-add,\n> git-mv and git-rm). One of problems is how to call it: git-resolve,\n> git-resolved, git-mark-resolved?\n\nIn that case, you would still need a pre-add hook.\nThe problem is not that people can't mark resolved without adding.\nIt's that they can't add without checking (automatically) if there\nare no conflicts.\n\n\nRichard\n"},{"id":"93284","messageId":"7vabd3mulf.fsf@gitster.siamese.dyndns.org","threadId":"15932","inReplyTo":"m3d4hzk2du.fsf@localhost.localdomain","subject":"Re: commiting while the current version is in conflict","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-17T09:36:28Z","receivedAt":"2008-10-17T09:36:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> From time to time somebody proposes to add a command which is used\n> only to say that given conflict got resolved, i.e. yet another\n> porcelain \"around\" git-update-index plumbing (in addition to git-add,\n> git-mv and git-rm). One of problems is how to call it: git-resolve,\n> git-resolved, git-mark-resolved?\n>\n> BTW. while I usually use \"git commit -a\", when comitting merge commit\n> I usually use explicit \"git add\" together \"git commit\" (without '-a').\n\nThere are three things to keep in mind while thinking about this:\n\n * \"git add\" _always_ is to mark \"this path now is in a good shape and is\n ready to be committed\", whether you are doing a conflict resolution of\n a merge or making a normal commit.\n\n * you cannot partially commit a merge, as the resulting tree won't be a\n proper merge (i.e. the change from either parents do not describe what\n happened).\n\n * during a conflicted merge, cleanly merged paths are already staged in\n the index.\n\nWhich means that the only paths you would \"git add\" during a conflicted\nmerge are the paths you resolved (unless you are creating an evil merge),\nand there is no point having a separate \"git resolved\" -- such a command\nwill be nothing but an alias to \"git add\" anyway.\n\nWe could add a training wheel mode to \"git commit -a\" (or \"git add -u\")\nthat warns about unmerged paths and asks confirmation, but I suspect that\nit would really annoy people who used git for more than 2 weeks if we made\nit the default, and on the other hand if it is not the default, it would\nnot help new people that much. It is nice to try to help new people from\nshooting themselves in the foot, but we need to draw a line somewhere so\nthat we do not hurt people by being obnoxious. After all, even these new\npeople will graduate from the \"new\" status soon. My gut feeling is that\nhelping \"oh, I staged the file that I wasn't ready to commit\" is on the\nother side of that line, especially since the example pre-commit hook\nsafety is easily available. If somebody wants to add a pre-add hook that\nis run by \"git add\" Porcelain (but never by \"update-index\"), that would\nadd the safety net, too.\n"}]}