{"thread":{"id":"23631","subject":"how to fix the problem correctly?","startedAt":"2010-04-28T16:54:33Z","lastAt":"2010-04-28T18:55:01Z","messageCount":3,"participants":["Eugene Sajine","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140595","messageId":"w2t76c5b8581004280954r436c1be1g8d6e415bf3596f4d@mail.gmail.com","threadId":"23631","inReplyTo":null,"subject":"how to fix the problem correctly?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-28T16:54:33Z","receivedAt":"2010-04-28T16:54:33Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"I have a following situation (in dev branch):\n\n3 files:\n1.txt, 2.txt, 3.txt\n\nA -> B -> C -> D -> E\n        |                     |\n   Master               dev\n\nBetween B and C the version of file 1.txt was screwed up (let’s say it\nwas copied into git repo from other location where it was in state A\n(CVS) and then committed by mistake in C, effectively reverting the\nchange of this file in commit B)\nCommit C also had changes to files 2 and 3.\nAfter this commits D and E did not have changes for file 1.txt, only 2\nand 3 were touched.\n\nWhen we tried to revert commit C – this lead to the code completely\nmessed up, with conflicts – so this seems to be not an option.\nRebase also doesn’t seem to help here\n\nOnly two variants I saw:\n1. Do “git co A 1.txt” and commit the change as F\n2. Do “git reset –soft master” and recommit all changes once again\n\nIs there a better way?\n\nPS interesting enough – CVS keywords helped us to notice the problem\nas master state was imported from CVS.\nIn commit A file 1.txt had version ID 1.5 in commit B it was 1.6 ,\ncommit C was changing the line back to 1.5\nIs there a way for git to help me to recognize this kind of issue if\nthere are no keywords?\n\nDISCLAIMER: I don’t like keywords, and I don’t want them to be\nimplemented in git.\n\n\nThanks,\nEugene\n"},{"id":"140598","messageId":"s2v32541b131004281130m1c79ff4dp8c02afc8b70bbde5@mail.gmail.com","threadId":"23631","inReplyTo":"w2t76c5b8581004280954r436c1be1g8d6e415bf3596f4d@mail.gmail.com","subject":"Re: how to fix the problem correctly?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-04-28T18:30:01Z","receivedAt":"2010-04-28T18:30:01Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Apr 28, 2010 at 12:54 PM, Eugene Sajine <euguess@gmail.com> wrote:\n> Between B and C the version of file 1.txt was screwed up (let’s say it\n> was copied into git repo from other location where it was in state A\n> (CVS) and then committed by mistake in C, effectively reverting the\n> change of this file in commit B)\n> Commit C also had changes to files 2 and 3.\n> After this commits D and E did not have changes for file 1.txt, only 2\n> and 3 were touched.\n>\n> When we tried to revert commit C – this lead to the code completely\n> messed up, with conflicts – so this seems to be not an option.\n> Rebase also doesn’t seem to help here\n>\n> Only two variants I saw:\n> 1. Do “git co A 1.txt” and commit the change as F\n> 2. Do “git reset –soft master” and recommit all changes once again\n>\n> Is there a better way?\n\nVirtually any way that works is \"correct.\"  It depends a bit on your goals.\n\nStep 1 is certainly the easiest place to start.  If you're then\nconcerned about making sure your history never showed the mistake\n(which is a lofty goal, though rarely very important), you could use\ngit rebase to 'squash' this new commit into C.  But rewriting history\nin git has well-documented dangers, so you should be careful and read\nthe docs first.\n\n> PS interesting enough – CVS keywords helped us to notice the problem\n> as master state was imported from CVS.\n> In commit A file 1.txt had version ID 1.5 in commit B it was 1.6 ,\n> commit C was changing the line back to 1.5\n> Is there a way for git to help me to recognize this kind of issue if\n> there are no keywords?\n\nSadly, git doesn't have any magic features for detecting when someone\nchecks in something stupid :)   But 'git bisect' can be very helpful\nin isolating which commit caused a particular problem.  Once you know\nyou have a problem, it's pretty easy to narrow it down that way.\n\nHave fun,\n\nAvery\n"},{"id":"140600","messageId":"t2h76c5b8581004281155ta77ad992xc36b5d87824ec9cf@mail.gmail.com","threadId":"23631","inReplyTo":"s2v32541b131004281130m1c79ff4dp8c02afc8b70bbde5@mail.gmail.com","subject":"Re: how to fix the problem correctly?","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-04-28T18:55:01Z","receivedAt":"2010-04-28T18:55:01Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":">\n> Virtually any way that works is \"correct.\"  It depends a bit on your goals.\n>\n> Step 1 is certainly the easiest place to start.  If you're then\n> concerned about making sure your history never showed the mistake\n> (which is a lofty goal, though rarely very important), you could use\n> git rebase to 'squash' this new commit into C.  But rewriting history\n> in git has well-documented dangers, so you should be careful and read\n> the docs first.\n\nGood idea to clean up with rebase after step 1. I didn't think about\nthat, thanks! And yes I know about the restrictions;)\n\n>\n>> PS interesting enough – CVS keywords helped us to notice the problem\n>> as master state was imported from CVS.\n>> In commit A file 1.txt had version ID 1.5 in commit B it was 1.6 ,\n>> commit C was changing the line back to 1.5\n>> Is there a way for git to help me to recognize this kind of issue if\n>> there are no keywords?\n>\n> Sadly, git doesn't have any magic features for detecting when someone\n> checks in something stupid :)   But 'git bisect' can be very helpful\n> in isolating which commit caused a particular problem.  Once you know\n> you have a problem, it's pretty easy to narrow it down that way.\n\nyes, it is very hard to be fool-proof. I just got an idea:\nIn this particular case some script scanning for pairs of commits\nwhere blob SHA-1 changes\nare like below (for the same path) and warns about such occurrences.\n\ncommit 1111\n... blobaaaaaa... blobbbbbbb... path\n\ncommit 3333\n\n... blobbbbbbb... blobaaaaaaa... path\n\nUnless the commit 3333 is a real revert, this might be suspicious, isn't it?\n\nI don't know if it has any real sense or use, but i will try to create\nsuch thing at least as an exercise...\n\nThanks,\nEugene\n"}]}