5 ms·

You wouldn't publish a first draft, but neither would you burn it once the final draft was off to the printer. Personally, I'd prefer it if "squashing" commits

You wouldn't publish a first draft, but neither would you burn it once the final draft was off to the printer. Personally, I'd prefer it if "squashing" commits was purely a UI thing; the underlying commits were all still there, but grouped together and displayed as a single big "virtual" commit. That way you could still drill down to the real history if you needed to.

gmfawcett 6y ago
The Fossil designer agrees with you: "So, another way of thinking about rebase is that it is a kind of merge that intentionally forgets some details in order to not overwhelm the weak history display mechanisms available in Git. Wouldn't it be better, less error-prone, and easier on users to enhance the history display mechanisms in Git so that rebasing for a clean, linear history became unnecessary?"
mikepurvis 6y ago
I'm not a user of it myself, but I believe this is the philosophy behind how Fossil approaches it: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
ulisesrmzroche 6y ago
The real history is useless. Especially if we have tests. In that case it doesn’t matter how often we make changes. I do think this is because I prefer to think of code as a black box. No one should need to figure out how my functions work. Someone should just need the name of the function, what inputs it receives, and what output does it return. If someone actually has to read my code, that’s a failure.
- gmfawcett 6y ago
  > If someone actually has to read my code, that’s a failure. I can't tell if you're being serious, or are a brilliant troll. :) Assuming you're serious, Hyrum's Law is one reason I might need to see your code (https://www.hyrumslaw.com/ https://www.hyrumslaw.com/). The signature of your function is not the whole signature, it's just a sketch of the high points.
  - deleted 6y ago
    [deleted]
  - ulisesrmzroche 6y ago
    You really should just need to read the code in case something goes wrong, but otherwise, no. You need to be more careful with your time.
chrisweekly 6y ago
Pull requests can serve the same purpose; messy feature branches and a clean main trunk.
- JonathonW 6y ago
  The only way you get that in Git is if you squash-and-rebase before merge, though. Which is fine if that's the process and end result that you want, but does (if you keep feature branches "messy") disconnect feature branches from their related merges into trunk from Git's point of view.
  - mikepurvis 6y ago
    Yeah, you're reliant on Github metadata to make those links for you; there's nothing natively in git itself doing it. It's also an all-or-nothing affair, where the whole PR becomes a single squashed commit. To get anything in between ("here's my single large PR which I've rebased into N incremental commits, but you can also dig in and see the work that actually led here"), you really do need first class support in the tool. I suppose the Github answer to all this would be "just make separate PRs", but going that way asks a lot more of the developer in terms of how polished those incremental states need to be.
xorcist 6y ago
Why would you want to see every typo that was corrected? Every little test that was changed erroneously and then backed out again? That may be an accurate representation of the order savepoints were made, but it's not an accurate representation of how the software evolved. It is noise that needs to be discarded if a reader would like to know what change was really made. It also makes if difficult or impossible to use tools like git bisect. Is the argument really that a more detailed history is always better? In the trivial case every keypress could be a savepoint, and every savepoint a commit. One does not always know in advance that a commit needs to be split in two. The only way to produce readable commits without rebasing them in that case is to work with local _backup files. A version control system does this much better.
- gmfawcett 6y ago
  In fairness, you're only seeing 5% of the typos. We caught the other 95% before committing. :) I love your question, "why not a commit per keypress?", because it raises an interesting follow-up: why not squash and rebase entire months or years of project work into single commits? If squashing is so useful, why do we only apply it at low-grain scales? Could we read and understand massive projects quickly and easily, if they only had a few commits to them? I'm sure that we don't experiment with larger-scale rebases because of the limitations in the technology -- we all know that we're not supposed to 'git rebase' in public, and why that is. But suppose those obstacles were lifted. Now that we can rebase and rewrite at any time scale, which scale(s) is the right one(s) to choose?
  - anaerobicover 6y ago
    > it raises an interesting follow-up: why not squash and rebase entire months or years of project work into single commits? That's effectively what happened before version control/before the small-scale rebases we enjoy now were possible. And the reason is that it's hugely valuable in certain circumstances to be able to see some granularity of the history. (Though clearly people disagree about what the grain size should be.) > Could we read and understand massive projects quickly and easily, if they only had a few commits to them? I don't think so. The current state is visible at the top of the git tree regardless. History comes in when you are trying to understand why the state is what it is. Usually this is for troubleshooting in my experience, but sometimes also when doing a refactor. Meaningful commit messages attached to meaningfully-clumped patches are, in my opinion, absolute gold in those cases.
BeetleB 6y ago
Mercurial does this with the Evolve extension. https://www.mercurial-scm.org/doc/evolution/user-guide.html#example-6-fold-multiple-changesets-together-into-one https://www.mercurial-scm.org/doc/evolution/user-guide.html#... It still has the individual commits, but the interface will make it appear as if it's just one commit.

gmfawcett 6y ago

The Fossil designer agrees with you: "So, another way of thinking about rebase is that it is a kind of merge that intentionally forgets some details in order to not overwhelm the weak history display mechanisms available in Git. Wouldn't it be better, less error-prone, and easier on users to enhance the history display mechanisms in Git so that rebasing for a clean, linear history became unnecessary?"

mikepurvis 6y ago

I'm not a user of it myself, but I believe this is the philosophy behind how Fossil approaches it: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

ulisesrmzroche 6y ago

The real history is useless. Especially if we have tests. In that case it doesn’t matter how often we make changes. I do think this is because I prefer to think of code as a black box. No one should need to figure out how my functions work. Someone should just need the name of the function, what inputs it receives, and what output does it return. If someone actually has to read my code, that’s a failure.

gmfawcett 6y ago
> If someone actually has to read my code, that’s a failure. I can't tell if you're being serious, or are a brilliant troll. :) Assuming you're serious, Hyrum's Law is one reason I might need to see your code (https://www.hyrumslaw.com/ https://www.hyrumslaw.com/). The signature of your function is not the whole signature, it's just a sketch of the high points.
- deleted 6y ago
  [deleted]
- ulisesrmzroche 6y ago
  You really should just need to read the code in case something goes wrong, but otherwise, no. You need to be more careful with your time.

chrisweekly 6y ago

Pull requests can serve the same purpose; messy feature branches and a clean main trunk.

JonathonW 6y ago
The only way you get that in Git is if you squash-and-rebase before merge, though. Which is fine if that's the process and end result that you want, but does (if you keep feature branches "messy") disconnect feature branches from their related merges into trunk from Git's point of view.
- mikepurvis 6y ago
  Yeah, you're reliant on Github metadata to make those links for you; there's nothing natively in git itself doing it. It's also an all-or-nothing affair, where the whole PR becomes a single squashed commit. To get anything in between ("here's my single large PR which I've rebased into N incremental commits, but you can also dig in and see the work that actually led here"), you really do need first class support in the tool. I suppose the Github answer to all this would be "just make separate PRs", but going that way asks a lot more of the developer in terms of how polished those incremental states need to be.

xorcist 6y ago

Why would you want to see every typo that was corrected? Every little test that was changed erroneously and then backed out again? That may be an accurate representation of the order savepoints were made, but it's not an accurate representation of how the software evolved. It is noise that needs to be discarded if a reader would like to know what change was really made. It also makes if difficult or impossible to use tools like git bisect. Is the argument really that a more detailed history is always better? In the trivial case every keypress could be a savepoint, and every savepoint a commit. One does not always know in advance that a commit needs to be split in two. The only way to produce readable commits without rebasing them in that case is to work with local _backup files. A version control system does this much better.

gmfawcett 6y ago
In fairness, you're only seeing 5% of the typos. We caught the other 95% before committing. :) I love your question, "why not a commit per keypress?", because it raises an interesting follow-up: why not squash and rebase entire months or years of project work into single commits? If squashing is so useful, why do we only apply it at low-grain scales? Could we read and understand massive projects quickly and easily, if they only had a few commits to them? I'm sure that we don't experiment with larger-scale rebases because of the limitations in the technology -- we all know that we're not supposed to 'git rebase' in public, and why that is. But suppose those obstacles were lifted. Now that we can rebase and rewrite at any time scale, which scale(s) is the right one(s) to choose?
- anaerobicover 6y ago
  > it raises an interesting follow-up: why not squash and rebase entire months or years of project work into single commits? That's effectively what happened before version control/before the small-scale rebases we enjoy now were possible. And the reason is that it's hugely valuable in certain circumstances to be able to see some granularity of the history. (Though clearly people disagree about what the grain size should be.) > Could we read and understand massive projects quickly and easily, if they only had a few commits to them? I don't think so. The current state is visible at the top of the git tree regardless. History comes in when you are trying to understand why the state is what it is. Usually this is for troubleshooting in my experience, but sometimes also when doing a refactor. Meaningful commit messages attached to meaningfully-clumped patches are, in my opinion, absolute gold in those cases.

BeetleB 6y ago

Mercurial does this with the Evolve extension. https://www.mercurial-scm.org/doc/evolution/user-guide.html#example-6-fold-multiple-changesets-together-into-one https://www.mercurial-scm.org/doc/evolution/user-guide.html#... It still has the individual commits, but the interface will make it appear as if it's just one commit.