3 ms·

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

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

by Pyxl101 11y ago

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.