3 ms·

I can only sit in amazement as I read this thread, watching seemingly smart people advocating throwing away history for the sake of tidiness. It's maddening. T

I can only sit in amazement as I read this thread, watching seemingly smart people advocating throwing away history for the sake of tidiness. It's maddening. Those are four commits. That's what happened. It does not matter that it's untidy. It's your history. Just leave it. It will save you a lot of work some day when you need to find the error you introduced when you accidentally removed one too many lines on that "remove debug logging" commit.

saagarjha 6y ago
There’s “throwing away history” and then there is just clutter. If you added a feature and then ten commits to fix typos on top of it, just squash it into the original one and pretend like it was right all along. It keeps the repository sane and not full of “typo fix” commits, and, like, I don’t really mind looking for a change in a diff that is 20 lines instead of a dozen that are one.
kordlessagain 6y ago
> It will save you a lot of work some day I already spend a fair amount of time on other people's problems and they aren't doing much to save me, so what is the point of being obsessive with my own problems such that I may avoid spending a little bit of time on them later?
Vinnl 6y ago
It's not my history. My history includes every time I hit Ctrl+Z without doing a commit in between. But you wouldn't commit every keystroke, because it's not informative. It doesn't tell you anything about why you did something. We're not advocating throwing away history specifically, we're advocating writing helpful history, leaving helpful traces.
room500 6y ago
> It does not matter that it's untidy. It's your history. That is only true if you are working in a personal git repo If you are committing against a repo with many others though, having a tidy git history is important. If I discover a bug and bisect to the "remove debug logging" commit, it is hard to revert that - or to even understand what it means. I then have to go in and try to determine which feature that debug logging is for and how many commits I need to revert to get back to a sane place. My general rule of thumb is that I squash commits (when merging to a public repo) if the commit doesn't warrant time into creating a proper commit message (explaining what I am fixing, why, etc). I have no problem creating a set of 10 commits to merge in one feature, but each commit needs to be individually reviewable and understandable.
yxhuvud 6y ago
Here is the thing: With git, the history looks the way I want it to look like. It is not a list of how I worked and in what sequence. Unless I want it to. I generally don't and instead prefer the history to be comprehensible by someone looking for how features are put together and interact and changed over time. THAT, saves time when I need to look at it again.
renewiltord 6y ago
I have done one or the other. My personal experience is that intermediate commits provide low value. YMMV but I now know what works for me. I definitely leave in commit A and a revert of commit A if I think it'll be useful. The way I see it is I'm leaving breadcrumbs for myself for later. It's obvious that a sequence of keystrokes is useless (and most IDEs will undo a large number at once - correct behaviour) and that no history is useless so you have to find the thing that works for yourself or your team wherever.
nemetroid 6y ago
> Just leave it. It will save you a lot of work some day when you need to find the error you introduced when you accidentally removed one too many lines on that "remove debug logging" commit. I understood the parent as "remove debug logging" removing what was introduced by the previous two commits. In this case, squashing the commits will actually make the issue _much_ more obvious, since the accidentally removed line now stands out by itself without the clutter of the back-and-forth changes.

saagarjha 6y ago

There’s “throwing away history” and then there is just clutter. If you added a feature and then ten commits to fix typos on top of it, just squash it into the original one and pretend like it was right all along. It keeps the repository sane and not full of “typo fix” commits, and, like, I don’t really mind looking for a change in a diff that is 20 lines instead of a dozen that are one.

kordlessagain 6y ago

> It will save you a lot of work some day I already spend a fair amount of time on other people's problems and they aren't doing much to save me, so what is the point of being obsessive with my own problems such that I may avoid spending a little bit of time on them later?

Vinnl 6y ago

It's not my history. My history includes every time I hit Ctrl+Z without doing a commit in between. But you wouldn't commit every keystroke, because it's not informative. It doesn't tell you anything about why you did something. We're not advocating throwing away history specifically, we're advocating writing helpful history, leaving helpful traces.

room500 6y ago

> It does not matter that it's untidy. It's your history. That is only true if you are working in a personal git repo If you are committing against a repo with many others though, having a tidy git history is important. If I discover a bug and bisect to the "remove debug logging" commit, it is hard to revert that - or to even understand what it means. I then have to go in and try to determine which feature that debug logging is for and how many commits I need to revert to get back to a sane place. My general rule of thumb is that I squash commits (when merging to a public repo) if the commit doesn't warrant time into creating a proper commit message (explaining what I am fixing, why, etc). I have no problem creating a set of 10 commits to merge in one feature, but each commit needs to be individually reviewable and understandable.

yxhuvud 6y ago

Here is the thing: With git, the history looks the way I want it to look like. It is not a list of how I worked and in what sequence. Unless I want it to. I generally don't and instead prefer the history to be comprehensible by someone looking for how features are put together and interact and changed over time. THAT, saves time when I need to look at it again.

renewiltord 6y ago

I have done one or the other. My personal experience is that intermediate commits provide low value. YMMV but I now know what works for me. I definitely leave in commit A and a revert of commit A if I think it'll be useful. The way I see it is I'm leaving breadcrumbs for myself for later. It's obvious that a sequence of keystrokes is useless (and most IDEs will undo a large number at once - correct behaviour) and that no history is useless so you have to find the thing that works for yourself or your team wherever.

nemetroid 6y ago

> Just leave it. It will save you a lot of work some day when you need to find the error you introduced when you accidentally removed one too many lines on that "remove debug logging" commit. I understood the parent as "remove debug logging" removing what was introduced by the previous two commits. In this case, squashing the commits will actually make the issue _much_ more obvious, since the accidentally removed line now stands out by itself without the clutter of the back-and-forth changes.