On Mon, Nov 22, 2010 at 8:34 AM, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > Patrick Doyle <wpdster@xxxxxxxxx> 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 -- 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