On Fri, Mar 14, 2008 at 03:52:14AM -0700, Jakub Narebski wrote:
> "Geoff Russell" <geoffrey.russell@xxxxxxxxx> writes:
>
> > 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.
>
> 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.
[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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
