7 ms·

You’re describing merges, not commits, or pushes to remotes. One can commit and push to branches all day. Merging them to master without a heads up is a bad i

You’re describing merges, not commits, or pushes to remotes. One can commit and push to branches all day. Merging them to master without a heads up is a bad idea, except where teams have implemented a process that can handle it

inlined 7y ago
Many of us do a “squash merge” (use git rebase to compress to meaningful points in a CR and again before merging to master or feature branches). This creates a clean history at the expense of not being able to stalk others work at high granularity or get as large a score on github’s tracker.
- testvox 7y ago
  Git rebase interactive with fixup or squash will combine the commits into the first one. So the timestamp will still be somewhat reflective of when work is done (on average).
  - inlined 7y ago
    Though I wouldn’t be surprised if there is at least some biasing. E.g. first commits happening relatively soon after regularly scheduled scrum meetings. At least if they’re the type of developer who checkpoints after incremental changes.
  - mandelbrotwurst 7y ago
    Are you sure? It seems fairly likely to me that the average time of day that someone makes the initial commit on a new branch would be quite different from the average time of day that they make commits generally. Am I misunderstanding?
- MaxBarraclough 7y ago
  I'm not convinced that a 'clean history' beats a richer more fine-grain history. There's a reason frequent small commits are generally thought to be the way to go.
  - hoten 7y ago
    except of my dozens or so commits to a feature branch, most of which are "update" or "fix test" or "oops forgot edge case". But for the one squash commit, it's "some-feature-tag: nice description of the changes (#relevant-pr)". and there's no way I'm going to write more than one nice commit message for a branch. You can still get the fine-grained commits if you keep your merges focused on one thing.
    - MaxBarraclough 7y ago
      > You can still get the fine-grained commits if you keep your merges focused on one thing. Right. This is what Git Flow does. Best of both worlds.
- hinkley 7y ago
  Stalking other workers at high granularity is sometimes the only way I have to figure out what was going through their head (or indeed, my head 2 years ago) when they wrote this... very interesting logic. The biggest WTF programmer I work with squashes all of his commits. So every commit is 100-400 lines of Rube Goldbergian majesty.
dahart 7y ago
> You’re describing merges, not commits, or pushes to remotes. Both merges and commits can be pushed. I’m not exactly sure what distinction you’re trying to make. Also, btw, I’m using git terminology, but not everyone uses git. I’m including my experience on teams that use Perforce, for example. > One can commit and push to branches all day. Merging them to master without a heads up is a bad idea. Yeah, right, exactly. You agree with me. My policy is about putting anything new in the master branch during off hours, because breaking changes that evade the tests may not get fixed until work hours, and prevent other people from working at night or over the weekend.
- kragen 7y ago
  The article is about the times of day Git commits were made, not the times of day they were pushed, nor the times of day people used other source-control systems like Perforce. You said, "I’d be very cautious about assuming that commit time has anything to do with work time," citing your own policy of not pushing at night as an example of how "commit time" may not have anything to do with work time. Now you're saying, "My policy is about putting anything new in the master branch during off hours," which is to say, it's about pushes, not commits. This means that your original top-level comment is completely irrelevant to the article you are commenting on, which is unfortunate, since it's the top-voted comment on the article. You should edit the top-level comment to reflect that fact, or, if that's not possible, add a second-level comment retracting it.
  - dahart 7y ago
    I stand by my top comment, avoiding pushes Friday and waiting until Monday often leads to both code commit times on Monday and merge commit times on Monday. (Edit: and BTW I know this for a fact, because we monitored average commit times to make sure the policy was being adhered to.) If you look at the code from the article, you’ll see that the author did not filter out merge commits. The word merge doesn’t even appear in the article. The OPs data includes merge commits. You’re trying to draw a hard and idealized line that doesn’t exist in real companies. Squashes often happen right before push. Stashing for the weekend rather than committing is common. People unsafely leaving uncommitted changes in their workspace over the weekend is common. Most devs in my experience are not git experts, and they don’t always use git in best practices kinds of ways. That is made evident every time there’s a git thread on HN. I am talking about commit time, my push policy affects my commit times. You can’t count on commit times to demonstrate anything.

