Rebasing the main branch really is fully rewriting history (and this isn’t a squash commit). But this shouldn’t be called “rewriting history” in my book. Squashing a local branch does, in a way, rewrite local commit history. But Fossil’s distinction is more rigid and it considers anything ever committed to be history. I would argue the team-wide destination branch history is what should be called “history”, and the only thing that matters. Squash commits rewrite the source branch history, but they don’t rewrite the destination branch history. I saw this was downvoted and tried to help by upvoting, but it is worth talking about what “history” means though.
That kind of mis-representation ruffles my feathers a little bit, but I've had discussions with the Fossil team right here on HN about it, and they have in fact been open to listening, responsive, and willing to change and improve the messaging. But that page still says rebase is "dishonest", which is a deeply ironic claim, if you catch my drift. Some is there still, for example I'm quite pleased to see that a lot of the most hyperbolic verbiage is gone now, it used to carry on quite a bit. It is the key to working around git's strict commit parentage, and makes it easy to sculpt changes so they're palatable for me and my team.Ībove I was referring to some of the anti-rebase messaging Fossil has put out in the past. Rebasing my local workspace, it turned out, is the answer to that.
#SOURCETREE ATLASSIAN HOW TO#
Because git is strict about commit ordering and P4 is not, I was struggling to figure out how to manage multiple in-flight changes like I would in P4, and how to clean up and push something that wasn't a hot mess. Git does have a steep learning curve and a bumpy interface that most people (including yours truly) never get all the way through.įWIW, my intro to rebase came after using Perforce for years. And you're totally right, there is definitely resistance to rebase outside of Fossil, and even within the git community with people who've never heard of Fossil. Rewrite history is an okay metaphor, not great but nothing super wrong with it as an approximation. Rebase is a tool designed to reorder a sequence of commits, mostly for the purposes of making local changes presentable before pushing them, and has other legitimate uses too. I’m in favor of better VCSs, but the claim that rebase is a history rewrite is hyperbolic, and the judgement on top of that is silly and misguided. The framing of git rebase as a history rewrite, the very idea that rewriting history is bad, came from the Fossil team in an attempt to convince people to try Fossil and cast shade on git. Git never promised a “history” per se, not in the form of an immutable record of events.
We often choose to preserve the rebased sequence, but this distinction is not academic, it’s critically important because as a part of a version control system, rebase can be undone, precisely because it does not write over the old history. Git rebase provides a new, second, altered sequence of commits.
#SOURCETREE ATLASSIAN CODE#
Git isn’t a tool for preserving history, it’s a tool for keeping track of code changes. We don’t need a reasonable definition of rewriting history, we need a better conversation about what our tools are even for. Maybe it'll be built into one of these virtual workspaces as an overlay-fs, so its transparently auto-saved to a central store instead of manipulating the existing file system like git. You'd certainly not store the "fat" history of changes locally, and big assets/binaries/etc would be better supported. What will VCS look like when everything is always-connected and (maybe?) cloud hosted? Maybe it'll allow "sharing" of workspaces, so you can build big features as a team (instead of feature branches being pushed/pulled). I think "thin client" reproducible workspaces are the next evolution. Cheap to spin up for each feature, instead of branching/pushing/pulling on one local repo. We're starting to see a lot of various tools that are basically VM/Container workspaces that you work out of.
Any big change is going to come as we already change how we work. Personally, my bets are on the next VCS being more "workspace" centric as a next-step evolution. We're seeing progressively more integrated build tools (Cargo, NPM, vs anything C/Java). I think aggressive linting is starting to help with whitespace and formatting adding noise to diffs. I think this will come, but it may be more broken up through build tools that include this functionality, not a singular VCS. a tool that understands language syntax and can track when a symbol is changed. The next big thing will be semantic code versioning.