4 ms·
The whole misunderstanding ``git-rebase mangles history'' revolves around the concept of history. For me, history in DVCS should be about logical changes that
by dexen 14y ago
The whole misunderstanding ``git-rebase mangles history'' revolves around the concept of history.
For me, history in DVCS should be about logical changes that introduce given feature(s), fix bug(s) etc., and not be about raw, unprocessed changes, not be edition of `physical' bytes. Whenever I make a mistake in a commit (be it a typo, a small bug or perhaps I went in wrong direction and backtracked later on) I either --amend it, or, if it's an earlier commit, git rebase --interactive to fix it.
In other words, ask yourself, ``Would this commit stand for a good LKML submission?'' Until it does, it's --amend or git rebase --interactive time. Refactor history just as you refactor code ;-)
Of course, once the code is pushed to a shared repo, the genie is out of the bottle and there's no changing it. But that's a different matter.
What you want to do is:
* 1) clean up history with git-pull --rebase, git-rebase --interactive and git commit --amend,
* 2) then optionally perform git merge --no-ff --log --edit $your_feature_branch while on $upstream_tracking_branch, to create a new, merge-ish commit that covers the whole new feature you've been working on.
This way you have:
* clean history
* logical, standalone commits
* complex features introduced by a separate merge-ish commit (which you can git-rollback as whole, if need be).
My rule of thumb for the step 2) -- do it when there's three or more commits introducing a particular feature.
I perform the step 2) often enough to have created a short wrapper script for it [1].
[1] https://gist.github.com/dexen/f36cb1668b5c04eb5abd https://gist.github.com/dexen/f36cb1668b5c04eb5abd
[ lotsa small edits for cleanups -- sorry ^^; ]
- jgraham 14y agoEven the "don't rebase once code is pushed to a shared repo" thing is more of a guideline than a hard and fast rule. For example you might reasonably want to clean up the history on branches that you have previously: * Pushed to a distributed test system * Pushed to a branch based code review tool (e.g. Opera Critic or Gerrit). Using a heavily rebase-centric workflow for several years, with rebases on semi-public branches like those described above an expected part of the process, I don't think that history rewriting has ever caused me an actual problem. So my gut feeling is that people spend a lot of time trying to avoid something that sounds theoretically bad but isn't much of a problem in practice as long as some common sense is employed.
- jedbrown 14y agoThe intent is "don't rebase if you might have a downstream". You're welcome to rebase branches that you push as long as your workflow specifies that they are still volatile. For example, we push unfinished topic branches to our team repo as backup and to allow "passive review" (a pull request is "active review"). Comments at this stage are communicated by bitbucket line comments (or by email/chat) and are handled by amending the topic branch. This unmerged topic branch is rebased any time the author prefers to start from a later 'master' in exchange for re-testing the series. When the topic is considered complete by the author, she either makes a pull request or merges to 'next' herself. Merging to 'next' signifies that another topic may depend on that branch. In this workflow, an unmerged topic branch is roughly equivalent to a patch series on a mailing list, but doesn't require email client integration and degrades more gracefully with less disciplined commit factoring and less sophisticated tool use.
- dlitz 14y agoThere's a loose convention of using the suffix, "-wip", to name published branches that you plan to rebase.