# how to fix the problem correctly? 3 messages from 2010-04-28 to 2010-04-28. Participants: Eugene Sajine, Avery Pennarun. Thread: https://gitlist.dev/t/23631 ## Eugene Sajine, 2010-04-28 16:54 Subject: how to fix the problem correctly? Message-ID: URL: https://gitlist.dev/e/w2t76c5b8581004280954r436c1be1g8d6e415bf3596f4d%40mail.gmail.com ``` I have a following situation (in dev branch): 3 files: 1.txt, 2.txt, 3.txt A -> B -> C -> D -> E         |                     |    Master               dev Between B and C the version of file 1.txt was screwed up (let’s say it was copied into git repo from other location where it was in state A (CVS) and then committed by mistake in C, effectively reverting the change of this file in commit B) Commit C also had changes to files 2 and 3. After this commits D and E did not have changes for file 1.txt, only 2 and 3 were touched. When we tried to revert commit C – this lead to the code completely messed up, with conflicts – so this seems to be not an option. Rebase also doesn’t seem to help here Only two variants I saw: 1. Do “git co A 1.txt” and commit the change as F 2. Do “git reset –soft master” and recommit all changes once again Is there a better way? PS interesting enough – CVS keywords helped us to notice the problem as master state was imported from CVS. In commit A file 1.txt had version ID 1.5 in commit B it was 1.6 , commit C was changing the line back to 1.5 Is there a way for git to help me to recognize this kind of issue if there are no keywords? DISCLAIMER: I don’t like keywords, and I don’t want them to be implemented in git. Thanks, Eugene ``` ## Avery Pennarun, 2010-04-28 18:30 Subject: Re: how to fix the problem correctly? Message-ID: URL: https://gitlist.dev/e/s2v32541b131004281130m1c79ff4dp8c02afc8b70bbde5%40mail.gmail.com In-Reply-To: ``` On Wed, Apr 28, 2010 at 12:54 PM, Eugene Sajine wrote: > Between B and C the version of file 1.txt was screwed up (let’s say it > was copied into git repo from other location where it was in state A > (CVS) and then committed by mistake in C, effectively reverting the > change of this file in commit B) > Commit C also had changes to files 2 and 3. > After this commits D and E did not have changes for file 1.txt, only 2 > and 3 were touched. > > When we tried to revert commit C – this lead to the code completely > messed up, with conflicts – so this seems to be not an option. > Rebase also doesn’t seem to help here > > Only two variants I saw: > 1. Do “git co A 1.txt” and commit the change as F > 2. Do “git reset –soft master” and recommit all changes once again > > Is there a better way? Virtually any way that works is "correct." It depends a bit on your goals. Step 1 is certainly the easiest place to start. If you're then concerned about making sure your history never showed the mistake (which is a lofty goal, though rarely very important), you could use git rebase to 'squash' this new commit into C. But rewriting history in git has well-documented dangers, so you should be careful and read the docs first. > PS interesting enough – CVS keywords helped us to notice the problem > as master state was imported from CVS. > In commit A file 1.txt had version ID 1.5 in commit B it was 1.6 , > commit C was changing the line back to 1.5 > Is there a way for git to help me to recognize this kind of issue if > there are no keywords? Sadly, git doesn't have any magic features for detecting when someone checks in something stupid :) But 'git bisect' can be very helpful in isolating which commit caused a particular problem. Once you know you have a problem, it's pretty easy to narrow it down that way. Have fun, Avery ``` ## Eugene Sajine, 2010-04-28 18:55 Subject: Re: how to fix the problem correctly? Message-ID: URL: https://gitlist.dev/e/t2h76c5b8581004281155ta77ad992xc36b5d87824ec9cf%40mail.gmail.com In-Reply-To: ``` > > Virtually any way that works is "correct."  It depends a bit on your goals. > > Step 1 is certainly the easiest place to start.  If you're then > concerned about making sure your history never showed the mistake > (which is a lofty goal, though rarely very important), you could use > git rebase to 'squash' this new commit into C.  But rewriting history > in git has well-documented dangers, so you should be careful and read > the docs first. Good idea to clean up with rebase after step 1. I didn't think about that, thanks! And yes I know about the restrictions;) > >> PS interesting enough – CVS keywords helped us to notice the problem >> as master state was imported from CVS. >> In commit A file 1.txt had version ID 1.5 in commit B it was 1.6 , >> commit C was changing the line back to 1.5 >> Is there a way for git to help me to recognize this kind of issue if >> there are no keywords? > > Sadly, git doesn't have any magic features for detecting when someone > checks in something stupid :)   But 'git bisect' can be very helpful > in isolating which commit caused a particular problem.  Once you know > you have a problem, it's pretty easy to narrow it down that way. yes, it is very hard to be fool-proof. I just got an idea: In this particular case some script scanning for pairs of commits where blob SHA-1 changes are like below (for the same path) and warns about such occurrences. commit 1111 ... blobaaaaaa... blobbbbbbb... path commit 3333 ... blobbbbbbb... blobaaaaaaa... path Unless the commit 3333 is a real revert, this might be suspicious, isn't it? I don't know if it has any real sense or use, but i will try to create such thing at least as an exercise... Thanks, Eugene ```