Disclaimer: I’ve only used “graft points” myself once in a toy repository. But it is an obscure feature which you may not have heard of, and which _may_ be helpful in your situation. You could use “graft points” to fake the ancestry information. See, e.g., What are .git/info/grafts for? or proceed immediately to the git … Read more
It says: When you save and exit the editor, it will rewind you back to that last commit in that list and drop you on the command line with the following message: $ git rebase -i HEAD~3 Stopped at 7482e0d… updated the gemspec to hopefully work better You can amend the commit now, with It … Read more
VonC has the answer you’re looking for, the Rebase Extension. It is, however, worth spending a second or two thinking about why neither mq nor rebase are enabled by default in mercurial: because mercurial is all about indelible changesets. When I work in the manner you’re describing, which is nearly daily, here’s the pattern I … Read more
Short answer You omitted the fact that you ran git push, got the following error, and then proceeded to run git pull: To [email protected]:username/test1.git ! [rejected] dev -> dev (non-fast-forward) error: failed to push some refs to ‘[email protected]:username/test1.git’ hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. … Read more
Here’s what the rerere-train.sh script I mentioned in my comment does—essentially it redoes the merge, uses your resolution, and just lets rerere see it. You could do this manually just for your single commit if you like: git checkout <parent of merge commit> git merge <merged commit> # if this goes cleanly, we’re done git … Read more
TL;DR: it’s the fork point code You are getting the effect of git rebase –fork-point, which deliberately drops Dan’s commit from your repository too. See also Git rebase – commit select in fork-point mode (although in my answer there I don’t mention something I will here). If you run the git rebase yourself, you choose … Read more
It looks, that someone pushed new commits between your last git fetch and git push. In this case you need to repeat your steps and rebase my_feature_branch one more time. git fetch git rebase feature/my_feature_branch git push origin feature/my_feature_branch After the git fetch I recommend to examine situation with gitk –all.
A few notes on how git works (non technical): When you rebase, git takes the commits in question, and “recommits” them on top of a clean history. This is to prevent the history from showing: Description: tree -> mywork -> merge -> mywork -> merge -> mywork -> merge Commit SHA1: aaaa -> bbbb -> … Read more
It seems there is still a pending question in the thread: How to do it globally (i.e. for all branches) ? For the records, we can use the following: git config –add merge.ff false …to make it apply to all branches in the current repository. To make it apply to all branches in all repositories … Read more
Update July 2012 (git 1.7.12+) You now can rebase all commits up to root, and select the second commit Y to be squashed with the first X. git rebase -i –root master pick sha1 X squash sha1 Y pick sha1 Z git rebase [-i] –root $tip This command can now be used to rewrite all … Read more