3 ms·

Linus Torvalds: if you cannot explain a merge, then JUST DON'T DO IT

16 points by sathishmanohar 4y ago

abudabi123 4y ago
Could pair the programmer with bug-reporter to explain the merge.
Iolaum 4y ago
He later in that thread gives a very thorough explanation for his reasoning.
khaki54 4y ago
Linus unloads on the guy who did a pretty good job explaining what was in there (not why it was needed though), serves out plenty of collateral damage for everyone who's ever submitted a self-serving merge to go "hmm is he talking about me from 2 years ago?". Despite making a good point, where the guy is thinking "well I guess I'm not getting that merge", he goes ahead and approves without further comment. Probably controversial, but you want a few people like this in your organization holding the line against the barbarian hordes, especially when you are the barbarian, because you are reminded WHY you are following the process and it lets you know that others aren't getting over.
- temp2022account 4y ago
  I think Linus is making a good point, in a project as long-running as the kernel having commit messages like "Merge temp-branch-a into temp-branch-a-next" is clutter and really ought not make it into `master`. Obviously Linus could just manually re-merge the changes, picking out the commits individually, but that's a ton of work and doesn't scale well as contributors grow.
nunez 4y ago
Linus's follow-up explanation was beautiful.
gct 4y ago
Once again glad I don't work with Linus
- karmakaze 4y ago
  It would however, be pretty good to work with those who do. Often I'm the one making unpopular requests or demands on quality. Teammates don't always appreciate them at the time, but they all appreciate it when the project is done and they have to support it, or go on to work in an area where such criteria was not applied.
kwertyoowiyop 4y ago
It’s funny that just a few items above this HN’s “new” is a link to gitimmersion.com. Yes, ladies and gentlemen, THIS is what you have to look forward to at the end of your Git immersion!

abudabi123 4y ago

Could pair the programmer with bug-reporter to explain the merge.

Iolaum 4y ago

He later in that thread gives a very thorough explanation for his reasoning.

khaki54 4y ago

Linus unloads on the guy who did a pretty good job explaining what was in there (not why it was needed though), serves out plenty of collateral damage for everyone who's ever submitted a self-serving merge to go "hmm is he talking about me from 2 years ago?". Despite making a good point, where the guy is thinking "well I guess I'm not getting that merge", he goes ahead and approves without further comment. Probably controversial, but you want a few people like this in your organization holding the line against the barbarian hordes, especially when you are the barbarian, because you are reminded WHY you are following the process and it lets you know that others aren't getting over.

temp2022account 4y ago
I think Linus is making a good point, in a project as long-running as the kernel having commit messages like "Merge temp-branch-a into temp-branch-a-next" is clutter and really ought not make it into `master`. Obviously Linus could just manually re-merge the changes, picking out the commits individually, but that's a ton of work and doesn't scale well as contributors grow.

nunez 4y ago

Linus's follow-up explanation was beautiful.

gct 4y ago

Once again glad I don't work with Linus

karmakaze 4y ago
It would however, be pretty good to work with those who do. Often I'm the one making unpopular requests or demands on quality. Teammates don't always appreciate them at the time, but they all appreciate it when the project is done and they have to support it, or go on to work in an area where such criteria was not applied.

kwertyoowiyop 4y ago

It’s funny that just a few items above this HN’s “new” is a link to gitimmersion.com. Yes, ladies and gentlemen, THIS is what you have to look forward to at the end of your Git immersion!