0
  1. I was on current branch and did commit good.
  2. Then I commited irrelevant.
  3. I went back, checked out good (detached HEAD now).
  4. I did commit one, in detached HEAD state.

I would like to have some help to put one just after good, in current branch.

It doesn't matter if I lost irrelevant.

KcFnMi
  • 5,516
  • 10
  • 62
  • 136
  • Regarding your edit, commits aren't "on" or "in" branches. Git calls all the various ways to refer to commits "references", and "a branch" in git is just "a branch tip reference", a label for a currently-particular commit. You can rehang the label anywhere you like, at any time. When you do a `git commit`, git rehangs the `HEAD` reference, and that's it. Really. A huge portion of the confusion around git derives from people's preconceived notion that this has to be hard or complicated. It's not. It's simple. What you can _do_ with it gets complicated, but that's the job, not the tool. – jthill Oct 28 '16 at 21:39

1 Answers1

2
  1. I went back, checked out good (detached HEAD now).
  2. I did commit one, in detached HEAD state.

I would like to have some help to put one just after good.

one is after good. git commit updates HEAD, every time, no matter what. When you check out a branch tip, git sets the HEAD reference as an alias for that branch tip reference, it "attaches" it to that branch tip reference. A detached HEAD is just a reference directly to a particular commit, so when git commit updates it, HEAD now refers to the new one. But git commit always adds the old HEAD commit as the parent of the new one.

So just

git checkout -B current one               # if you don't still have `one` checked out

or just

git checkout -B current                   # if you do
Community
  • 1
  • 1
jthill
  • 55,082
  • 5
  • 77
  • 137
  • 1
    This is the right (upvoted :-) ) answer, and the easiest way to deal with the situation. I will add one nuance (which I'm sure jthill knows and it's mostly irrelevant, so a comment makes a good footnote): the *always* here gets modified slightly when you use `git commit --amend`. The `--amend` option tells `git commit` to use, not the current (HEAD) commit, but rather the current commit's parent(s). That's how Git fakes the amending (which isn't actually changing *anything*, but instead is adding a new commit, as usual—well, *almost* as usual). – torek Oct 28 '16 at 21:06