{"thread":{"id":"15931","subject":"commiting while the current version is in conflict","startedAt":"2008-10-16T22:10:55Z","lastAt":"2008-10-17T07:25:06Z","messageCount":10,"participants":["Richard Hartmann","Miklos Vajna","Shawn O. Pearce","Jakub Narebski","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"93248","messageId":"2d460de70810161510ha220593g4615a55b2c3e3b25@mail.gmail.com","threadId":"15931","inReplyTo":null,"subject":"commiting while the current version is in conflict","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-10-16T22:10:55Z","receivedAt":"2008-10-16T22:10:55Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"Hi all,\n\nI fooled around with git a liitle bit and noticed something\nrather strange. I merged two branches, creating a conflict\non purpose. When I then did a\n\n git commit -a\n\nall changes were submitted. Of course, I now have a\nfile with the conflict markers inlined in my repository. Not\na good thing, imo. Is there a way to make git block all\nconflicting versions?\n\nAlso, I would be interested in the design decissions\nbehind the current behaviour. Any pointers?\n\n\nThanks,\nRichard\n"},{"id":"93249","messageId":"20081016224808.GO536@genesis.frugalware.org","threadId":"15931","inReplyTo":"2d460de70810161510ha220593g4615a55b2c3e3b25@mail.gmail.com","subject":"Re: commiting while the current version is in conflict","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-10-16T22:48:08Z","receivedAt":"2008-10-16T22:48:08Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Fri, Oct 17, 2008 at 12:10:55AM +0200, Richard Hartmann wrote:\n> all changes were submitted. Of course, I now have a\n> file with the conflict markers inlined in my repository. Not\n> a good thing, imo. Is there a way to make git block all\n> conflicting versions?\n\nWrite a pre-commit hook that checks for conflict markers?\n\n> Also, I would be interested in the design decissions\n> behind the current behaviour. Any pointers?\n\nNot sure, but in general blocking conflict markers by default would be a\nbad idea IMHO, several markup language (asciidoc, for example) makes use\nof the >>>, === and such character sequences.\n"},{"id":"93250","messageId":"20081016230035.GC9877@spearce.org","threadId":"15931","inReplyTo":"20081016224808.GO536@genesis.frugalware.org","subject":"Re: commiting while the current version is in conflict","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-10-16T23:00:35Z","receivedAt":"2008-10-16T23:00:35Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Miklos Vajna wrote:\n> On Fri, Oct 17, 2008 at 12:10:55AM +0200, Richard Hartmann wrote:\n> > all changes were submitted. Of course, I now have a\n> > file with the conflict markers inlined in my repository. Not\n> > a good thing, imo. Is there a way to make git block all\n> > conflicting versions?\n> \n> Write a pre-commit hook that checks for conflict markers?\n\nThe sample pre-commit hook checks for these. Its really hande to\nhave enabled.\n \n> > Also, I would be interested in the design decissions\n> > behind the current behaviour. Any pointers?\n> \n> Not sure, but in general blocking conflict markers by default would be a\n> bad idea IMHO, several markup language (asciidoc, for example) makes use\n> of the >>>, === and such character sequences.\n\nNot only that, but \"git commit -a\" did exactly what you asked it to do:\n\n\tgit add -u\n\tgit commit\n\nand git add -u is basically a faster way to do something like this pseudo-shell:\n\n\tfor path in $(git status | grep modified:)\n\tdo\n\t\tgit add $path\n\tdone\n\nand merge conflicts are \"resolved\" by you running \"git add $path\"\nafter you have finished fixing that path.\n\nMoral of the story is, don't use \"git commit -a\". Use only \"git commit\"\nand stage files individually. That way when you are in a merge conflict\nyou won't be in the habit of writing \"git commit -a\" and staging everything\nfrom the working tree implicitly.\n\n-- \nShawn.\n"},{"id":"93251","messageId":"2d460de70810161607n470e9479h8f7885040cbf5428@mail.gmail.com","threadId":"15931","inReplyTo":"20081016224808.GO536@genesis.frugalware.org","subject":"Re: commiting while the current version is in conflict","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-10-16T23:07:27Z","receivedAt":"2008-10-16T23:07:27Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"On Fri, Oct 17, 2008 at 00:48, Miklos Vajna wrote:\n\n> Not sure, but in general blocking conflict markers by default would be a\n> bad idea IMHO, several markup language (asciidoc, for example) makes use\n> of the >>>, === and such character sequences.\n\nDoesn't git keep metadata about conflicts, as well?\n\n\nRichard\n"},{"id":"93252","messageId":"20081016232332.GD9877@spearce.org","threadId":"15931","inReplyTo":"2d460de70810161607n470e9479h8f7885040cbf5428@mail.gmail.com","subject":"Re: commiting while the current version is in conflict","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-10-16T23:23:32Z","receivedAt":"2008-10-16T23:23:32Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Richard Hartmann wrote:\n> On Fri, Oct 17, 2008 at 00:48, Miklos Vajna wrote:\n> \n> > Not sure, but in general blocking conflict markers by default would be a\n> > bad idea IMHO, several markup language (asciidoc, for example) makes use\n> > of the >>>, === and such character sequences.\n> \n> Doesn't git keep metadata about conflicts, as well?\n\nYes, in the index. But it erases it when you stage the file with\n\"git add\".\n\nGo look at my prior message about how \"git commit -a\" is staging\nthe files prior to commit. That makes git commit think everything\nhas been resolved, because you've told git, everything is resolved.\n\n-- \nShawn.\n"},{"id":"93253","messageId":"2d460de70810161626n4f4c4489k489b20f2e6cce186@mail.gmail.com","threadId":"15931","inReplyTo":"20081016230035.GC9877@spearce.org","subject":"Re: commiting while the current version is in conflict","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-10-16T23:26:37Z","receivedAt":"2008-10-16T23:26:37Z","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:00, Shawn O. Pearce wrote:\n\n> The sample pre-commit hook checks for these. Its really hande to\n> have enabled.\n\nThanks.\n\n\n> and merge conflicts are \"resolved\" by you running \"git add $path\"\n> after you have finished fixing that path.\n\nTrue, git add is an implicit resolving, I did not think about it this way.\nPersonally, I think that git should break at this point, but that's\njust me.\n\nThe obvious fix would be a pre-add hook. Does anyone else think\nthis would make sense?\n\n\nJudging from the code in the pre-commit script, git does not\nkeep conflict information in its metadata cache, but tries to guess\nconflicts from the file's contents/ This seems to be a strange\nthing to do, imo. What's the reason for this?\n\n\nRichard\n"},{"id":"93254","messageId":"2d460de70810161631n4b9f766fv2bca0e44d1e4009@mail.gmail.com","threadId":"15931","inReplyTo":"20081016232332.GD9877@spearce.org","subject":"Re: commiting while the current version is in conflict","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-10-16T23:31:02Z","receivedAt":"2008-10-16T23:31:02Z","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:23, Shawn O. Pearce wrote:\n\n\n> Yes, in the index. But it erases it when you stage the file with\n> \"git add\".\n>\n> Go look at my prior message about how \"git commit -a\" is staging\n> the files prior to commit. That makes git commit think everything\n> has been resolved, because you've told git, everything is resolved.\n\nThis makes a good part of my latest email obsolete. Asynchronous\ncommunication ftw ;)\n\n\nRichard\n"},{"id":"93255","messageId":"m3ljwojeeu.fsf@localhost.localdomain","threadId":"15931","inReplyTo":"2d460de70810161510ha220593g4615a55b2c3e3b25@mail.gmail.com","subject":"Re: commiting while the current version is in conflict","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-16T23:42:06Z","receivedAt":"2008-10-16T23:42:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Richard Hartmann\" writes:\n\n> I fooled around with git a liitle bit and noticed something\n> rather strange. I merged two branches, creating a conflict\n> on purpose. When I then did a\n> \n> git commit -a\n> \n> all changes were submitted. Of course, I now have a\n> file with the conflict markers inlined in my repository. Not\n> a good thing, imo. Is there a way to make git block all\n> conflicting versions?\n\nThe default pre-commit hook shipped with git includes this check. \nAll you have to do is enable it: it has to be named 'pre-commit' and\nit has to be exacutable. In older git version you would do:\n $ chmod a+x .git/hooks/pre-commit\nwhile in never versions it would be\n $ mv .git/hooks/pre-commit.sample .git/hooks/pre-commit\n \n> Also, I would be interested in the design decissions\n> behind the current behaviour. Any pointers?\n\nIt is a git policy that it ships with all hooks disabled.\n\nP.S. You can always bypass pre-commit hook (for example if comitting\nAsciiDoc files, which may include something that looks like conflict\nmarkers, or if you are committing test which includes conflicted file\nas one of test vectors), by using `--no-verify' option to git-commit.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"93257","messageId":"32541b130810161816r1667f018paa74525091f0682a@mail.gmail.com","threadId":"15931","inReplyTo":"2d460de70810161626n4f4c4489k489b20f2e6cce186@mail.gmail.com","subject":"Re: commiting while the current version is in conflict","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-10-17T01:16:10Z","receivedAt":"2008-10-17T01:16:10Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, Oct 16, 2008 at 7:26 PM, Richard Hartmann\n wrote:\n> On Fri, Oct 17, 2008 at 01:00, Shawn O. Pearce wrote:\n>> and merge conflicts are \"resolved\" by you running \"git add $path\"\n>> after you have finished fixing that path.\n>\n> True, git add is an implicit resolving, I did not think about it this way.\n> Personally, I think that git should break at this point, but that's\n> just me.\n>\n> The obvious fix would be a pre-add hook. Does anyone else think\n> this would make sense?\n\nThat would be awesome. I've frequently been bitten by accidentally\nrunning \"git add\" on a file that I *think* I've resolved the conflicts\non, but it turns out I missed a commit marker or two. And then the\nhandy conflict-style \"git diff\" is no longer available, among other\nthings. If \"git add\" could prevent me from adding the file at all, it\nmight save me some trouble.\n\nOn the other hand, an even better alternative would be to have a way\nto \"unadd\" a file and bring back the conflict information, but I don't\nknow how that would really work.\n\nHave fun,\n\nAvery\n"},{"id":"93272","messageId":"2d460de70810170025y74fbd846nefc7dad24f669e75@mail.gmail.com","threadId":"15931","inReplyTo":"m3ljwojeeu.fsf@localhost.localdomain","subject":"Re: commiting while the current version is in conflict","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2008-10-17T07:25:06Z","receivedAt":"2008-10-17T07:25:06Z","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:42, Jakub Narebski wrote:\n\n> [a lot of detailed information]\n\nThanks! 'Unfortunately', I figured all this out by myself, in the\nmeantime, but I really appreciate that you took the time to\nexplain all this .\n\n\nThanks!\nRichard\n\nPS: Well, I lie, I did not figure out the mv $1.sample $1 bit\nas my git version still uses the old format.\n"}]}