5 ms·

I completely agree that rebase and manipulating the graph history is part of the design of git. But also you can use git effectively without manipulating the h

• dahart 7y ago
  It’s still not clear what you’re talking about exactly, will you clarify? Perhaps some concrete examples of the safety and simplicity gains you’re referring to? Are you saying, and arguing with your team, that individuals should always branch and merge, even when they want to check in single commits, or small numbers of commits? I don’t consider what happens before push to be “history” at all. Do you? I do consider what happens after push to be history, and for pushed commits, I agree, people should not rebase them. Branching was designed for the isolation and safety of multi-person teams working on features that take non-trivial amounts of time. Arguing over what individuals should do when not working in teams in a branch is possibly a bit of bike-shedding. I don’t know if that’s what we’re doing here, but on the other hand there are some clues: rebasing is something people do to their own private branch before push, but not normally to other people’s commits after they’ve pushed. I do think it’s noisy and unnecessary to have two commits for every single-commit change in master. A lot of teams specifically disallow that practice and require direct checkins to master for single commit changes, just to prevent the noise. If you’re advocating never using rebase, and never rewriting your own history before you push, then I think that is a dogmatic approach that misunderstands the goals and tools in git and fundamentally mistakes git’s philosophy. If you’re saying that people are rebasing your changes after you pushed them, then I agree with you completely. I’m not calling anyone wrong. But this isn’t a disagreement over which way has cognitive load. You asked what was wrong with noisy history, and I answered. Your example of having to learn rerere only applies to the team lead, the person doing the merges, and it only comes up once in a while. Not everyone needs to learn rerere, and nobody needs to use it all the time. My example, noisy history, applies to everyone on the team at all times. On my teams, I prefer that people learn git well, and keep their histories clean.
  • derriz 7y ago
    Bit late to reply but regarding the advantages of not allowing rebase operations in a distributed system: if you can only change the version tree by adding nodes to leaves and by adding attributes to nodes (e.g. for merge arrows, tags, etc.), then combining distributed changed versions of a version tree is relatively trivial and users need never fear pushing and pulling. Or more formally, there is a partial order on version trees (inclusion) and if all changes to version tree are monotonic with respect to this partial order, then it will always be possible to combine distributed versions without conflict. An analogy might be that I prefer storing raw facts in databases, where practical and performing aggregations/filtering/etc. as queries during retrieval rather than storing filtered and aggregated data. Typical rebase operations like squashing commits or removing merge history destroy information. Rather than decide up front what information is interesting, why not keep it and provide better tooling for filtering and aggregating commit information? And what I'm suggesting here isn't radical - other VCSs offer branching and merging without requiring operations similar to rebase. Git itself supports such a workflow and many tutorials introduce git with a simple workflow that does not involve rebasing. I've used such systems in the past and because they had decent version browsing tooling, there was very little "noisy history" overhead. If you wanted a linear view of a branch like "master", you could view the history that way; if you wanted to drill into the branches, sub-branches and merges involved in a particular "master" version, you could do that also.
    • dahart 7y ago
      So yes, you are talking about individual branching & merging in order to commit a single change. And you are talking about never using the rebase command. Why? What are the tangible benefits to never using rebase on your own private commits? You didn’t give me any concrete examples. This seems exceedingly academic and it also seems like you’re either not understanding normal git workflow, or are trying to work in an ad for Pijul or something? If you use git like I’ve proposed - which is how most people actually use it - by calling commits “history” only after they’ve been shared with someone else, e.g. pushed, then you get all the same guarantees that you are proposing, and the workflow is one of adding only leaves. Rebase is something you usually do locally before adding nodes to the shared tree, and really has no bearing on published history, nor does it affect published history or change the order or monotonicity of shared events, because you never rebase already published commits. It is not only possible to use rebase in a non-destructive way, it is the most common workflow, and you’re arguing against that part in favor of something that offers zero advantages. It’s not possible to never have a merge conflict. It is possible to do better than git, but if two people change the same file in the same location, you have a problem, no matter how many monotonic partial orderings you have. > other VCSs offer branching and merging without requiring operations similar to rebase Git does not require rebase for branching and merging, and you already know this because you’re advocating single commits in master from individuals get branched and then merged instead of rebased locally. Lots of tutorials don’t mention rebase because it’s irrelevant in the context, and because rebase isn’t required. Be specific: what systems exactly are you talking about using in the past that had no rebasing and better tooling? There’s no discussion here without concrete examples.