5 ms·

It is valuable history: it is archaeological evidence of what has been attempted before.

seba_dos1 4y ago
It sure is valuable, which is why it's retained in your reflog. You don't have to push it out anywhere though (or at least not somewhere where it pretends to be part of the project).
- eurasiantiger 4y ago
  My reflog is not accessible to other contributors. I could keep a decision log, but that is double work.
  - seba_dos1 4y ago
    My reflog can sometimes be useful for myself, but I can't imagine anyone ever taking time to go through someone else's (either literal or in form of commits) messy reflog. If that's your argument, then no, it's not exactly what I'd call "valuable".
    - eurasiantiger 4y ago
      Reflog was your argument. Going through a reflog is much more noisy than going through commits, which is why I would prefer the commits.
      - seba_dos1 4y ago
        My argument was that the only cases where going through unfiltered chain of WIP commits is somewhat valuable are well served by browsing through your reflog. I don't see any value in peeking at other people's unfinished stuff (unless doing something like pair programming or teaching). Any decisions that are worth noting go into commit messages anyway. That "archaeological evidence" has, in general, no reason to leave the local machine at all.
gherkinnn 4y ago
- wip - wip - wip fix this - wip revert - wip almost done - wip ruehejhejdhdhd - wip tests I don’t see the value here.
- eurasiantiger 4y ago
  That is a strawman argument: you are pretending that bad commit messages are the result of retaining commit history.
  - masklinn 4y ago
    That is not a strawman argument, that is what routinely happens in development branches.
    - eurasiantiger 4y ago
      Maybe it does, but couldn’t the developer write more descriptively? The argument is a non sequitur too: It does not follow that a git merge strategy that keeps all commits is at fault for a culture of writing bad commit messages. Presenting that argument as a rationale for avoiding straight merges while preferring squashing and/or rewriting history is the strawman.
      - masklinn 4y ago
        > Maybe it does, but couldn’t the developer write more descriptively? Commonly while you're fixing things up there's nothing of worth to be descriptive about. "made test x pass" is a useful checkpoint during development, it's not a useful step to conserve forever. > The argument is a non sequitur too: It does not follow that a git merge strategy that keeps all commits is at fault for a culture of writing bad commit messages. I see your accusation of strawmanning was just projection. Thank you for the insight, have a nice day.
        eurasiantiger 4y ago
        ”Made test x pass” is still a bad commit message, as it says nothing about what changes were made to the codebase — which are always made when ”fixing things up”! I did not intend for my comment to be taken as an accusation, as that would imply intention on your part. I simply meant to point out the logical fallacy in statements I read online, i.e. ”because someone on the Internet was wrong”. Trying to gaslight me with personal accusations of psychological projection, however, is crossing a line. Do not do that to other people, it is violence. You do not know what I think or feel, only what I write.
the_gipsy 4y ago
It can also be a burden pushed away from the author to reviewers (or future contributors), hence why OSS repos usually require clean/squashed PRs.
- eurasiantiger 4y ago
  How is it a burden? Just diff the HEADs of the branches like GitHub does by default?
u801e 4y ago
> It is valuable history: it is archaeological evidence of what has been attempted before. Except that is not readily accessible. When looking at a particular section of code, you could either run git blame, or run git log and filter it to only list commits that updated that file. Either way, you're not going to easily be able to find what previous implementations were tried, or why they were not used compared to the current implementation. But if you make a clean commit with the working implementation and include an explanation of what other approaches were tried and why they weren't used, then someone could use git blame to get the information pretty easily.

It sure is valuable, which is why it's retained in your reflog. You don't have to push it out anywhere though (or at least not somewhere where it pretends to be part of the project).

eurasiantiger 4y ago
My reflog is not accessible to other contributors. I could keep a decision log, but that is double work.
- seba_dos1 4y ago
  My reflog can sometimes be useful for myself, but I can't imagine anyone ever taking time to go through someone else's (either literal or in form of commits) messy reflog. If that's your argument, then no, it's not exactly what I'd call "valuable".
  - eurasiantiger 4y ago
    Reflog was your argument. Going through a reflog is much more noisy than going through commits, which is why I would prefer the commits.
    - seba_dos1 4y ago
      My argument was that the only cases where going through unfiltered chain of WIP commits is somewhat valuable are well served by browsing through your reflog. I don't see any value in peeking at other people's unfinished stuff (unless doing something like pair programming or teaching). Any decisions that are worth noting go into commit messages anyway. That "archaeological evidence" has, in general, no reason to leave the local machine at all.

gherkinnn 4y ago

- wip - wip - wip fix this - wip revert - wip almost done - wip ruehejhejdhdhd - wip tests I don’t see the value here.

eurasiantiger 4y ago
That is a strawman argument: you are pretending that bad commit messages are the result of retaining commit history.
- masklinn 4y ago
  That is not a strawman argument, that is what routinely happens in development branches.
  - eurasiantiger 4y ago
    Maybe it does, but couldn’t the developer write more descriptively? The argument is a non sequitur too: It does not follow that a git merge strategy that keeps all commits is at fault for a culture of writing bad commit messages. Presenting that argument as a rationale for avoiding straight merges while preferring squashing and/or rewriting history is the strawman.
    - masklinn 4y ago
      > Maybe it does, but couldn’t the developer write more descriptively? Commonly while you're fixing things up there's nothing of worth to be descriptive about. "made test x pass" is a useful checkpoint during development, it's not a useful step to conserve forever. > The argument is a non sequitur too: It does not follow that a git merge strategy that keeps all commits is at fault for a culture of writing bad commit messages. I see your accusation of strawmanning was just projection. Thank you for the insight, have a nice day.
      - eurasiantiger 4y ago
        ”Made test x pass” is still a bad commit message, as it says nothing about what changes were made to the codebase — which are always made when ”fixing things up”! I did not intend for my comment to be taken as an accusation, as that would imply intention on your part. I simply meant to point out the logical fallacy in statements I read online, i.e. ”because someone on the Internet was wrong”. Trying to gaslight me with personal accusations of psychological projection, however, is crossing a line. Do not do that to other people, it is violence. You do not know what I think or feel, only what I write.

the_gipsy 4y ago

It can also be a burden pushed away from the author to reviewers (or future contributors), hence why OSS repos usually require clean/squashed PRs.

eurasiantiger 4y ago
How is it a burden? Just diff the HEADs of the branches like GitHub does by default?

u801e 4y ago

> It is valuable history: it is archaeological evidence of what has been attempted before. Except that is not readily accessible. When looking at a particular section of code, you could either run git blame, or run git log and filter it to only list commits that updated that file. Either way, you're not going to easily be able to find what previous implementations were tried, or why they were not used compared to the current implementation. But if you make a clean commit with the working implementation and include an explanation of what other approaches were tried and why they weren't used, then someone could use git blame to get the information pretty easily.