> > 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 -- 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