# git reset --hard <commit> superfluous?

3 messages from 2009-01-03 to 2009-01-03. Participants: chris@seberino.org, Sitaram Chamarty, Björn Steinbrink.
Thread: https://gitlist.dev/t/16975

## chris@seberino.org, 2009-01-03 01:13

Subject: git reset --hard <commit> superfluous?
Message-ID: <20090103011319.GA24149@seberino.org>
URL: https://gitlist.dev/e/20090103011319.GA24149%40seberino.org

```
David

git reset --hard <commit>
"resets" the current branch head.

Is this equivalent to deleting the branch
and doing

git branch <branch> <commit> ??

So "git reset --hard" is syntactic sugar and 'unnecessary' right?

cs

```

## Sitaram Chamarty, 2009-01-03 06:34

Subject: Re: git reset --hard <commit> superfluous?
Message-ID: <slrnglu1ms.63u.sitaramc@sitaramc.homelinux.net>
URL: https://gitlist.dev/e/slrnglu1ms.63u.sitaramc%40sitaramc.homelinux.net
In-Reply-To: <20090103011319.GA24149@seberino.org>

```
On 2009-01-03, chris@seberino.org <chris@seberino.org> wrote:
> git reset --hard <commit>
> "resets" the current branch head.
>
> Is this equivalent to deleting the branch
> and doing
>
> git branch <branch> <commit> ??
>
> So "git reset --hard" is syntactic sugar and 'unnecessary' right?

only if you don't have any local changes to the work tree or
the index :-)

If you do, however, the reset throws them away, while the
longer method tries to preserves them, to the point of not
letting you switch if there are too many changes.

```

## Björn Steinbrink, 2009-01-03 12:20

Subject: Re: git reset --hard <commit> superfluous?
Message-ID: <20090103122001.GA20199@atjola.homenet>
URL: https://gitlist.dev/e/20090103122001.GA20199%40atjola.homenet
In-Reply-To: <20090103011319.GA24149@seberino.org>

```
On 2009.01.02 17:13:19 -0800, chris@seberino.org wrote:
> David
> 
> git reset --hard <commit>
> "resets" the current branch head.
> 
> Is this equivalent to deleting the branch
> and doing
> 
> git branch <branch> <commit> ??
> 
> So "git reset --hard" is syntactic sugar and 'unnecessary' right?

Deleting the branch also deletes the reflog, while using reset adds a
new entry to the reflog. So returning the branch head to its previous
state is pretty trivial if you used reset and might be pretty hard if
you deleted the branch. HEAD's reflog should probably have the right
entry as well, but chances are that it's hidden in a crapload of other
entries, especially if you rebase often.

Björn

```