181–190 of 215 posts
Who cares? Why does it matter?
It does not even remotely matter. What matters is who is going to maintain all of this after the years to come. (Or they could be even obseleted or superseeded anyway.)
Earlier quoted context omitted.
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.
There's a reason frequent small commits are generally thought to be the way to go.
Let's cargo cult the advice on this ftw. Also let's piss off our managers by saying, "Yeah, I heard this on Hacker News." Here for the downvotes to get back to 666.
Earlier quoted context omitted.
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…
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.
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'm a forgetful person, so I commit very often but with label "tmp", and later I squash them all into 1 proper commit before pushing. I'm sure I'm not alone, so commit time can't be used as barometer.
I would suggest making use of 'git commit --fixup' or 'git commit --squash' which creates a commit that is specially-named such that you can later squash everything together with `git rebase --autosquash'. It's really transformed how I work on large patchsets.
Who cares? Why does it matter?
Exactly, no-one cares. This industry is creating a culture of celebrity programmers and worshipping and glorifying the code they write. It does not even remotely matter. What matters is who is going to maintain all of this after the years to come. (Or they could be even obseleted or superseeded anyway.)
To those asking about whether time zones are considered, the author responded in [1]: > The script uses the time the author saw on his wall clock when doing the commit. I can't imagine better time to use for such graphs [1] https://gist.github.com/bessarabov/674ea13c77fc8128f24b5e3f5...
Earlier quoted context omitted.
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.
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.
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.
Earlier quoted context omitted.
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.
Right. This is what Git Flow does. Best of both worlds.
Earlier quoted context omitted.
Hypothetically the author thought of “epic programmers” and only came up with white males. Women and PoC have given great contributions in our industry and are underrepresented. This could have been an opportunity for the author to learn about some and give them a bit of credit.
Can you give us some examples of programmers of "epic" repute that are women or people of color? (Or both?) I'd like to be able to bring them up when I find myself reading something that doesn't include them.