In short: I'm in favor of squashing when done in a sensible and information-preserving way.
On 28-03-15 17:13, Arne Babenhauserheide wrote: > > I agree with Bombe that it’s not nice to lose the history, but with > git that’s the best we can do. It’s a limitation of the tool. > > […] > > ¹: The evolve extension of Mercurial has the concepts of hidden > changesets with rewrite-markers, so the history which is shown by > default is clean, but you can always inquire how it came into > being. This is an interesting observation. There appears to be a certain hierarchy to which history can be considered useful for a particular purpose. IMHO rewriting / losing history is only a bad thing if the history actually serves a purpose: this depends on who will be using the log in the future, and for what purpose. I really don't care about anyone's "Oops, fix XYZ" or "Also fix XYZ at ABC" commits (and nor should any other developer or reviewer) as long as the relevant code has not yet surfaced. Yes, this provides information as to how the code was originally created, but it serves no purpose in understanding, reviewing or maintaining the code. I consider this kind of commits *noise* if they end up in the master tree (or in the initial commit set of a pull request), though they may be useful in my own branch during development (e.g. I can revert more granularly, read my work log, etc.). (FYI: I consider myself a noisy committer, too.) A pull request may require such commits to be added to the publicly known code, at that point they do add information — up to the point where the pull request is merged, from then on they no longer serve a purpose. One use case I have in mind that illustrates the above is finding the *intended purpose* of a single piece of code, e.g. through `git blame': having to browse through a list of fixup-type commits doesn't help and can easily be avoided by sensible squashing. I usually don't care if that line was *changed* (before merge, that is!) to fix something, I just want to know why that line is there at all. In the same way, commits in the initial commit set of a pull request (and their messages) may be useful during the review process to get a better understanding of the code. If this is indeed the case, it is likely that this information will also be relevant to future readers of the code, and squashing should be done sparingly. Squashing entire pull requests into single commits just for the sake of reducing history verbosity does not make sense — only view merge commits if you're simply bothered by the verbosity. However, squashing and/or reordering a whole lot of (fixup) commits into one or more semantically correct commits allows the author to re-describe his development process in a way that actually conveys the information he intends to convey. This is particularly useful for fixups after discussion on a pull request: those in particular can easily break the clarity of the commit log (after merge), although they do add information during the review process. That said, only merge candidate branches should ever be squashed, obviously before merging, and preferably to yet another branch. Comparing both branches for equality is trivial, hence existing review work is not invalidated. So IMHO no, squashing (or history rewriting) is not evil, but it depends on where, when and how it is applied whether it is good. Developing, understanding, reviewing and maintaining the code all call for other commit granularities — squash accoringly. -- Bert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
