From: Patrick Doyle <wpdster@gmail.com>
Date: Mon, 22 Nov 2010 14:22:21 GMT
Subject: Re: OK, how should I have done this...
Message-ID: <AANLkTi=uxRfsy2vG+4CBJv8Vhjrr2roVOXeNLvPA+6U+@mail.gmail.com>
In-Reply-To: <vpq4ob9qy6f.fsf@bauges.imag.fr>

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.  ((*) Well,
I didn't "lose" it in the sense of "it's gone forever", but I lost it
in the sense of "it doesn't show up in git log anymore".)

This looks like I would end up committing changes on top of the "the
one that works" commit and not on the more recent, already on the
server, "the-one-that-doesnt" commit.

--wpd