Re: About detached heads

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mar 14, 2008, 17:53 UTC
Message-ID: <alpine.LFD.1.00.0803141041080.3557@woody.linux-foundation.org>
In-Reply-To: <93c3eada0803140246k53408c74m21f9dc277857202d@mail.gmail.com>

On Fri, 14 Mar 2008, Geoff Russell wrote:

Show 8 quoted lines

>
> This should be simple! I have a series of commits:
> 
>            1---2---3---4---5
> 
> I want to go back to 3 but not branch, so I want
> 
>            1---2---3---4---5---3

This is actually an uncommonly easy operation for core git, but it's a very unusual thing to want to do in general, so I don't think there is any high-level command to do it directly. But it's really easy to do with a single so-called "plumbing" command, namely "git read-tree".

So the "core git" way to do it is to literally just do

	git read-tree -u -m 3
	git commit

(or use "--reset" instead of "-m" if you want to do it even in the presense unmerged entries).

What the above does is to literally just read the tree state at "3", and make it the new index: the "-u" means that we also want to update the working tree to that state, and the "-m" means that we will merge in the old index stat information.

The commit then will then create the actual new commit: it will have the exact same tree as your commit '3', but it will be a new commit (so call it 3').

Of course, people have already pointed out that another easy way to do it is to just revert 5 and 4. That may be the more high-level way to do it, but the git-read-tree approach actually has the advantage that it will work even across merges etc, and it will be very unambiguous: we want *exactly* the state at commit 3 back, nothing else.

			Linus