5 ms·

I've never understood why people think omitting a historical event keeps their "history clean".

by Touche 11y ago

jasonlotito 11y ago
If you don't understand, then clearly you should investigate why as you cannot form an opinion on something you don't understand.
- Touche 11y ago
  I have investigated, why are you assuming I have not?
  - jasonlotito 11y ago
    Clearly not enough, because you don't understand. You literally said that. How can you pass a judgement on something you don't understand?
    - Touche 11y ago
      Who said I'm passing judgment? I a lot of people prefer that workflow so I'm guessing there is some merit. I just don't understand it (I've never gotten an explanation that satisfies me).
      - jasonlotito 11y ago
        You do, in your own comments. You pass judgement. Take for example this: > The whole "prettiness" thing seems like a bit of a fetishism more than about productivity. When you say: > I've never gotten an explanation that satisfies me You have gotten explanations, you just pass judgement on those explanations and assume they are based on a fetish. You effectively wave your hands and dismiss them. So, you are passing judgement based on your own admitted ignorance. And you go out of your way to hinder any investigation you claim to perform. Whatever. You suffer for your self-inflicted and self-admitted ignorance.
masklinn 11y ago
Because I've yet to find a git graphlog tool which made viewing pretty nonlinear git history (as precise a historical record as they are) anything but a pain in the ass, some of them barely even manage to display a dozen concurrent "branches". This is combined with most of the "historical record" really being worthless garbage: does it matter that you had to implement 12 fixups at various points and rewrite the whole feature thrice after requirements changed? Probably not. Does it need to be enshrined in the project's commit history? Absolutely not.
- camwest 11y ago
  Check out http://gitup.co http://gitup.co
- Touche 11y ago
  > Because I've yet to find a git graphlog tool which made viewing pretty nonlinear git history (as precise a historical record as they are) anything but a pain in the ass, some of them barely even manage to display a dozen concurrent "branches". I'm not following this at all... what is it you need from this tool and why? > Does it matter that you had to implement 12 fixups at various points and rewrite the whole feature thrice after requirements changed? Probably not. Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made. And having many small commits rather than 1 massive one makes it much easier to revert bad commits.
  - HolyHaddock 11y ago
    > Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made. This is interesting - even places I've worked that have cared about commit messages have been pretty happy with the entirely content-free "Fixes from code review." Do you summarise code review discussions in the commit messages?
    - Touche 11y ago
      Yes, I do, I try to treat each commit like something that can be read in isolation. But nevertheless, the merge commit will have (if using GitHub) a reference to the pull request where you can see the discussion, which is valuable imo.

I've never understood why people think omitting a historical event keeps their "history clean".

by Touche 11y ago

I've never understood why people think omitting a historical event keeps their "history clean".

If you don't understand, then clearly you should investigate why as you cannot form an opinion on something you don't understand.

Touche 11y ago
I have investigated, why are you assuming I have not?
- jasonlotito 11y ago
  Clearly not enough, because you don't understand. You literally said that. How can you pass a judgement on something you don't understand?
  - Touche 11y ago
    Who said I'm passing judgment? I a lot of people prefer that workflow so I'm guessing there is some merit. I just don't understand it (I've never gotten an explanation that satisfies me).
    - jasonlotito 11y ago
      You do, in your own comments. You pass judgement. Take for example this: > The whole "prettiness" thing seems like a bit of a fetishism more than about productivity. When you say: > I've never gotten an explanation that satisfies me You have gotten explanations, you just pass judgement on those explanations and assume they are based on a fetish. You effectively wave your hands and dismiss them. So, you are passing judgement based on your own admitted ignorance. And you go out of your way to hinder any investigation you claim to perform. Whatever. You suffer for your self-inflicted and self-admitted ignorance.

masklinn 11y ago

Because I've yet to find a git graphlog tool which made viewing pretty nonlinear git history (as precise a historical record as they are) anything but a pain in the ass, some of them barely even manage to display a dozen concurrent "branches". This is combined with most of the "historical record" really being worthless garbage: does it matter that you had to implement 12 fixups at various points and rewrite the whole feature thrice after requirements changed? Probably not. Does it need to be enshrined in the project's commit history? Absolutely not.

camwest 11y ago
Check out http://gitup.co http://gitup.co
Touche 11y ago
> Because I've yet to find a git graphlog tool which made viewing pretty nonlinear git history (as precise a historical record as they are) anything but a pain in the ass, some of them barely even manage to display a dozen concurrent "branches". I'm not following this at all... what is it you need from this tool and why? > Does it matter that you had to implement 12 fixups at various points and rewrite the whole feature thrice after requirements changed? Probably not. Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made. And having many small commits rather than 1 massive one makes it much easier to revert bad commits.
- HolyHaddock 11y ago
  > Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made. This is interesting - even places I've worked that have cared about commit messages have been pretty happy with the entirely content-free "Fixes from code review." Do you summarise code review discussions in the commit messages?
  - Touche 11y ago
    Yes, I do, I try to treat each commit like something that can be read in isolation. But nevertheless, the merge commit will have (if using GitHub) a reference to the pull request where you can see the discussion, which is valuable imo.