Hacker News Reader

Comment by dahart | Hacker News Reader

Personally, I’d be very cautious about assuming that commit time has anything to do with work time.

For at least 15 years I’ve had a policy - and so have the people on my teams - to avoid merging or committing to public branches at night or just before & during weekends so that you don’t accidentally hose other people on the team, who rely on automated builds & testing. We write code at all hours, but wait to commit/push/merge to master until the morning when everyone’s there.

I realize that not everyone has policies like that, but these are high profile programmers who are likely to have their own complicating factors. Linus, for example, commits a lot of merges that other people depend on; his code reviews and code writing might be on separate schedules.

View on HN

Strange policy about commits — why just not push at night or during weekends? Why's everyone not working on branches?

> Strange policy about commits — why just not push at night or during weekends? Why's everyone not working on branches

That is what I’m saying. The policy is avoid pushes to master. My policy does apply to branches too once there are more than a few people in the branch.

Lots of people do work in branches, but everywhere I’ve worked, plenty of people skip branching when they’re making what they think are “small” changes. And some places I’ve been, the team has decided on a policy to skip branches & merges for single commit changes due to the history noise it causes.

The policy is to avoid breaking changes being committed to master when people aren’t around to notice & fix it.

I think the reason for confusion is that you seem to say that people doesn't even commit their work when they work, but only when they're pushing as well. dchest is (seemingly) asking why don't you commit when you're done, but delay the pushing (according to your policies)?

The confusion was my fault, but I think is mostly gone now. I initially described it as commits when I was thinking of pushes, partly because I’m lumping both git and Perforce experience together. I edited my comments to be more clear, and it seems to have helped.

The question asked is valid, and we do commit often, we only avoid pushes to shared spaces at night, so some commits may have representative time stamps. As others have mentioned, squashing might compromise that, and commits made Friday but pushed Monday are, in my experience, more likely to be modified Monday right before pushing. For me, it’s pretty rare that the first commit time survives until push, I’m almost always squashing code, multiple times, before it’s ever pushed.

Absolutely! In addition, if you've spent a full day on a single commit, it'll show in these stats as a single data point at the end of the day - the fact that you were working for the 8 hours leading up to the commit as well is lost.

This isn't entirely correct. Git commits have two timestamps: the author timestamp and the commit timestamp. Git only shows the author timestamp by default, and that timestamp definitely survives `git commit --amend` and other operations like rebase with squash. I've had commits where the author timestamp was many months older than my last modification to the commit before finally pushing it upstream.

Unfortunately, TFA doesn't discuss which timestamp is being looked at, though that leads me to suspect that it's looking at the author timestamp because that's the default.

> that timestamp definitely survives `git commit --amend` and other operations like rebase with squash.

You're only talking about the first commit in a squash, and assuming that there aren't multiple squashes, right? There isn't only one timestamp in a squash, so you lose all but one of them.

> I've had commits where the author timestamp was many months older than my last modification to the commit before finally pushing it upstream.

Right, exactly, this illustrates why looking at timestamps isn't a good proxy for work time.

> TFA doesn't discuss which timestamp is being looked at

Here's the relevant portion of the script from the article:

    git log --author="Linus Torvalds" --date=iso

For history noise, just rebase before merging and you won't get a merge commit. It's really easy and preserves the use of branches.

Our process is:

- create a branch for every change - make commits relatively small, but complete; each commit shouldn't break the build our the tests - request peer review when the code is ready to merge - when reviewed, rebase onto team's development branch and merge

We have emergency production rollback to the last working deploy. That's what you do when breaking changes are committed to master. Letting devs commit to master directly? Horrible idea.

That’s a great strategy that works in some scenarios. Preventing weekend breaks would depend on a daily deploy schedule? I do normally revert first and ask questions later when breaking changes appear, that’s similar to what you’re saying, I think...

> Letting devs commit to master directly? Horrible idea.

I’ve never been on a team that disallows commits to master. I can see the thinking, and maybe I should be doing that, but for whatever reason, the places I’ve been are less formal than that and they might be concerned about slowing down turnaround times during the day when people need to share things more quickly.

FWIW, I am including git and also VCSs other than git. It’s harder to wall off the master branch in Perforce as a policy decision. And maybe I just haven’t been on a large enough team to warrant having someone with full time merge duties...

> the places I’ve been are less formal than that and they might be concerned about slowing down turnaround times during the day

I'd be more concerned about code being committed to master without code review.

