(I don't know which branch this is, feature_orig or mainline!) Get onto the branch you want the merge commit to show up in: $ git checkout. Now we have this: C - D - E - F <- feature_orig But at most, I suspect you will want to keep feature_orig, not the rebased line.) Let's move one more branch name around now, to-I hope-make the picture clearer: $ git branch -m feature feature_rebased If merging feature into mainline, maybe not. One other question though: do you want to keep the feature branch around? (If you're merging mainline into feature here, you probably do. Except, you want it to happen on/with feature_orig, rather than the rebased feature. What you want now (per the original question) is a merge: either "merge feature into mainline" or "merge mainline into feature". The above is what you can see after you do git branch feature_orig ORIG_HEAD (or recover the original tip from reflogs and use that to create feature_orig). The point is that commit F' captures the "final, all-resolved" version of the work-tree: C - D - E - F <- feature_orig I'll assume that in rebasing you modified commits C and F and dropped D and E entirely as no-longer needed. (Exactly why should be obvious once you understand the rest of this.) That is, we want to resurrect the old branch tip, and also keep the new branch tip. Give it a label (branch or tag name), while also keeping a label on the post-rebase chain. If not, find the old branch-tip in the reflogs. The original chain of commits (pre-rebase) is likely still pointed-to by ORIG_HEAD. What to do then? Assuming you're quite confident of your resolution :-) you could try this. ![]() Then if you reset things to pre-rebase state and "git merge" it should "re"use them (the last "re"). As Amber said in a comment, if you turned on rerere, git will have "re"corded your previous "re"solution (two of the three re's).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |