About detached heads

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

?

         git checkout 3...

gets me the commit on a detached head, but I don't know how to put this back as the HEAD.

I'm on git 1.5.0.5

Cheers, Geoff Russell

On Fri, Mar 14, 2008 at 9:46 AM, Geoff Russell <geoffrey.russell@gmail.com> wrote:

Two options.  Either rewrite history, nuking commits 4 & 5 :
  git reset --hard 3

or publicly reverse the changes introduced by 5 & 4 :
  git revert 5
  git revert 4

Jon

"Jonathan del Strother" <maillist@steelskies.com> writes:

The revert can be done by resetting to the tree in 3:

  git checkout 3 -- .
  git commit -m "reset to 3"

El 14/3/2008, a las 10:46, Geoff Russell escribió:

How about?

   git cherry-pick the-sha-1-id-of-commit-3

Wincent

Wincent Colaiuta <win@wincent.com> writes:

Correct me if I'm wrong, but I believe this will try to re-apply commit 3 (probably a no-op since commit 3 is already in the history, perhaps tons of conflicts if 4 and 5 touched the same pieces of code).

The OP wants to keep commit 3, and to revert commits 4 and 5. As mentionned in other messages, either "git revert" 4 and 5, or just commit a new revision with the same tree as 3 had.

El 14/3/2008, a las 11:48, Matthieu Moy escribió:

I thought the OP was saying that 4 and 5 somehow undid the effect of 3 and he wanted to reapply it. But he probably meant what you said, he just wants to reset back to 3.

Wincent

"Geoff Russell" <geoffrey.russell@gmail.com> writes:

Lets check what git does in each of scenarios. Let's assume that current branch is named 'master'.

At beginning we have:

   1---2---3---4---5    <--- master <--- HEAD

HEAD contents is "ref: refs/heads/master"

1. Now, "git checkout 3...", which is equivalent to "git checkout 3",
detaches HEAD because commit '3' is not a head (is not a branch), so
we have:

   1---2---3---4---5    <--- master
           ^
            \ 
             \-------------- HEAD

HEAD contents is "<sha1 of 3>"

2. If we did "git reset --hard 3" we would rewind the history,
resulting in the following situation:

   1---2---3           <--- master <--- HEAD
            \           
             \-4---5   <... master@{1}, ORIG_HEAD, HEAD@{1}
              
and now commits 4 and 5 are referenced only by reflogs, and by the
(temporary) "last position of HEAD" reference named ORIG_HEAD.

3. Now, if you have published 1..5 history you would not want
(usually) to rewind published branch. If you do the following:

  $ git revert --no-commit 5
  $ git revert 4

you would get the following:

   1---2---3---4---5---(5^-1 4^-1 => 3)  <--- master <--- HEAD

git-revert applies reversal of changes in given commit, in the "patch -R" ("patch --reverse") sense. Using '--no-commit' option allows to squash reverting two commits into one commit. The ordering of reverting ensures that there are no merge conflicts.

4. Or you can just put the _contents_ of revision 3 into your working
tree, either using plumbing command git-read-tree, or by checking out
or resetting to top tree: "git checkout 3^{tree}", or 
"git checkout 3 -- .", or equivalent git-reset invocation.

This way you would get exactly

   1---2---3---4---5---3   <--- master <--- HEAD

but the relation of 5---3 parentage is unclear: you would have to explain it in the commit mesage.

HTH

Jakub Narebski <jnareb@gmail.com> writes:

[...]

the working tree in now dirty...

