3 ms·

> do annoying things like rewriting commit histories after I made comments in their PRs That's exactly what I'd expect someone to do after I commented on their

> do annoying things like rewriting commit histories after I made comments in their PRs That's exactly what I'd expect someone to do after I commented on their PR.

Supermancho 6y ago
> ewriting commit histories after I made comments in their PRs > That's exactly what I'd expect someone to do after I commented on their PR. The vast majority of people do not. I certainly wouldn't expect someone to waste time on that.
- jamienicol 6y ago
  > The vast majority of people do not. That's a very bold claim. It's certainly been the expected workflow everywhere I've worked. You might consider it a waste of time but I'd wager the resulting mess of commits from not doing so wastes far more time in the long run.
  - recursive 6y ago
    I've never worked in an environment where it was expected or used. As far as I can tell, no time has been wasted as a result. How would it cause time wasting?
    - jamienicol 6y ago
      Without a clean history it takes longer to find which commit changed things and why.
      - recursive 6y ago
        I believe I've really only needed to do that once. git bisect handled it in about 10 minutes IIRC. It's hard for me to imagine how I could achieve a net time savings against that level of commit-hunting.
        jamienicol 6y ago
        I envy you then. I spend a great deal of time looking through history to find bugs. An unclean history is less likely to work well with bisect too, as the individual commits may be broken.
        Supermancho 6y ago
        > I spend a great deal of time looking through history to find bugs. You mean when where and how a change was introduced? I dont think bugs are located in the history, since bugs are operational failures on a deployed branch.
        jamienicol 6y ago
        Yes, I phrased that badly. Let's say looking through history to understand the context of when bugs were introduced and how to fix them
recursive 6y ago
No one I work with does that. They do one of two things. 1) argue that they really don't need to change anything 2) push more commit(s) Why would it be better to rewrite history?

> do annoying things like rewriting commit histories after I made comments in their PRs That's exactly what I'd expect someone to do after I commented on their PR.

Supermancho 6y ago

> ewriting commit histories after I made comments in their PRs > That's exactly what I'd expect someone to do after I commented on their PR. The vast majority of people do not. I certainly wouldn't expect someone to waste time on that.

jamienicol 6y ago
> The vast majority of people do not. That's a very bold claim. It's certainly been the expected workflow everywhere I've worked. You might consider it a waste of time but I'd wager the resulting mess of commits from not doing so wastes far more time in the long run.
- recursive 6y ago
  I've never worked in an environment where it was expected or used. As far as I can tell, no time has been wasted as a result. How would it cause time wasting?
  - jamienicol 6y ago
    Without a clean history it takes longer to find which commit changed things and why.
    - recursive 6y ago
      I believe I've really only needed to do that once. git bisect handled it in about 10 minutes IIRC. It's hard for me to imagine how I could achieve a net time savings against that level of commit-hunting.
      - jamienicol 6y ago
        I envy you then. I spend a great deal of time looking through history to find bugs. An unclean history is less likely to work well with bisect too, as the individual commits may be broken.
        Supermancho 6y ago
        > I spend a great deal of time looking through history to find bugs. You mean when where and how a change was introduced? I dont think bugs are located in the history, since bugs are operational failures on a deployed branch.
        jamienicol 6y ago
        Yes, I phrased that badly. Let's say looking through history to understand the context of when bugs were introduced and how to fix them

recursive 6y ago

No one I work with does that. They do one of two things. 1) argue that they really don't need to change anything 2) push more commit(s) Why would it be better to rewrite history?