3 ms·

I must respectfully disagree. In this universe, nothing is linear in terms of how we perceive events and their simultaneity. If we consider a commit is an event

I must respectfully disagree. In this universe, nothing is linear in terms of how we perceive events and their simultaneity. If we consider a commit is an event, then who can say one commit comes before another? As in relativity, if both developers are working independently then they each of their own frame of reference. In effect, a merge commit reconciles those different frames of reference in its own discrete and well-documented entity. You could think of it as the equivalent of a Lorentz transformation. I understand the analogy is quite stretched here, but I still find it useful. It follows then that if a merge commit is a genuine reconciliation, then a rebase is the act of one party rewriting their own memory in order to hide from themselves the fact that they were working in isolation and later had to agree on the actual outcome of events. Thus, in effect, rebasing ones code is no different than suffering from a self-inflicted delusion. That is, a delusion that we are all working in one shared directory or, to a lesser extent, that there is one source of truth as in SVN or other centralised systems. This is, in fact, quite a sad thing our community. Many a developer -- while they may be using git -- are not truly using git in the way it was intended. They have limited themselves to their old ways of thinking and acting and, in the pursuit of what they have been taught is "the ideal", they have hidden from themselves the possibilities, efficiencies and understanding that might be discovered by the move into a world which can capture the fact that not everyone works in a single shared directory with immediate knowledge of each other's work. We have to learn to embrace the oddity of a non-linear history because, while we might not like it, it represents what really happens when we write code. The better our tools help us model reality the better answers we can produce for ourselves now and in the future. Six months from now when we say, "How the hell did this ever work?" or "What the fuck was I thinking when I wrote that?", we'll want answers. If we choose rebase, corrupt our own memories and burn the reflogs we'll never know.

Pyxl101 11y ago
This is a poor and incorrect analogy for rebase. Someone using rebase is conducting the reconciliation and then rewriting their commit to account for it, while simplifying the commit history and hiding it. When a commit lands in master, it doesn't matter to anyone else how it was developed. Those events are almost outside the "light cone". Those who rebase a commit onto the upstream branch recognize that the little details of how it was made have no relevance to others and thus do not belong in shared history. People often speak about preserving history while missing the point that source history is most meaningfully logical, not physical. Imagine an editor that made a new commit for every key press. That would be a true recounting of history, and yet would be irrelevant. Most feature development can and should land as one commit; the details of how it was made are, like the key presses that composed it, minimally relevant to anyone but the author.
- justinjlynn 11y ago
  Fair assessment. Commits should represent logical groupings of modifications. This is always a trade off between the extremes of recording each change atomically and dropping one tarball release of all code to replace the last with no changelog. However, the purpose of having a history is to, in as much as possible, reconstruct the contents of the writers mind when evaluating their actions and the changes they have made. This is the heart of why we have revision control -- to allow us to manage this information and query it effectively. Since the purpose of a revision history is to enable historians to gather a complete picture of a feature's genesis so as to interpret the author's changes and mental states prompting those changes in their correct context all of recorded history should facilitate that purpose. If rebase workflows do indeed encourage big atomic commits which drop features into a repository as though they were commandments from a god then obviously they do not help historians understand the authorial intent that went into their creation. You yourself argue for just that as do, in my observations, most users of rebase oriented workflows. Additionally, the heart of rebase workflows themselves, namely retroactively changing the parent of a commit, misrepresents what the author knew at the time that code was written. This clearly misleads the historian and I find the workflow to be dishonest and unhelpful in preserving the very reason we use revision control and thus I judge it harmful. If one uses rebase (say, in interactive squash mode) to clean up and regroup commits into small logical chunks in order to facilitate the understanding of authorial intent then I don't have any issues with it at all. It's when it is used to misrepresent, overload and mislead the historian for the sake of a "good looking" git log that I find the usage of rebase distasteful. An author should never be so self-absorbed that they believe that no-one but themselves could possibly care how they did their work and arrived at the conclusion they did. Authors that abuse their tools really have no excuse and best remember that they themselves are also historians with respect to other people's code and, in time, their own.
- golergka 11y ago
  > When a commit lands in master, it doesn't matter to anyone else how it was developed. On the contrary — this is one of the most important pieces of information I hope to get from my VCS.

Pyxl101 11y ago

This is a poor and incorrect analogy for rebase. Someone using rebase is conducting the reconciliation and then rewriting their commit to account for it, while simplifying the commit history and hiding it. When a commit lands in master, it doesn't matter to anyone else how it was developed. Those events are almost outside the "light cone". Those who rebase a commit onto the upstream branch recognize that the little details of how it was made have no relevance to others and thus do not belong in shared history. People often speak about preserving history while missing the point that source history is most meaningfully logical, not physical. Imagine an editor that made a new commit for every key press. That would be a true recounting of history, and yet would be irrelevant. Most feature development can and should land as one commit; the details of how it was made are, like the key presses that composed it, minimally relevant to anyone but the author.

justinjlynn 11y ago
Fair assessment. Commits should represent logical groupings of modifications. This is always a trade off between the extremes of recording each change atomically and dropping one tarball release of all code to replace the last with no changelog. However, the purpose of having a history is to, in as much as possible, reconstruct the contents of the writers mind when evaluating their actions and the changes they have made. This is the heart of why we have revision control -- to allow us to manage this information and query it effectively. Since the purpose of a revision history is to enable historians to gather a complete picture of a feature's genesis so as to interpret the author's changes and mental states prompting those changes in their correct context all of recorded history should facilitate that purpose. If rebase workflows do indeed encourage big atomic commits which drop features into a repository as though they were commandments from a god then obviously they do not help historians understand the authorial intent that went into their creation. You yourself argue for just that as do, in my observations, most users of rebase oriented workflows. Additionally, the heart of rebase workflows themselves, namely retroactively changing the parent of a commit, misrepresents what the author knew at the time that code was written. This clearly misleads the historian and I find the workflow to be dishonest and unhelpful in preserving the very reason we use revision control and thus I judge it harmful. If one uses rebase (say, in interactive squash mode) to clean up and regroup commits into small logical chunks in order to facilitate the understanding of authorial intent then I don't have any issues with it at all. It's when it is used to misrepresent, overload and mislead the historian for the sake of a "good looking" git log that I find the usage of rebase distasteful. An author should never be so self-absorbed that they believe that no-one but themselves could possibly care how they did their work and arrived at the conclusion they did. Authors that abuse their tools really have no excuse and best remember that they themselves are also historians with respect to other people's code and, in time, their own.
golergka 11y ago
> When a commit lands in master, it doesn't matter to anyone else how it was developed. On the contrary — this is one of the most important pieces of information I hope to get from my VCS.