4 ms·

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 node

by 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.

by derriz 7y ago

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.