On Wed, Apr 28, 2010 at 12:54 PM, Eugene Sajine <euguess@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html