3 ms·

> The nice thing about git is that your commits can be garbage. That's a dangerous practice. When you first commit the changes, you have all the necessary con

> The nice thing about git is that your commits can be garbage. That's a dangerous practice. When you first commit the changes, you have all the necessary context, and hopefully flow hasn't been interrupted. If you rebase hours, days, maybe weeks later, then that context is completely lost---it's just like trying to get back into a project that amount of time later. The reason the detail you'd put into your commits is so useful is because you have a perspective that others won't; if you return to it later, you'll be reading the diff and suffering just like others, albeit with a bit more knowledge.

developer2 10y ago
I could have been more specific about the scenario I was referring to. Many people commit to git very frequently in such a way that their local git history is more like an IDE's undo log. You can commit 10+ times in the span of an hour, using the log as nothing more than a savepoint system. This is really common from people who for some unfathomable reason perform a commit before testing, which results in a lot of those one-liner commits that really do not deserve their own commit (this specific task can be done via amend, but you don't see it from most devs). Git commits are so fantastically cheap, and especially easy if it's a one second task via keyboard shortcut in your IDE rather than terminal commands. You wind up with a lot of commits throughout the day all related to accomplishing a simple task, and then rebase them down into a smaller number of meaningful chunks of work. I agree that this should not be the workflow for larger units of work. If you're working on a week-long task, you would use this flow to refactor each day's 50 commits down to what you would have normally committed (maybe 1-5 commits for the day). This allows your feature branch's log to contain meaningful information. At the end of the week, when your feature branch is complete, you then have the additional choice as to whether the branch's already-more-compact history is meaningful; if not, you can further squash the merge commit. tldr: >> When you first commit the changes, you have all the necessary context Rebasing your local changes before sharing is for the case where you're spamming loads of meaningless commits that don't have - or deserve - their own context.
- mikegerwitz 10y ago
  I see; this is a very different workflow than I am describing (or am used to). While I understand it's useful as a snapshot, that's not a useful use of history in Git. In fact, it's quite useless, and I'd agree that those commits should not remain, and should be replaced with something useful. But since context has been lost, that "useful" commit might just be a single, squashed one; I've observed this situation at work from others. So, this is a situation where those users are digging their own hole.

developer2 10y ago

I could have been more specific about the scenario I was referring to. Many people commit to git very frequently in such a way that their local git history is more like an IDE's undo log. You can commit 10+ times in the span of an hour, using the log as nothing more than a savepoint system. This is really common from people who for some unfathomable reason perform a commit before testing, which results in a lot of those one-liner commits that really do not deserve their own commit (this specific task can be done via amend, but you don't see it from most devs). Git commits are so fantastically cheap, and especially easy if it's a one second task via keyboard shortcut in your IDE rather than terminal commands. You wind up with a lot of commits throughout the day all related to accomplishing a simple task, and then rebase them down into a smaller number of meaningful chunks of work. I agree that this should not be the workflow for larger units of work. If you're working on a week-long task, you would use this flow to refactor each day's 50 commits down to what you would have normally committed (maybe 1-5 commits for the day). This allows your feature branch's log to contain meaningful information. At the end of the week, when your feature branch is complete, you then have the additional choice as to whether the branch's already-more-compact history is meaningful; if not, you can further squash the merge commit. tldr: >> When you first commit the changes, you have all the necessary context Rebasing your local changes before sharing is for the case where you're spamming loads of meaningless commits that don't have - or deserve - their own context.

mikegerwitz 10y ago
I see; this is a very different workflow than I am describing (or am used to). While I understand it's useful as a snapshot, that's not a useful use of history in Git. In fact, it's quite useless, and I'd agree that those commits should not remain, and should be replaced with something useful. But since context has been lost, that "useful" commit might just be a single, squashed one; I've observed this situation at work from others. So, this is a situation where those users are digging their own hole.