Dropping a merge from history -- rebase or filter-branch or ...?
- Date: Fri, 7 Jul 2017 17:07:18 -0400
- From: Martin Langhoff <martin.langhoff@xxxxxxxxx>
- Subject: Dropping a merge from history -- rebase or filter-branch or ...?
long time no see! I'm trying to do one of those "actually, please
don't" things that turn out to be needed in the field.
I need to open our next "for release" development branch from our
master, but without a couple of disruptive feature branches, which
have been merged into master already. We develop in github, so I'll
call them Pull Requests (PRs) as gh does.
So I'd like to run a filter-branch or git-rebase --interactive
--preserve-merges that drops some PRs. Problem is, they don't work!
filter-branch --commit-filter is fantastic, and gives me all the
control I want... except that it will "skip the commit", but still use
the trees in the later commits, so the code changes brought in by
those commits I wanted to avoid will be there. I think the docs/help
that discuss "skip commit" should have a big warning there!
rebase --interactive --preserve-merges --keep-empty made a complete
hash of things. Nonsense conflicts all over on the merge commits; I
think it re-ran the merge without picking up the conflict resolutions
we had applied.
The changes we want to avoid are fairly localized -- a specific module
got refactored in 3 stages. The rest of the history should replay
cleanly. I don't want to delete the module.
My fallback is a manually constructed revert. While still an option, I
think it's better to have a clean stat without sizable feature-branch
- ask interesting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted ~ http://github.com/martin-langhoff
by shiny stuff