Hello, I several times made the mistake of a wrong commit also if generally the error born for a wrong add expecially: git add . in a directory with some files that haven't to be managed by git. So, as wrote in some emails here, if I wrote something like: git commit -m "Added file.c" -a I tryed to solve with: git commit --amend -m "Added file.c" -a hoping to have a status like before the commit and then sending: git reset . hoping to have a status like that before the wrong add. But this is not what git status say so, my solution to solve commi problems is ALWAYS: git reset --soft HEAD^ that for my point of view works better then all others permitting to redo last add and commit to solve not only a -m problem but also a wrong git add command. Il 19/06/2011 12.37, Jakub Narebski ha scritto: > On Sun, 19 Jun 2011, Jonathan Nieder wrote: >> Jakub Narebski wrote: >>> Mike <xandrani@xxxxxxxxx> writes: >>>> % git reset --hard HEAD~1 >>> Errr... here you screwed up. This reset state of you working area to >>> the state at last commit, removing all your changes to tracked files. >> Or rather, here we screwed up. Jakub and others gave some useful >> advice about how to recover, so let's consider how the UI or >> documentation could be improved to prevent it from happening again. >> >> * In this example if I understand correctly then the index contained >> some useful information, perhaps about a larger commit intended for >> later. To preserve that, you could have used >> >> git reset --soft HEAD~1 >> >> which would _just_ undo the effect of "git commit", leaving the index >> and worktree alone. > Another issue is that Mike haven't realized that `--amend' option can be > used *in combination* with other "git commit" options, which means that > the solution to his problem was using "git commit" as it should have > been done, but with '--amend' added. > > I'm not sure if git documentation talks about 'git reset --soft HEAD^', > and when to use it; from what I remember it encourages use of > 'git commit --amend' instead (which was I guess most often used reason > of using soft reset before there was '--amend'). > >> * Another situation that comes up from time to time is making a change >> that just turned out to be a bad idea. After commiting it, you might >> want to discard the erroneous change, like so: >> >> git reset --keep HEAD~1 >> >> The "--keep" option uses some safeguards to make sure that only the >> committed change gets discarded, instead of clobbering local changes >> at the same time. >> >> * In the early days of git, the "--keep" option did not exist. So a lot >> of old documentation recommends to do >> >> git reset --hard HEAD~1 >> >> which is the same if you don't have any local changes. > Yes, it would be good idea to examine git documentation (tutorials, > user's manual, manpages, perhaps "Git Community Book" and "Pro Git" > too) to encourage use of new safer options of hard reset, namely > '--keep' and '--merge' instead of '--hard'. >
begin:vcard fn:Massimo Manca n:Manca;Massimo org:Micron Engineering di Massimo Manca adr:;;via della Ferriera, 48;Pordenone;PN;33170;ITALIA email;internet:massimo.manca@xxxxxxxxxxxxxxxxxxxx tel;work:+39 0434 1856131 tel;fax:+39 0434 1851032 / 178 273 3543 tel;cell:+39 349 4504979 url:http://www.micronengineering.it version:2.1 end:vcard