3 ms·
This is a bit of a tangent but I've been on teams that demanded you rebase everything so that there's a linear history. Of course this leads to nasty conflict
by wmil 13y ago
This is a bit of a tangent but I've been on teams that demanded you rebase everything so that there's a linear history.
Of course this leads to nasty conflict resolutions, so they solve that by squashing all of their commits before rebasing.
Now your code is no longer in the repo.
- zwegner 13y agoWell, I definitely prefer the rebasing route, but with the caveat that everyone's working on the same branch, so there's not much divergence. The only rebasing occurs when somebody commits before you do, and it's only your own local commits that need conflict resolution.
- amputect 13y agoThat seems like a git anti-pattern. On the other hand, one or two repos where I work have developed some, uh, interesting network graphs, as various branches have merged and evolved.
- lomnakkus 13y agoWhat do you mean by "your code is no longer in the repo"?
- tjgq 13y agoI suppose (s)he means that, if you squash commits, you lose the intermediate states containing code that was later deleted. It's not necessarily bad - squashing is a useful tool to clean up your changes before you merge them in.
- thedufer 13y agoIf you squash together the commits that added and deleted a line, that line never existed.
- skybrian 13y agoBut if it never appeared in the main branch then it doesn't really matter, does it? You don't want to clutter up the history with experiments and false starts.
- girvo 13y agoWeirdly: yes, I do. It's handy, and those experiments show what I've done to tackle a problem. Numerous times those experiements that I've left in the repo somewhere have come in handy. Hell, we keep our feature branches around here. *shrugs
- wtetzner 13y agoI'm not sure that you don't. Having a history of how you got to the current version could help future maintainers understand why you made the decisions you did, and prevent them from making similar mistakes.
- derekp7 13y agoI tend to work out of a private branch, and commit early and often. So I end up with a lot of commits that say "fixed foo to be 1", then "oops, I meant it to be 2", then "No, it should be -7", etc. I'll drop a tag, then rebase a group of commits to re-order them (so all the fix, to a fix, to a typo mistake that shouldn't have been there) are together. Then sometimes I'll drop another tag, then squash, then rebase onto the main branch. Those temporary tags then get pushed only to a separate repo that only I write to (the one that everyone else uses gets the cleaned-up presentable code).
- wtetzner 13y agoI'm not sure that you don't. Having a history of how you got to the current version could help future maintainers understand why you made the decisions you did, and prevent them from making similar mistakes.