Re: OK, how should I have done this...

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Patrick Doyle <wpdster@gmail.com> writes:

> On Mon, Nov 22, 2010 at 8:34 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Patrick Doyle <wpdster@gmail.com> writes:
>>
>>> I just checked in modifications to 1/2 dozen or so files in a single
>>> commit and pushed them to my server.
>>
>>> So now I want to figure out which modification(s) in which file(s)
>>> introduced the problem.
>>
>> 'didn't read all the details of your message, but the way I'd have
>> done this would be with stash --keep-index:
>>
>> (untested)
>>
>> git checkout the-one-that-works # staging area and tree checked out.
>> git reset the-one-that-doesnt   # just change the staging area
>> git add -p
>> # pick some commits
>> git stash --keep-index
>> # run some tests
>> # if test fail then
>>   # happy, "git diff --staged" tells you what.
>> # else
>>   git commit -m "first modification"
>>   git stash pop
>>   # goto the git add -p step.
>> # fi
>
> That looks kinda scary to me.  The last time I played with git-reset,
> I ended up losing(*) the commit at the head of my branch.

In general, you should think twice before doing this kind of surgery.
But :

* The git checkout at the beginning brings you in detached HEAD state,
  so you're not going to damage the branches themselves. The
  intermediate commits you'll do will be unreachable unless you create
  a ref explicitely. So, "git checkout branch-name" will bring you
  back to your branch when you're done.

* Git has this great "reflog" thing, so even if you mess up your
  branch, it's still in the reflog.

* Hopefully, you're working on a local clone, and really important
  stuff have already been pushed to a safer place, so the very worst
  thing that can happen is to start over with a fresh clone.

In my proposal, *if* you end up with a set of small commit that you
prefer over your initial big commit, you can chose to record it in
history (either git update-ref, dangerous if you've already pushed
anything, or git merge, to keep both the big commit and the small ones
in the history).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/