Re: how to fix the problem correctly?

[Avery Pennarun <apenwarr@gmail.com>]

On Wed, Apr 28, 2010 at 12:54 PM, Eugene Sajine <euguess@gmail.com> 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