a merge to master should only be done after a review, eg. PR is accepted by X reviewers which most likely happens only during working hours. Not sure I understand your policy, people randomly committing/pushing to master without review is not a good idea at any time.

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

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.

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).

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.

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?

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.

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.

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.

> 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.

> 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.

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.

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.

You're attempting to defend the relevance of your comments to an article about the development practices of, among other people, Linus Torvalds, by saying, "Most devs in my experience are not git experts, and they don’t always use git in best practices kinds of ways." Perhaps you are not aware that Linus Torvalds originally wrote Git, and did so specifically to mechanize what he considers to be "best practices".

Edited to add: apparently something in my phrasing is leading you to believe that I'm angry with you and wanting to attack you. I'm not sure what that is, but that isn't my intention. I just think what you're saying isn't true, or rather is presumably true of your company but not of this article, and I was trying to explain why. I'm sorry for writing in what is apparently an aggressive tone.

Thank you, yes I’m well aware that Linus wrote git. I’m not sure what made you so angry, but I’m up for continuing this discussion if you’re really open to discussion, as opposed to proving me wrong no matter what. It currently feels like the latter, but I think you’re not listening or understanding what I’ve said. It seems like you’re making assumptions.

Maybe you missed that I pointed out above that Linus makes a lot of merge commits, and you’ve just ignored my previous point about merge commits which is completely and directly relevant to my comments. The article included Linus’ merge commits in their histogram of his commit times. If Linus is waiting to merge like I do, then the data is skewed. If Linus is code reviewing and emailing in the morning, and writing code at night, then the data is misleading.

The merge commits made by Linus will have as their date and time the time when he made the merge locally on his own machine, which can be different from the time that he pushed those changes out (and given that he specifically designed git to have this capability it seems rather plausible that he uses it).

Merge commits are really the same as non-merge commits. The only difference is the number of parent commits, which is irrelevant for this discussion.

For what is worth kragan is entirely right here.

As strawman arguments often are within their own context. That doesn't mean I'm wrong. My point that merge commits were included in the OP's article and data went unanswered by @kragen, and it's directly relevant to what I said at the top; merge commits don't represent work time, but they're being counted here. Code commits also don't necessarily represent work time either, due to squashing, stashing, and general dev practice, so I haven't heard any evidence that convinces me otherwise. Do you have any to add?

Merging is work too. The times of merges are indicators that the person did work at that time.

Obviously the methodology is limited but it does seem to work well in practice. If you have evidence that the statistics are wrong for one of the listed programmers, please do share it.

Your attack on my integrity here is unwelcome and entirely unwarranted; that does make me angry. I regret having given you so much of my time in this thread and having assumed good faith on your part.

> Your attack on my integrity here is unwelcome

I absolutely did no such thing. You may wish to consider taking that untrue statement back, for the sake of your integrity. Nothing I said is attacking you personally in any way.

You called for a retraction of my top comment, implying it is flip-flopping and hypocritical, but you misunderstood my argument and made a rebuttal point that didn't address mine. That's a straw man, and since you appear to believe "straw man" is judgemental, it is not. It simply means you're arguing against a different point than the one I made.

It's a fact that you haven't yet responded to the merge commit point I made, and that merge commits in the OPs data are relevant to my original comment.

> I regret having given you so much time

You make it sound like I'm supposed to appreciate you calling my words untrue and "completely irrelevant". How does arguing with me and saying I'm attempting to defend an irrelevant position amount to you extending good faith?

I find kragan's comments to be creating strawman arguments. They are unnecessarily confrontational.

> You can’t count on commit times to demonstrate anything.

Very extreme stance! Especially for so deep in thread. Sometimes it’s nice to make your ideas more specific as you go deeper in conversation, not just radicalize and double down.

Interesting; I don’t consider what I said extreme or radical at all. I’ll rephrase it into a question: what do you claim that commit time demonstrates, considering that commit times can and do in practice very often change immediately prior to push?

Commit time has some correlation with when code is written. It’s not perfect, but for me personally it’s usually close.

Whether that correlation models reality closely enough to be useful depends.

My understanding of your “commit time demonstrates nothing” assertion is that you are saying there is no useful information there, which seemed like a radical position for so deep in the thread.

How can a commit time change?

git commit --amend changes author time.

git commit --amend --reset-author changes both author time and commit time.

git rebase changes commit time.