and this one fails with dirty tree :(

Probably:

$ git revert -n 5 && git revert -n 4 && git commit -a

BTW, why git-revert doesn't take a range? Is there some fundamental problem with it?

-- Sergei.

* Jakub Narebski [14 III 2008 11:52]:
 > Lets check what git does in each of scenarios. Let's assume that
 > current branch is named 'master'.
 >
 > At beginning we have:
 >
 >    1---2---3---4---5    <--- master <--- HEAD
 >
 > HEAD contents is "ref: refs/heads/master"
 >
 > 1. Now, "git checkout 3...", which is equivalent to "git checkout 3",
 > detaches HEAD because commit '3' is not a head (is not a branch), so
 > we have:
 >
 >    1---2---3---4---5    <--- master
 >            ^
 >             \
 >              \-------------- HEAD
 >
 > HEAD contents is "<sha1 of 3>"
 >
 >
 > 2. If we did "git reset --hard 3" we would rewind the history,
 > resulting in the following situation:
 >
 >    1---2---3           <--- master <--- HEAD
 >             \
 >              \-4---5   <... master@{1}, ORIG_HEAD, HEAD@{1}
 >
 > and now commits 4 and 5 are referenced only by reflogs, and by the
 > (temporary) "last position of HEAD" reference named ORIG_HEAD.
 >
 >
 > 3. Now, if you have published 1..5 history you would not want
 > (usually) to rewind published branch. If you do the following:
 >
 >   $ git revert --no-commit 5
 >   $ git revert 4
 >
 > you would get the following:
 >
 >    1---2---3---4---5---(5^-1 4^-1 => 3)  <--- master <--- HEAD
 >
 > git-revert applies reversal of changes in given commit, in the
 > "patch -R" ("patch --reverse") sense. Using '--no-commit' option
 > allows to squash reverting two commits into one commit. The ordering
 > of reverting ensures that there are no merge conflicts.
 >
 >
 > 4. Or you can just put the _contents_ of revision 3 into your working
 > tree, either using plumbing command git-read-tree, or by checking out
 > or resetting to top tree: "git checkout 3^{tree}", or
 > "git checkout 3 -- .", or equivalent git-reset invocation.
 >
 > This way you would get exactly
 >
 >    1---2---3---4---5---3   <--- master <--- HEAD
 >
 > but the relation of 5---3 parentage is unclear: you would have to
 > explain it in the commit mesage.

I suggest one should add the above nice explanation to FAQ or some wiki material.

BR, /Adam

On Fri, Mar 14, 2008 at 03:52:14AM -0700, Jakub Narebski wrote:

[Great explanation.  Let me offer one minor clarification:]

 This way you would get exactly:
 
    1---2---3---4---5---3'   <--- master <--- HEAD
 
 While the 3' commit has the same contents as 3, it is a new, distinct
 commit with its own history.  Its commit message should explain why
 you want to go from 5 back to the contents of 3.

-chris

On 14/03/2008, Chris Shoemaker wrote:

Just a small question -- does that mean that 3 and 3' share the same tree object ?

On Fri, 14 Mar 2008, Rafael Garcia-Suarez wrote:

Yes. However, they don't share the same parent in the commit object, so even if the commit text was the same and the time stamps were forced to be the same, the commit 3' won't have the same SHA1.

Nicolas

On Fri, 14 Mar 2008, Rafael Garcia-Suarez wrote:

Yes it does. 

Commit object has link to a tree object in the form of its sha1 id, and repository's object store is content addressed, or to be more exact sha-1 id of contents addressed.

On Fri, 14 Mar 2008, Geoff Russell wrote:

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

On 2008.03.14 10:53:25 -0700, Linus Torvalds wrote:

Hm, that's just squashing revert commit. Squashing can be done via: git reset --soft HEAD~5 # Or wherever your squashed commit should start git commit -m "Squashed from HEAD~5 onwards"

Now the "revert" version of that: git reset --hard HEAD~5 # Go back to the state that we want git reset --soft ORIG_HEAD # Move HEAD back, but keep the index as is git commit -m "Back at the state of HEAD~5"

AFAICT that should have the same advantages as using read-tree, but doesn't feel so low-level :-)

Björn

On Fri, 14 Mar 2008, Bj?rn Steinbrink wrote:

Umm. The low-level one is a *lot* easier to understand than your "high-level" one, wouldn't you say?

And when the low-level plumbing commands are easier, are they not then better porcelain?

		Linus

Linus Torvalds <torvalds@linux-foundation.org> writes:

AFAIK the porcelain equivalent to plumbing

  git read-tree -u -m 3

is just

  git checkout 3 -- .

On Fri, 14 Mar 2008 12:11:33 -0700 (PDT) Jakub Narebski <jnareb@gmail.com> wrote:

Hi Jakub,

   git checkout .   won't remove paths, so you could end up with extra
state that didn't exist in the earlier commit.

Sean

I thought my question was trivial, but judging by the number of answers, clearly not!

I understand "git read-tree -u -m 3 ; git commit" and it does exactly what I want.

The context where I want to use this is for users who update files, can understand "take me back to the state I was in at 4pm yesterday before I mucked up my data" but who don't want to know about merging, branching, topics, etc, etc, But of course having taken them back to the 4pm commit, they then realise that they really need the 6pm commit or perhaps the 3pm commit. So anything which just throws away commits would be risky.

The "git read-tree -u -m 3; git commit" allows me to present a simple straight line view of the data, which is perfect for the people I'm dealing with.

Many thanks to you all,

Cheers, Geoff Russell

"Geoff Russell" <geoffrey.russell@gmail.com> writes:

Thanks to the reflog even if they go the "git reset --hard 3" route, the commits would be protected for gc.reflogExpireUnreachable period, which defaults to 30 days, by reflog. After this period they could be garbage-collected.

Simple, straight line with _rewinds_, i.e. not so simple history.

Unless you can expect users to find errors later than 30 days, or you have pushed non-rewritable branch already, then "git reset --hard 3" is IMHO a beter solution than "git read-file -u -m 3 && git commit -a".

On Sat, 15 Mar 2008, Geoff Russell wrote:

The reflog can help you there as well.  You can simply do:

	git reset --hard HEAD@{yesterday.at.4pm}

and it'll magically bring you back to the state you were yesterday at 4pm. You need the 6pm state instead? No problem: just ask for yesterday.at.6pm then.

And before doing the 'reset --hard', you might want to do a simple 'checkout' beforehand so you can be sure it actually corresponds to what you want:

	git checkout HEAD@{yesterday.at.4pm}
	[compile, test, whatever]
	git checkout HEAD@{yesterday.at.6pm}
	[compile, test, whatever]

and when OK with it, then:

	# return to your master branch (or any other branch)
	git checkout master
	# then reset it to the desired state
	git reset --hard HEAD@{yesterday.at.6pm}

Nicolas

On 3/15/08, Nicolas Pitre <nico@cam.org> wrote:

More useful advice ... many thanks.

Cheers, Geoff.