13 ms·

I think that git is quite good, but I don't like the notion of 'squashing commits': when you squash commits you loose history! I would prefer to have a "fold/fo

by renox 9y ago

I think that git is quite good, but I don't like the notion of 'squashing commits': when you squash commits you loose history! I would prefer to have a "fold/folder" of commits which could be manipulated as 'one commit' but would instead be a set of commit and you could look inside the folder if you need the full history.

mjhoy 9y ago
> I would prefer to have a "fold/folder" of commits which could be manipulated as 'one commit' You can get this, more or less, with the combination of using `git rebase` and `git merge --no-ff`.
hota_mazi 9y ago
Like everything, "squashing commits" has good use cases and bad use cases. They have all been documented to death but just as a quick reminder: Bad: squashing commits that have been pushed. Very bad. Not just because it rewrites history but because it's going to cause headaches to other people. Good: squashing commits in your own local branch before pushing to origin. In my opinion, this is not just good, it's excellent. Nobody on my team needs to know how many micro commits or dead ends and backtracks I've gone through before I reached the current shape of the code I'm about to push. I love squashing in this situation so I can rearrange and make the commit more pretty before it becomes public. On top of that, I'd argue that this kind of commit squashing contributes to making better commit logs.
- Fice 9y ago
  In Fossil the good use case is supported by using private branches: when you merge a private branch into a public branch, only the merge commit is pushed, the private branch remains private.
rbehrends 9y ago
That's largely a UI issue. Look at Bazaar's hierarchical logs, for example [1]. I call it largely a UI issue because: 1. You can run `bzr log` on a git repository (with the bzr-git plugin). Hence it's a UI issue. 2. That operation still takes O(history size) time, because git repositories lack the necessary metadata to make the operation fast (hence: "largely" a UI issue). [1] https://bzrinit.com/05.html#hide https://bzrinit.com/05.html#hide

by renox 9y ago

mjhoy 9y ago

> I would prefer to have a "fold/folder" of commits which could be manipulated as 'one commit' You can get this, more or less, with the combination of using `git rebase` and `git merge --no-ff`.

hota_mazi 9y ago

Like everything, "squashing commits" has good use cases and bad use cases. They have all been documented to death but just as a quick reminder: Bad: squashing commits that have been pushed. Very bad. Not just because it rewrites history but because it's going to cause headaches to other people. Good: squashing commits in your own local branch before pushing to origin. In my opinion, this is not just good, it's excellent. Nobody on my team needs to know how many micro commits or dead ends and backtracks I've gone through before I reached the current shape of the code I'm about to push. I love squashing in this situation so I can rearrange and make the commit more pretty before it becomes public. On top of that, I'd argue that this kind of commit squashing contributes to making better commit logs.

Fice 9y ago
In Fossil the good use case is supported by using private branches: when you merge a private branch into a public branch, only the merge commit is pushed, the private branch remains private.

rbehrends 9y ago

That's largely a UI issue. Look at Bazaar's hierarchical logs, for example [1]. I call it largely a UI issue because: 1. You can run `bzr log` on a git repository (with the bzr-git plugin). Hence it's a UI issue. 2. That operation still takes O(history size) time, because git repositories lack the necessary metadata to make the operation fast (hence: "largely" a UI issue). [1] https://bzrinit.com/05.html#hide https://bzrinit.com/05.html#hide