Is there a way to squash a number of commits non-interactively?
Make sure your working tree is clean, then git reset –soft HEAD~3 git commit -m ‘new commit message’
Make sure your working tree is clean, then git reset –soft HEAD~3 git commit -m ‘new commit message’
I saw this still here so I figured I might as well answer the question. So the answer is YES. It will remove the contributions from the graph. It won’t do it right away because commits that are no longer being pointed to by anything can technically still be reached for awhile but are eventually … Read more
I’ve managed to work around this by: Locate the last commit that retained the order Run git rebase -i <hash of that commit> Replace all pick with reword Run git push -f Before that, I tried changing only the first commit message, which also changes all the following hashes, but that didn’t fix it. I … Read more
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
Short answer You omitted the fact that you ran git push, got the following error, and then proceeded to run git pull: To git@bitbucket.org:username/test1.git ! [rejected] dev -> dev (non-fast-forward) error: failed to push some refs to ‘git@bitbucket.org:username/test1.git’ hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. … 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
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
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