3 ms·

You can push your local work to a private remote branch. (By private, I don't mean that other people can't see it, I just mean some convention which means other

You can push your local work to a private remote branch. (By private, I don't mean that other people can't see it, I just mean some convention which means other developers will ignore it in normal circumstances.) If a person commits a lot, they can end with all kinds of little commits which are just fixing typos or syntax errors, exploring half-baked ideas, can't be bothered writing a commit message right now, etc. What's the point of keeping all that stuff long-term? Then, when it is ready to be reviewed, you rewrite that real history into something more logical - e.g. first commit creates an interface, second commit implements it, third makes other parts of the code call it, etc - and then submit that for review as a PR - that "fake" history is likely to be much more useful to others (and to one's own future self) than the real development history was

bluGill 3y ago
The reason you are asving this is because git is so aweful at managing many tiny commits. So you work around it by squashing. However this is a defect of your version control system. back when I used hg small commits were not a problem as the branch name remained after the merge and so mostly we were able to treat branch names as the squashed whiae still having acces to the typo commit if needed.
- skissane 3y ago
  > The reason you are asving this is because git is so aweful at managing many tiny commits. So you work around it by squashing. I don’t think the real issue is Git’s features. Even if Git had whatever additional features you wish it had, it still doesn’t change the fact that a history of typos and stupid mistakes isn’t very useful to anybody (especially in the long-run), and hence there is little or no value in preserving it; while a faked history which breaks the change down into logical steps does have some real long-term value, in terms of helping anyone who needs to review and understand the change in the future

bluGill 3y ago

The reason you are asving this is because git is so aweful at managing many tiny commits. So you work around it by squashing. However this is a defect of your version control system. back when I used hg small commits were not a problem as the branch name remained after the merge and so mostly we were able to treat branch names as the squashed whiae still having acces to the typo commit if needed.

skissane 3y ago
> The reason you are asving this is because git is so aweful at managing many tiny commits. So you work around it by squashing. I don’t think the real issue is Git’s features. Even if Git had whatever additional features you wish it had, it still doesn’t change the fact that a history of typos and stupid mistakes isn’t very useful to anybody (especially in the long-run), and hence there is little or no value in preserving it; while a faked history which breaks the change down into logical steps does have some real long-term value, in terms of helping anyone who needs to review and understand the change in the future