4 ms·
This is a feature I've wanted for such a long time. While it's perfectly feasible to do through the command line, I've always found myself having to force push
by ianleeclark 11y ago
This is a feature I've wanted for such a long time. While it's perfectly feasible to do through the command line, I've always found myself having to force push to update the history on github's side of things.
I typically did it through git rebase -i HEAD~N, so maybe someone here on HN knows of a better way to squash a commit whenever you're updating remote history. Albeit, it seems that updating remote history with a squashed commit isn't entirely attractive behavior and that's why I was forced to force push.
- klodolph 11y agoTwo things you can do differently, if you feel this would be appropriate. Instead of git rebase -i HEAD~N, I typically use git reset --soft HEAD~N followed by git commit. Instead of git push --force, use git push --force-with-lease. This only updates the remote if the remote's current state is what you expect. For example, it will fail if someone else has pushed to the same branch in the meantime.
- azernik 11y agoUsually I'll do git rebase -i origin/master (or upstream/master, or wherever in branched off of on the first place). Doesn't require me to count up to N commits, and also does an actual rebase. But yeah, force push is kind of inherent to the process - you're rewriting history, no two ways about it. Usually for my own forks of projects, though, I'll go into .git/config and add a 'push' option with a + in front of the refspec - this enables force pushing always. This really only works and is safe for workflows where there's a distinction between your own personal GitHub account and the upstream that has the authoritative copy - you really don't want to rewrite history by accident on the latter.