Say I introduced <feature.c> a while ago and now notice it shouldn't have been part of my main
branch but rather a branch feature
. Is it possible to use e.g. git-filter-branch
to automatically move all of <feature.c>'s history out of my main
branch into the feature
branch?
相关问题
- Why does recursive submodule update from github fa
- Extended message for commit via Visual Studio Code
- Emacs shell: save commit message
- Can I organize Git submodules in a flat hierarchy?
- Upload file > 25 MB on Github
相关文章
- 请教Git如何克隆本地库?
- GitHub:Enterprise post-receive hook
- Git Clone Fails: Server Certificate Verification F
- SSIS solution on GIT?
- Is there a version control system abstraction for
- ssh: Could not resolve hostname git: Name or servi
- Cannot commit changes with gitextensions
- git: retry if http request failed
Ok, here's my go:
Had I not commits manipulating <feature.c>, I could have branched of from <feature.c>'s first commit and then used
git cherry-pick
withgit log
in a loop, as suggested by Tim Visher. Starting from master I guess this should work:With
taghelperscript
being something likegit tag prefix.$1
(maybe this can be done better?). The tagging part probably only works for the lightweight tags I use. Also be advised that this does not work if <feature.c> has been renamed at some point, and if it existed already in the initial commit this might either cause two separate histories, or (my guess) a commit inmaster
which contains the deletion of <feature.c> which is likely to cause a merge conflict or confusion later.The trouble is, some of my commits modify other files, thus causing
git cherry-pick
to trigger an unresolved merge, or introduces these other files. So instead, I'll try somegit filter-branch
magic. Later. Stay tuned...It sounds like you're doing something fairly insane! :)
That said, I see a few options, none of which are particularly automated.
If you've got a ton of commits with that file present, just admit the mistake, make a new branch off of your HEAD, and put further commits with that feature into that branch until they're stable. If you're repo's shared, this becomes the only real option. No one wants to have divergent history, especially if that feature was committed deep in the history.
If you're only talking about 10 or so commits that have actually touched that file, and they're fairly recently committed without many other commits interleaved, you could check out a new branch on HEAD, and revert the branch you don't want this feature in back to before you added the feature, and then cherry pick commits you need out of the feature branch until you're ready to commit them all in at a later date.
If you're dealing with a ton of history, lots of interleaved commits, and you really don't want to have that feature present at all, you could write up a little shell script that takes the output of
git log
and cherry picks it into a new branch. Something along the lines of:Once you have that feature branch with all of the commits cherry picked out, you can then use
git filter-branch
to filter out all of the commits that reference that file. The man page has a simple example that does exactly that.Once you've got that, you can then
git rebase feature-x --onto <filtered-branch>
and you should be good to go.Of course that should be quite discouraged, especially if any of that is published.