5

It happens all the time at work, that someone accidentally commits something to master instead of to the intended feature branch, the person then tries to resolve it, only to have the changes suddenly disappear. I have searched thick and thin, and can find no documentation to shed light on why this happens, or how to remedy the situation.

Here are steps to reproduce:

$ git init $ echo hello world > testfile $ git add testfile $ git commit -m 'init' $ git branch A $ echo abc >> testfile $ git commit -am 'append abc' $ git revert HEAD --no-edit $ git checkout A $ echo fff > secondfile $ git add secondfile $ git commit -m 'Add second file' $ git cherry-pick master^

At this point the git history looks like this:

$ git log --oneline --all --graph --decorate * ac6f9b4 (HEAD -> A) append abc * 54be952 Add second file | * 9ba1f16 (master) Revert "append abc" | * ef7c8d6 append abc |/ * 65a885d init

Watch then what happens when I rebase branch A on top of master:

$ git rebase master $ git log --oneline --all --graph --decorate * 9d08739 (HEAD -> A) Add second file * 9ba1f16 (master) Revert "append abc" * ef7c8d6 append abc * 65a885d init

What happened to the commit that was at the head of A, commit ac6f9b4? Where did it go? why wasn't it reapplied?

While this was just a small example with a single commit missing on the end, but sometimes we end up losing several commits from the middle of a long commit chain, and then they seem practically invisible :(

Improve this question
1
  • As a side note, I know Github at least allows you to restrict direct pushes to master and require PRs instead. Commented Jul 5, 2017 at 23:42

1 Answer 1

Reset to default
4

Rebase doesn't re-apply commits that have already been applied in the new base -- here, it's your append abc change. It's already in the master history. This is so often right that git does this without comment. It's arguably at least worth mentioning in the presence of subsequent reverts.

To see whether anything you're rebasing is already part of the new base history (master, here),

git log --oneline --cherry ...master

and look for =-marked commits. Those are commits in master that match commits in your branch; rebase won't re-apply them. Swap master... for ...master to see the local equivalents.

If you want an effectively blinded rebase, a first cut is

git checkout -B A master git cherry-pick ..A@{1} # < added the very important `..` by edit

which just moves A onto master and then cherry-picks everything you just left behind. To ignore merges (which you probably should), add --no-merges to the cherry-pick, it turns out when you ask cherry-pick for a series it just passes the whole set to git rev-list so you can use the machinery directly:

git cherry-pick --no-merges ..A@{1} # just learned now that cherry-pick takes this
Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

I like your post, the git log command is very helpful, although it doesn't actively fix the problem it helps a great deal in pinpointing and verifying what might go wrong.. I also like your cherry pick, I didn't know that trick, however, the cherry-pick doesn't completely solve the problem either, because you can't (as I just discovered) cherry-pick merges. Thus, the command died half way through on my real world example ;(
Well, one thing at a time. I think this answers your question as asked, if you've got another question about something you didn't mention before, how about asking that as another question?
No doubt about it. You will receive credit where credit is due. In the mean time, there's no harm in striving toward the most universal solution, or do you disagree? also for the sake of people reading this in the future.. I can manually cherry-pick past the merges. I can also rebase and then identify and re-cherry-pick the missing commits using the git log command.. but.. git is smart, and used by so many people, surely there is a command that will do the right thing, and if by pointing that out it sparks an idea of how to solve it, all the better for us and all that come after :)
Alright, but the only new thing you mentioned was merges—rebase ignores those, too, were you just looking for git cherry-pick $(git rev-list --no-merges ..A@{1})?
hm.. nope, that applies the commits in reverse order. However, trying to recover from the mess that caused, I discovered that you can git cherry-pick --continue when you've resolved an issue, and it continues the cherry-pick.. so with that in mind your original suggestion seems to solve the issue perfectly. It doesn't preserve the branching and merging, however, it does preserve the commits on either side, so all in all exactly like rebase, except for the not dropping commits. So I thank you kindly, and apologize for not recognizing the genious of your solution immediately :)
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.