{"thread":{"id":"25808","subject":"OK, how should I have done this...","startedAt":"2010-11-22T13:22:09Z","lastAt":"2010-11-23T00:17:55Z","messageCount":7,"participants":["Patrick Doyle","Matthieu Moy","Tay Ray Chuan","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"156313","messageId":"AANLkTim0_J0i_a0o+z1oCC4mramfUxCGtCg_Y+ab+h+-@mail.gmail.com","threadId":"25808","inReplyTo":null,"subject":"OK, how should I have done this...","fromName":"Patrick Doyle","fromEmail":"wpdster@gmail.com","sentAt":"2010-11-22T13:22:09Z","receivedAt":"2010-11-22T13:22:09Z","isPatch":false,"sender":{"key":"wpdster@gmail.com","avatar":null},"body":"I just checked in modifications to 1/2 dozen or so files in a single\ncommit and pushed them to my server.\n\nThen I switched to a different machine, pulled the latest version of\nmy repository from the server, tried running my code, and discovered\nthat I introduced a problem that didn't manifest itself when running\non my laptop.\n\nSo now I want to figure out which modification(s) in which file(s)\nintroduced the problem.\n\nI did a git log and saw that things were fine back at commit 5ccce3, so I did\n\n$ git checkout 5ccce3\n\nfully expecting (and seeing) the warning about 'moving to \"5ccce3\"\nwhich isn't a local branch'\n\nran my code. It worked (as expected).\n\n$ git diff --name-status master\n\nSaw the list of files that had changed.\n\n$ git checkout master -- file1\n\nGrabbed the version of file1 from master & reran my test. It passed.\nRepeated the process until I'd identified the set of 3 files that\ncaused things to break, and fixed those three files.\n\nNow I want to check those 3 files in on the master branch. My first\ninclination, since every time I've tried doing stuff like this in the\npast has failed miserably, was to copy those 3 files to a safe\nlocation, revert them to their unmodified state, switch to the master\nbranch, copy the modified files into my working directory, and commit\nthem.\n\nInstead, I did:\n\n$ git checkout master\n\nhoping that would just switch me to the master branch, keeping those 3\nmodified files. Instead, what I got was:\n\nerror: Entry 'blah/file7' not uptodate. Cannot merge.\n\nand now \"git status\" shows a bunch of files staged to be committed\n(all the files that were different between master and rev 5ccce3) and\nmy 3 files with their modifications.\n\nI'm gonna go back to plan A, copy those 3 files to someplace safe, and\ncheckout/reset until I get back to a clean checkout of master, copy\nthose 3 files in, and commit that change.\n\nBut I _know_ that there must be a better way to do this. What should\nI have done?\n\n--wpd\n"},{"id":"156315","messageId":"vpq4ob9qy6f.fsf@bauges.imag.fr","threadId":"25808","inReplyTo":"AANLkTim0_J0i_a0o+z1oCC4mramfUxCGtCg_Y+ab+h+-@mail.gmail.com","subject":"Re: OK, how should I have done this...","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-11-22T13:34:48Z","receivedAt":"2010-11-22T13:34:48Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Patrick Doyle writes:\n\n> I just checked in modifications to 1/2 dozen or so files in a single\n> commit and pushed them to my server.\n\n> So now I want to figure out which modification(s) in which file(s)\n> introduced the problem.\n\n'didn't read all the details of your message, but the way I'd have\ndone this would be with stash --keep-index:\n\n(untested)\n\ngit checkout the-one-that-works # staging area and tree checked out.\ngit reset the-one-that-doesnt # just change the staging area\ngit add -p\n# pick some commits\ngit stash --keep-index\n# run some tests\n# if test fail then\n # happy, \"git diff --staged\" tells you what.\n# else\n git commit -m \"first modification\"\n git stash pop\n # goto the git add -p step.\n# fi\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"156319","messageId":"AANLkTi=uxRfsy2vG+4CBJv8Vhjrr2roVOXeNLvPA+6U+@mail.gmail.com","threadId":"25808","inReplyTo":"vpq4ob9qy6f.fsf@bauges.imag.fr","subject":"Re: OK, how should I have done this...","fromName":"Patrick Doyle","fromEmail":"wpdster@gmail.com","sentAt":"2010-11-22T14:22:21Z","receivedAt":"2010-11-22T14:22:21Z","isPatch":false,"sender":{"key":"wpdster@gmail.com","avatar":null},"body":"On Mon, Nov 22, 2010 at 8:34 AM, Matthieu Moy\n wrote:\n> Patrick Doyle writes:\n>\n>> I just checked in modifications to 1/2 dozen or so files in a single\n>> commit and pushed them to my server.\n>\n>> So now I want to figure out which modification(s) in which file(s)\n>> introduced the problem.\n>\n> 'didn't read all the details of your message, but the way I'd have\n> done this would be with stash --keep-index:\n>\n> (untested)\n>\n> git checkout the-one-that-works # staging area and tree checked out.\n> git reset the-one-that-doesnt   # just change the staging area\n> git add -p\n> # pick some commits\n> git stash --keep-index\n> # run some tests\n> # if test fail then\n>   # happy, \"git diff --staged\" tells you what.\n> # else\n>   git commit -m \"first modification\"\n>   git stash pop\n>   # goto the git add -p step.\n> # fi\n\nThat looks kinda scary to me. The last time I played with git-reset,\nI ended up losing(*) the commit at the head of my branch. ((*) Well,\nI didn't \"lose\" it in the sense of \"it's gone forever\", but I lost it\nin the sense of \"it doesn't show up in git log anymore\".)\n\nThis looks like I would end up committing changes on top of the \"the\none that works\" commit and not on the more recent, already on the\nserver, \"the-one-that-doesnt\" commit.\n\n--wpd\n"},{"id":"156320","messageId":"AANLkTim19WCCz6_iMrRj9cLU1-Q=MGAWnvYOc8=NBC_F@mail.gmail.com","threadId":"25808","inReplyTo":"AANLkTi=uxRfsy2vG+4CBJv8Vhjrr2roVOXeNLvPA+6U+@mail.gmail.com","subject":"Re: OK, how should I have done this...","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2010-11-22T14:29:55Z","receivedAt":"2010-11-22T14:29:55Z","isPatch":false,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"Hi,\n\nOn Mon, Nov 22, 2010 at 10:22 PM, Patrick Doyle wrote:\n> That looks kinda scary to me.  The last time I played with git-reset,\n> I ended up losing(*) the commit at the head of my branch.  ((*) Well,\n> I didn't \"lose\" it in the sense of \"it's gone forever\", but I lost it\n> in the sense of \"it doesn't show up in git log anymore\".)\n\nThat's the whole idea of git reset. If you want to see what the \"lost\"\ncommit was, try git reflog; it's very likely at HEAD@{1}.\n\n-- \nCheers,\nRay Chuan\n"},{"id":"156323","messageId":"vpqtyj9xrmm.fsf@bauges.imag.fr","threadId":"25808","inReplyTo":"AANLkTi=uxRfsy2vG+4CBJv8Vhjrr2roVOXeNLvPA+6U+@mail.gmail.com","subject":"Re: OK, how should I have done this...","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-11-22T16:14:25Z","receivedAt":"2010-11-22T16:14:25Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Patrick Doyle writes:\n\n> On Mon, Nov 22, 2010 at 8:34 AM, Matthieu Moy\n> wrote:\n>> Patrick Doyle writes:\n>>\n>>> I just checked in modifications to 1/2 dozen or so files in a single\n>>> commit and pushed them to my server.\n>>\n>>> So now I want to figure out which modification(s) in which file(s)\n>>> introduced the problem.\n>>\n>> 'didn't read all the details of your message, but the way I'd have\n>> done this would be with stash --keep-index:\n>>\n>> (untested)\n>>\n>> git checkout the-one-that-works # staging area and tree checked out.\n>> git reset the-one-that-doesnt   # just change the staging area\n>> git add -p\n>> # pick some commits\n>> git stash --keep-index\n>> # run some tests\n>> # if test fail then\n>>   # happy, \"git diff --staged\" tells you what.\n>> # else\n>>   git commit -m \"first modification\"\n>>   git stash pop\n>>   # goto the git add -p step.\n>> # fi\n>\n> That looks kinda scary to me. The last time I played with git-reset,\n> I ended up losing(*) the commit at the head of my branch.\n\nIn general, you should think twice before doing this kind of surgery.\nBut :\n\n* The git checkout at the beginning brings you in detached HEAD state,\n so you're not going to damage the branches themselves. The\n intermediate commits you'll do will be unreachable unless you create\n a ref explicitely. So, \"git checkout branch-name\" will bring you\n back to your branch when you're done.\n\n* Git has this great \"reflog\" thing, so even if you mess up your\n branch, it's still in the reflog.\n\n* Hopefully, you're working on a local clone, and really important\n stuff have already been pushed to a safer place, so the very worst\n thing that can happen is to start over with a fresh clone.\n\nIn my proposal, *if* you end up with a set of small commit that you\nprefer over your initial big commit, you can chose to record it in\nhistory (either git update-ref, dangerous if you've already pushed\nanything, or git merge, to keep both the big commit and the small ones\nin the history).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"156342","messageId":"7vr5ecvr9p.fsf@alter.siamese.dyndns.org","threadId":"25808","inReplyTo":"AANLkTim0_J0i_a0o+z1oCC4mramfUxCGtCg_Y+ab+h+-@mail.gmail.com","subject":"Re: OK, how should I have done this...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-23T00:05:06Z","receivedAt":"2010-11-23T00:05:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Doyle writes:\n\n> But I _know_ that there must be a better way to do this. What should\n> I have done?\n\nDepends on how you wanted to fix your history (we already know from your\ndescription what shape of tree you want to end up in).\n\nIf you want to pretend that you were perfect and never made mistakes in\nthese three files you had to fix later, then history surgery like what\nMatthieu suggested would be necessary (I won't repeat how).\n\nOn the other hand, if you want to record what you did in the time order,\nthen I would probably do this:\n\n $ git checkout master ; test ;# broken\n $ git checkout 5ccce3 ; test ;# ok\n $ git checkout master -- file1 ; test ;# ok\n $ git checkout master -- file2 ; test ;# ok\n $ git checkout master -- blah/file7 ; test ;# broken\n $ edit blah/file7 ; test ;# ok\n $ git reset --soft master\n $ git commit -a -m 'The change to file3 was borked on the other env' -e\n\nand in this particular case, this would be what I would have done, as a\nseparate \"fix-up\" commit will give me a place to describe why a solution\ndifferent from the initial attempt, which was Ok on the original machine,\nwas necessary.\n\n \n"},{"id":"156343","messageId":"AANLkTimek=PAMGz-aKrb=7QJGJYEjZ29Z8izrD1BCKDN@mail.gmail.com","threadId":"25808","inReplyTo":"7vr5ecvr9p.fsf@alter.siamese.dyndns.org","subject":"Re: OK, how should I have done this...","fromName":"Patrick Doyle","fromEmail":"wpdster@gmail.com","sentAt":"2010-11-23T00:17:55Z","receivedAt":"2010-11-23T00:17:55Z","isPatch":false,"sender":{"key":"wpdster@gmail.com","avatar":null},"body":"On Mon, Nov 22, 2010 at 7:05 PM, Junio C Hamano wrote:\n> Patrick Doyle writes:\n>\n>> But I _know_ that there must be a better way to do this.  What should\n>> I have done?\n>\n> Depends on how you wanted to fix your history (we already know from your\n> description what shape of tree you want to end up in).\n>\n> If you want to pretend that you were perfect and never made mistakes in\n> these three files you had to fix later, then history surgery like what\n> Matthieu suggested would be necessary (I won't repeat how).\n>\n> On the other hand, if you want to record what you did in the time order,\n> then I would probably do this:\n>\n>  $ git checkout master ; test ;# broken\n>  $ git checkout 5ccce3 ; test ;# ok\n>  $ git checkout master -- file1 ; test ;# ok\n>  $ git checkout master -- file2 ; test ;# ok\n>  $ git checkout master -- blah/file7 ; test ;# broken\n>  $ edit blah/file7 ; test ;# ok\n>  $ git reset --soft master\n>  $ git commit -a -m 'The change to file3 was borked on the other env' -e\n>\n> and in this particular case, this would be what I would have done, as a\n> separate \"fix-up\" commit will give me a place to describe why a solution\n> different from the initial attempt, which was Ok on the original machine,\n> was necessary.\n\nThanks Junio, that's exactly what I was trying to do. I keep getting\nconfused about checkout vs. reset. Both affect the index and the\nworking copy. Both manipulate the ref pointer. I just can't keep\nstraight when I should use reset. I understand using checkout to grab\na particular version of the repository.\n\nBut your recipe is what I wanted to do. I just used \"checkout\"\ninstead of \"reset --soft\".\n\nThanks again.\n\n--wpd\n"}]}