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.
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
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?
There's a reason frequent small commits are generally thought to be the way to go.
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.
Right. This is what Git Flow does. Best of both worlds.
The biggest WTF programmer I work with squashes all of his commits. So every commit is 100-400 lines of Rube Goldbergian majesty.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
> 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.
I found the phrasing abstruse relative to my daily way of thinking of these things
> 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...
I'd be more concerned about code being committed to master without code review.
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.
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.
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=isoOur 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
In a way a lot of this CI/CD stuff was easier when you ran it on your CI system.
Because, obviously, it's pushing commits that's problematic, not committing per se (in git vocabulary).