7 ms·

I personally almost never rebase and/or squash, since I think that the information that gets lost (like: when was it started, what were mistakes along the lines

I personally almost never rebase and/or squash, since I think that the information that gets lost (like: when was it started, what were mistakes along the lines) might be useful for future understanding of how the project work evolved over time, and what adjustments should/could be made to the development process. But I understand that a screen as shown in the article is not immensely usuful. But if it comes down on how to present git history information to users, maybe an additional aproach would be to come up with a better presentation layer (that, for example, could hide merge commits, "squashes" branches, etc.

splike 9y ago
I think there are two perfectly acceptable schools of thought. One says that the history should be preserved exactly, because its important we keep a record of exactly what happened. The second says that its ok to rewrite history a little if that makes it more understandable. I think you would put yourself in the first, and that's ok. I would put myself in the second because at the end of the day I value understanding over precision in git histories. I'm of the opinion that one cares about the commit I made to correct a missing semicolon.
- hdhzy 9y ago
  The usual rule of thumb is not to modify (e.g rebase) published commits. So it's perfectly fine to adjust local commits before they go into centralized repo - from the point of view of an external observer the history is never destructively modified. This rule can be extended to topic branches or user owned branches with the caveat that others should not base their work upon the topic branch. Also remember git push --force-with-lease!
  - james-skemp 9y ago
    And `git commit --amend` I missed a semi-colon or a file? I probably noticed right after I made the commit (and before I pushed it to the remote branch).
- maxxxxx 9y ago
  I am in the first because I don't think you should change history. But I think there is a need for tools that can show history like it would look after rebasing and squashing.
- fulafel 9y ago
  Maybe we need another layer of abstraction, maybe recorded as merge commits, that would present the summarized history.
UK-AL 9y ago
The thing is I commit very frequently, and a lot of the commits don't really make much sense by themselves. Often with stuff that's just plain wrong or confusing inbetween.
- test1235 9y ago
  e.g. remove console.log what do you need that in the git history for?
  - epmatsw 9y ago
    “Fix lint” is my favorite one.
    - AstralStorm 9y ago
      My unfavorite is WIP and "update submodule(s)". In fact I contemplated making a git hook to reject such drivel on merge.
jeff_vader 9y ago
Say we work together. Why would you want to see my 5 solutions to a problem in `master`, of which 4 actually never really ran in production? I do commit often, things that I try and later throw away are in the history. Once rebased and squashed, only final solution is in `master` history.
- branja 9y ago
  This is much easier when I actually need to trawl through history to find things.
- chii 9y ago
  > 4 actually never really ran in production? but the history showed that it was tried (and perhaps the commit message can have a short note on why it wasn't selected). without the git history, you'd have to rely on human memory to know this. Or a separately maintained documentation (which, lets face it, is never going to get updated).
  - Tade0 9y ago
    Or store it in another branch - that's the approach we had been using in one company I worked at.
    - radiospiel 9y ago
      Ah, yes, this was implied :) only working code (as checked via CI) is allowed to show up in master and other long living branches.
0xcoffee 9y ago
I wish there was some happy medium, like that I can merge a branch and it gets squashed into a single commit, but then if needed I can 'expand' that commit to see its contents, even after the other branch is deleted.
- falsedan 9y ago
  That’s a rebased branch. You can see just the changed introduced by a branch: MERGE_COMMIT=$(git rev-parse :/“Merge .*$branchname”) git diff $MERGE_COMMIT^1..$MERGE_COMMIT^2 It never occurred to me that people prefer to squash so they can avoid the crummy UI of git diff
lomnakkus 9y ago
I really don't need to see all your false starts at a solution to the problem. I don't mean that in a patronizing way, it's just that it is truly irrelevant when I'm digging through commit history. Question: Do you have a problem with rebase-before-push? Regardless, there's a happy medium here: Just commit whenever you feel like it, then rebase, squash or whatever just before you're reasonably(!) confident in your approach... and push. Obviously you don't want to force-push, so at the point that you're "reasonably confident" you're committed. If you need to retrace your steps, you just do that through normal "git revert" or whatever. The point of the above being: This way of working preserves the useful parts of history and you still avoid the absurd noise of seeing everybody's "I changed a thing" commits and non-compiling-commits as well.

splike 9y ago

I think there are two perfectly acceptable schools of thought. One says that the history should be preserved exactly, because its important we keep a record of exactly what happened. The second says that its ok to rewrite history a little if that makes it more understandable. I think you would put yourself in the first, and that's ok. I would put myself in the second because at the end of the day I value understanding over precision in git histories. I'm of the opinion that one cares about the commit I made to correct a missing semicolon.

hdhzy 9y ago
The usual rule of thumb is not to modify (e.g rebase) published commits. So it's perfectly fine to adjust local commits before they go into centralized repo - from the point of view of an external observer the history is never destructively modified. This rule can be extended to topic branches or user owned branches with the caveat that others should not base their work upon the topic branch. Also remember git push --force-with-lease!
- james-skemp 9y ago
  And `git commit --amend` I missed a semi-colon or a file? I probably noticed right after I made the commit (and before I pushed it to the remote branch).
maxxxxx 9y ago
I am in the first because I don't think you should change history. But I think there is a need for tools that can show history like it would look after rebasing and squashing.
fulafel 9y ago
Maybe we need another layer of abstraction, maybe recorded as merge commits, that would present the summarized history.

UK-AL 9y ago

The thing is I commit very frequently, and a lot of the commits don't really make much sense by themselves. Often with stuff that's just plain wrong or confusing inbetween.

test1235 9y ago
e.g. remove console.log what do you need that in the git history for?
- epmatsw 9y ago
  “Fix lint” is my favorite one.
  - AstralStorm 9y ago
    My unfavorite is WIP and "update submodule(s)". In fact I contemplated making a git hook to reject such drivel on merge.

jeff_vader 9y ago

Say we work together. Why would you want to see my 5 solutions to a problem in `master`, of which 4 actually never really ran in production? I do commit often, things that I try and later throw away are in the history. Once rebased and squashed, only final solution is in `master` history.

branja 9y ago
This is much easier when I actually need to trawl through history to find things.
chii 9y ago
> 4 actually never really ran in production? but the history showed that it was tried (and perhaps the commit message can have a short note on why it wasn't selected). without the git history, you'd have to rely on human memory to know this. Or a separately maintained documentation (which, lets face it, is never going to get updated).
- Tade0 9y ago
  Or store it in another branch - that's the approach we had been using in one company I worked at.
  - radiospiel 9y ago
    Ah, yes, this was implied :) only working code (as checked via CI) is allowed to show up in master and other long living branches.

0xcoffee 9y ago

I wish there was some happy medium, like that I can merge a branch and it gets squashed into a single commit, but then if needed I can 'expand' that commit to see its contents, even after the other branch is deleted.

falsedan 9y ago
That’s a rebased branch. You can see just the changed introduced by a branch: MERGE_COMMIT=$(git rev-parse :/“Merge .*$branchname”) git diff $MERGE_COMMIT^1..$MERGE_COMMIT^2 It never occurred to me that people prefer to squash so they can avoid the crummy UI of git diff

lomnakkus 9y ago

I really don't need to see all your false starts at a solution to the problem. I don't mean that in a patronizing way, it's just that it is truly irrelevant when I'm digging through commit history. Question: Do you have a problem with rebase-before-push? Regardless, there's a happy medium here: Just commit whenever you feel like it, then rebase, squash or whatever just before you're reasonably(!) confident in your approach... and push. Obviously you don't want to force-push, so at the point that you're "reasonably confident" you're committed. If you need to retrace your steps, you just do that through normal "git revert" or whatever. The point of the above being: This way of working preserves the useful parts of history and you still avoid the absurd noise of seeing everybody's "I changed a thing" commits and non-compiling-commits as well.