[chriswarbo]

One important reason is to avoid wasting time on gilding lilies.

Another reason is that the git information (e.g. from git blame) tells us when the code was written and in what order, rather than some post-hoc rearrangement.

For example, we might notice that code X is doing some tricky work which elsewhere is done by a helper function Y. We look at the git info and see that X was added after Y, so we try to figure out what special edge-cases X is trying to deal with that Y wasn't suitable for. Little do we realise that X was actually written before Y existed, but the commits got rearranged.

That kind of archeology is difficult to predict in advance (mostly because, if we realised all of the issues with our code beforehand, we'd fix them immediately!).

Future devs are just as capable at traversing repos and collapsing diffs as you or I, so there's no need to lie to them. In fact, they might have access to much smarter tools and IDEs than we do.

[shados]

Personally, I only care about when the code hit master. Because that's when it could potentially have broken shit for everyone.

That I committed it locally is pretty irrelevant: I could just as well NOT have committed it, made a backup of the files on the side, copied them back in...from the perspective of the rest of my team, my local history is an implementation detail.

If the only thing I do is manipulate my local history, then open a PR and merge, master's history will actually show something much closer to the truth: That on X date I added something to master.

That I spent 6 weeks and 300 commits locally to do it (kids, don't do this at home!), literally doesn't matter to anyone.

[TurningCanadian]

> Personally, I only care about when the code hit master.

So just look for the merge commit on the master branch that brought it in.

By having 300 separate commits (which you were doing anyway) it helps us know what your thought process was on the day that a given line changed. Maybe you were refactoring function X to do Y. If you don't mention that you were accounting for changes happening in someone else's branch, then we know we have to look closer at that code. Without the individual commit, all we know is that giant-project-x was accomplished with this commit, and the change to that line may or may not have the necessary update.

[sofal]

By having a history of every single key you typed to create this comment, it would help me know what your thought process was when you typed it up. Maybe you got pissed off and wrote a swear word or two and then backspaced. Maybe you worded something awkwardly and then refactored your sentence. Without all of your keystroke history, all we know is that a comment was made by you, and your opinion may or may not have taken into account certain arguments made by others in the same thread around the time that the comment was published.

[xorcist]

> it helps us know what your thought process was on the day that a given line changed

This is not something someone who actually spends his days reading code would say.

Code is hard to read as it is. Presenting it in well packages, readable commits is the very least one can do.

[Dylan16807]

>Future devs are just as capable at traversing repos and collapsing diffs as you or I, so there's no need to lie to them.

The ability of devs to collapse a bunch of commits into a useful summary is near zero right now. You can only achieve it by rewriting history. Unless you think that feature is going to be commonplace very very soon, there is a compelling reason to lie.

[chriswarbo]

> The ability of devs to collapse a bunch of commits into a useful summary is near zero right now

You can get quite far with 'git diff START END'. Something more task-specific can probably be done with Emacs, Magit, Ediff mode, bash, elisp, etc.

Even if you think collapsing commits by rewriting history is useful for making summaries, etc. what makes you think you can produce a more useful summary right now than that future dev can, considering the fact that you don't know what they might want?

The nice thing about git is that anyone can make a new branch from any point in the repo's history, merge, cherry pick, rebase, etc. to their heart's content, then garbage collect it once they've learned what they needed.

[Dylan16807]

What makes me think I can write better code than the thousand people downloading my repo later? I don't, but somebody should do the summarizing, and it might as well be me.

Smashing the diffs together gets you the least useful parts of a purposeful squash commit.

[chriswarbo]

> somebody should do the summarizing, and it might as well be me.

Should they? See my earlier point about gilding lilies and YAGNI ;)

Of course, there are always exceptions! The most obvious ones are processes which work per-commit, e.g. bisecting, conflict resolution, per-commit code review, etc. where having a bunch of interleaved "stories" can be tedious.

[eridius]

The order in which code was written is pretty meaningless. What matters is how the function of the code changed over time. If I run `git blame` I should not be presented with a whole series of "fixed typo", "changed whitespace", etc commits. That makes it really hard to work with. When I use `git blame` I want to be presented with the commit that actually made a meaningful change to the code.

[nzp]

That code X should be clearly commented to explain the state you describe. That's the proper, most ergonomic, solution to the problem. Sure, it might not be documented and archaeology might be needed, but it shouldn't be considered as an excuse to not write comments and/or documentation.

[chriswarbo]

I agree that if X avoids Y for some subtle edge-case or whatever, then there should be a comment explaining why.

However, in my example X is written first, but just so happens to have become redundant once Y gets written. We've just spotted this redundancy, and it's up to us to figure out whether X should be refactored to use Y or not.

If we look at an unaltered history, we would see that X was written first, so we can hypothesise that it's just a special case of Y which can be refactored away.

If we look at an altered history, the commits containing X may have been squashed/rebased/etc. into a coherent "story", which just-so-happens to appear on top of the story containing Y.

If there were a comment telling us that X was added due to some edge-case, etc. that makes Y unsuitable, we could leave it alone and get on with something else. Yet in this situation there is no such comment, but that doesn't imply that it's not there to handle some subtle edge-case; we'd need to do more investigation to convince ourselves that it is indeed redundant before we could refactor it in confidence, to counteract the contrary evidence which git is telling us.