threads / discuss / 22530

Re: reverting vs resetting

Subject: Re: reverting vs resetting

## tl;dr

5 messages between Feb 5, 2010 and Feb 5, 2010.

replies: 4people: 4as markdown or json

Mihamina Rakotomandimby· Feb 5, 2010, 06:12 UTC · lore

reverting vs resetting

Manao ahoana, Hello, Bonjour,
We put a gateway iptables script (SNAT, DNAT,...) under GIT.

Someone (Bob) made a mistake on it, but he did not know. That broke the gateway.

Another one (Andy), did not try to undo Bob's mistake but tried (and tried, and tried... always committing) to solve the problem. Andy made about 50 commits.

When we decided to giveup, we decided to get back to the configuration before Bob broke it. But it would be interesting to see Andy's history.

Reverting or resetting?
As far as I know: 
- Reverting Bob's commit will only cancel Bob's mistake but not Andy's
  tries to solve it.
- Resetting will forget the history.
Any suggestion?
Misaotra, Thanks, Merci.
-- 
       Architecte Informatique chez Blueline/Gulfsat:
    Administration Systeme, Recherche & Developpement
                +261 34 29 155 34 / +261 33 11 207 36
Avery Pennarun· Feb 5, 2010, 06:48 UTC · re: Mihamina Rakotomandimby · lore

On Fri, Feb 5, 2010 at 1:12 AM, Mihamina Rakotomandimby <mihamina@gulfsat.mg> wrote:

> When we decided to giveup, we decided to get back to the configuration
> before Bob broke it. But it would be interesting to see Andy's history.
>
> Reverting or resetting?
Try this:
    git checkout HEAD~5 .
    git commit -m "reverted back to the version before this mess"

Replace HEAD~5 with the revision you want it to look like. But don't forget the "." in the checkout line! All the magic is in there. When you specify a path ("."), git won't change the revision HEAD points to, but it will change all the files and the index to the ones from the specified version. Then you can commit these files, producing effectively a single commit that undoes a bunch of previous ones.

Have fun,
Avery
Junio C Hamano· Feb 5, 2010, 07:09 UTC · re: Avery Pennarun · lore
Avery Pennarun <apenwarr@gmail.com> writes:
Show 11 quoted lines
> On Fri, Feb 5, 2010 at 1:12 AM, Mihamina Rakotomandimby
> <mihamina@gulfsat.mg> wrote:
>> When we decided to giveup, we decided to get back to the configuration
>> before Bob broke it. But it would be interesting to see Andy's history.
>>
>> Reverting or resetting?
>
> Try this:
>
>     git checkout HEAD~5 .
>     git commit -m "reverted back to the version before this mess"
Caveat: if Andy added new paths while experimenting, the above won't
remove it.  You would need something like this instead:
	git read-tree -m -u HEAD~50
        git commit -m "reverted back to the version before this mess"

But this all assumes that the futile experiment is worth keeping. I highly doubt it.

I would recommend to do this:
	git branch andy_failed_experiment
        git reset --hard HEAD~50
	;# and perhaps revert Bob's change here as well

There is no sane reason to keep the failed experiment that added nothing of value to the history leading to the tip of the 'master' branch.

I am using the word _value_ but keep in mind that value is relative to the purpose you have in mind. The purpose of the 'master' branch presumably is to keep and to improve on a working configuration of the gateway box. For that particular purpose, you have to admit that Andy's futzing around didn't add anything of value in the result. Hence, that shouldn't be kept in its history.

Andy and other people may be able to learn from the failed experiment later, so it is perfectly Ok to keep the series of random hacks in a separate branch to study at their leisure. The purpose of the branch is different from that of the 'master': it is to serve as a catalog of things/ideas that did _not_ work.

Matthieu Moy· Feb 5, 2010, 08:41 UTC · re: Junio C Hamano · lore
Junio C Hamano <gitster@pobox.com> writes:
> 	git branch andy_failed_experiment
>         git reset --hard HEAD~50
> 	;# and perhaps revert Bob's change here as well

So would I, and to complement Junio's answer: keeping a failure followed by a repair means this experiment will appear more or less forever in the output of "git log", "git blame", will break "git bisect" on that part of history, and so on. Putting it on a separate branch avoids this, and keeps it in a safe place to show newcommers: "see, here's what you should not do" ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Mihamina Rakotomandimby· Feb 5, 2010, 11:21 UTC · re: Matthieu Moy · lore
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> :
> So would I, and to complement Junio's answer
Thank you all.
-- 
       Architecte Informatique chez Blueline/Gulfsat:
    Administration Systeme, Recherche & Developpement
                +261 34 29 155 34 / +261 33 11 207 36

← back to recent threads