All three commands can be used just before a merge and push to clean things up. So there is no guarantee that the author time or commit time we see in the final commit history accurately represents the actual time at which the work was done.

It's a different commit. I was talking about introducing and then pushing new commits with different timestamps than the original, not somehow modifying timestamps on a specific commit. The commit that gets pushed can, and often does, have a different timestamp than the timestamp on the commit when the code was written.

That to me seems more like a sign that you should be enforcing a policy that pushing the merge button is gated by tests passing (& in successful application pushing the "merge button" should be nothing but a request to automation to apply the merge & do the tests before actually pushing it as a new master). If you're saying that there are breaking changes that are possible that test coverage is insufficient for, I would propose that the test coverage needs to be addressed. Is this advice for small 1 person repos? It can be if you want to develop good habits or be more diligent at preventing defects. It becomes more applicable as more people start contributing.

Teams I’ve worked on do gate the merges by passing tests. You’re right; test coverage is insufficient. I’ve never worked anywhere with sufficient test coverage, I truly hope to some day, but new features in my experience have always come with new breakage and new tests.

> Is this advice for small 1 person repos?

I’ve never used a wait to push policy on my own repos, I’d say my policy doesn’t make any sense in that scenario. The goal of the policy is to prevent breaking other people, not to prevent breaking myself.

Your original comment reads like pushes only goes to master, so you wait to push to a non master branch until working hours.

I found the phrasing abstruse relative to my daily way of thinking of these things

It always surprises me that workplaces with automatic deployment don’t have deploy windows. Automatic deployment only occurs 10-3 in your region and you can deploy by overriding outside that time to get out emergency fixes.

Most CI systems support running builds automatically on an interval, and I think some support time ranges as well.

In a way a lot of this CI/CD stuff was easier when you ran it on your CI system.

The policy is to risk breaking stuff only when people are in the office. It's a good concept.

I think that 'to avoid merging or committing to public branches' means 'to avoid pushing' here, specifically the 'to public branches' part.

Because, obviously, it's pushing commits that's problematic, not committing per se (in git vocabulary).

Isn't that what feature or topic branches are for? Commit in your own little world, merge when you are ready to share.

But a lot of teams prefer that you do rebases and have a flat commit history, rather than have merge commits (so your commits would reflect the time of rebase onto master, not the time you first committed to your topic branch).

I still think this a very cool back-of-the-envelope estimate though.

> (so your commits would reflect the time of rebase onto master, not the time you first committed to your topic branch)

That's not the case with git. By default it preserves the original commit time.

I think they may be talking about squashing several commits before rebasing, creating new commit(s).

Yes, this is what I meant. It wasn't clear, thanks. Generally squashing all the feature commits in a branch into 1 atomic commit in master.

It just calls it author date (it records one commit date and one author date), and one of those is preserved by rebasing. :)

Yes, that is what feature branches are for. The policy I’m talking about is referring to when people share, not when they commit to a feature branch. Sorry, I did initially described it only as “commit”, so that was my fault, not yours.

I would avoid deploys before weekends, holidays, and vacations but you have problems with your pre-merge/pre-commit testing setup if it possibly screws people up when you land something.

Interestingly, many pathologists have a policy of not signing out cases (do I commit this patient to a cancer-not-cancer diagnosis?) in the evenings. The move is generally more self-protective (tired minds make bad decisions), but certainly the 24-hour folks like hospitalists aren't looking for me to add more work to their nights and weekends either.

Looks like you already addressed that merge time != commit time. That being said, while it's hard to make a blanket statement about what part of the working process a commit falls, I'd venture a guess that it's usually at the end of a period of work. Given that, the commit time covers an indeterminate period of time before the commit's time. So having no commits at 6 AM doesn't mean the person isn't working at 6 AM, but it probably means they aren't working at 5 AM or 4 AM.

But that all being said, we only have a handful of people worth of data points and who's to say that Linus isn't someone who writes his code the previous day and commits it the next. Or that Guido isn't someone who makes lots of small commits as he's working. Hell, maybe they all squash multiple days worth of commits leaving it with a timestamp for a totally different time.

tl;dr: Yeah, I don't know that we can glean that much super reliably from this data set.

Commit time and push time are not the same time.

These are commit times, not merge times.

The article includes merge commit times; I read the script.

Includes them yes, but doesn't only use them.

Even merge commits aren't pushes.

YEP.

We instituted a policy of NO CHANGE FRIDAYS! To avoid fucking up peoples weekends.

Reply on news.ycombinator.com