inlined 7y ago

Many of us do a “squash merge” (use git rebase to compress to meaningful points in a CR and again before merging to master or feature branches). This creates a clean history at the expense of not being able to stalk others work at high granularity or get as large a score on github’s tracker.

testvox 7y ago
Git rebase interactive with fixup or squash will combine the commits into the first one. So the timestamp will still be somewhat reflective of when work is done (on average).
- inlined 7y ago
  Though I wouldn’t be surprised if there is at least some biasing. E.g. first commits happening relatively soon after regularly scheduled scrum meetings. At least if they’re the type of developer who checkpoints after incremental changes.
- mandelbrotwurst 7y ago
  Are you sure? It seems fairly likely to me that the average time of day that someone makes the initial commit on a new branch would be quite different from the average time of day that they make commits generally. Am I misunderstanding?
MaxBarraclough 7y ago
I'm not convinced that a 'clean history' beats a richer more fine-grain history. There's a reason frequent small commits are generally thought to be the way to go.
- hoten 7y ago
  except of my dozens or so commits to a feature branch, most of which are "update" or "fix test" or "oops forgot edge case". But for the one squash commit, it's "some-feature-tag: nice description of the changes (#relevant-pr)". and there's no way I'm going to write more than one nice commit message for a branch. You can still get the fine-grained commits if you keep your merges focused on one thing.
  - MaxBarraclough 7y ago
    > You can still get the fine-grained commits if you keep your merges focused on one thing. Right. This is what Git Flow does. Best of both worlds.
hinkley 7y ago
Stalking other workers at high granularity is sometimes the only way I have to figure out what was going through their head (or indeed, my head 2 years ago) when they wrote this... very interesting logic. The biggest WTF programmer I work with squashes all of his commits. So every commit is 100-400 lines of Rube Goldbergian majesty.

dahart 7y ago

> You’re describing merges, not commits, or pushes to remotes. Both merges and commits can be pushed. I’m not exactly sure what distinction you’re trying to make. Also, btw, I’m using git terminology, but not everyone uses git. I’m including my experience on teams that use Perforce, for example. > One can commit and push to branches all day. Merging them to master without a heads up is a bad idea. Yeah, right, exactly. You agree with me. My policy is about putting anything new in the master branch during off hours, because breaking changes that evade the tests may not get fixed until work hours, and prevent other people from working at night or over the weekend.

kragen 7y ago
The article is about the times of day Git commits were made, not the times of day they were pushed, nor the times of day people used other source-control systems like Perforce. You said, "I’d be very cautious about assuming that commit time has anything to do with work time," citing your own policy of not pushing at night as an example of how "commit time" may not have anything to do with work time. Now you're saying, "My policy is about putting anything new in the master branch during off hours," which is to say, it's about pushes, not commits. This means that your original top-level comment is completely irrelevant to the article you are commenting on, which is unfortunate, since it's the top-voted comment on the article. You should edit the top-level comment to reflect that fact, or, if that's not possible, add a second-level comment retracting it.
- dahart 7y ago
  I stand by my top comment, avoiding pushes Friday and waiting until Monday often leads to both code commit times on Monday and merge commit times on Monday. (Edit: and BTW I know this for a fact, because we monitored average commit times to make sure the policy was being adhered to.) If you look at the code from the article, you’ll see that the author did not filter out merge commits. The word merge doesn’t even appear in the article. The OPs data includes merge commits. You’re trying to draw a hard and idealized line that doesn’t exist in real companies. Squashes often happen right before push. Stashing for the weekend rather than committing is common. People unsafely leaving uncommitted changes in their workspace over the weekend is common. Most devs in my experience are not git experts, and they don’t always use git in best practices kinds of ways. That is made evident every time there’s a git thread on HN. I am talking about commit time, my push policy affects my commit times. You can’t count on commit times to demonstrate anything.