Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Merge Pull Request Considered Harmful

blog.spreedly.com

Post reply on HN
Print view View original

91–100 of 115 posts

Re: Merge Pull Request Considered Harmful

#91

Post by warfangle »

lomnakkus wrote: post #82
warfangle wrote: post #78

Earlier quoted context omitted.

It might make sense to squash so you only have compile-ready commits in your log. In a sense I work this way, without the squashing. When I write a test, the build fails and nothing has been done on the application codebase so I don't commit. When I fix the build by writing new code, I commit. Maybe I should be doing small intermediate commits and squashing the commits into one commit.

> Maybe I should be doing small intermediate commits and squashing the commits into one commit. I would recommend trying that, or at least something similar: Try committing regularly (this is useful if you ever want to go back to a prior state while working or e.g. pick up where you left off on a different machine, etc), but reorganizing and cleaning up your topic branch (via rebase -i, etc.) into a few commits befor…

Yeah, I've been using 'have I added things, and do my tests pass' as a metric for when I should commit - I'm pretty strictly TDD these days.

Re: Merge Pull Request Considered Harmful

#92

Post by btilly »

chrismorgan wrote: post #73
livingparadox wrote: post #68

Earlier quoted context omitted.

Since the author of the article decided to invoke Linus, I thought I'd see what Linus thought about the merge vs rebase debate. http://www.mail-archive.com/dri-devel@lists.sourceforge.net/... Turns out Linus also agrees with drunken_thor, that merge messages are useful. Suppose that's why Linus added merges in the first place. ;)

His answer there on this topic boils down to “tell the patch author that they made a mistake, and steadfastly refuse to do anything with it yourself until the patch author does fix it”. This is the whole point of this article—that is simply not pragmatic; you can have changes made that aren’t quite perfect but where the original user is not willing to make the changes you require. It being abandoned in imperfect stat…

Linus' situation is that his ability to handle incoming contributions is a real bottleneck. In that case it is worthwhile to say, "Make my life easy or I ignore you." And because people want their stuff in his project, they do wind up making his life easy.

Most open source maintainers are not in that position.

Re: Merge Pull Request Considered Harmful

#94

Post by ntalbott »

grogenaut wrote: post #87

Considered Harmful blog posts Considered Harmful

You forgot to reference the great recursive essay Eric Meyer wrote on exactly this topic:

http://meyerweb.com/eric/comment/chech.html

Which essay I already knew about and chose to willfully ignore when I titled the OP. We could chat over beers sometime as to whether I'm a bad person for doing so :-)

Re: Merge Pull Request Considered Harmful

#95

Post by MichaelGG »

rjbwork wrote: post #34
thinkt4nk wrote: post #23

harmful?

It's a play on the classic Dijkstra letter, "Goto Considered Harmful." Also yes, I think it's harmful. A co-worker and I wanted to use a new up and coming FOSS project that's hosted on GitHub, but we needed a certain killer feature. Said co-worker worked for about 4 weekends in a row, and fully implemented it, with nice abstraction and separation of concerns. The code was then turned down because it was "too seperate…

I was once on the other side of this. A nice guy wrote a whole ton of code for a module, refactored things to the max, made it "testable" and a bunch of other things. He was very nice, very enthusiastic, and really wanted to help.

But I had to say no because it didn't fit well within the overall project, and didn't really add any value but a lot of complexity. I felt very bad to turn him down but otherwise I'd be now responsible for code I have no interest in and code I don't feel helps users.

The right way is to talk to the maintainer and agree on what to do first. Or be prepared to run a fork.

Re: Merge Pull Request Considered Harmful

#96

Post by rjbwork »

rlpb wrote: post #44
rjbwork wrote: post #34

Earlier quoted context omitted.

It's a play on the classic Dijkstra letter, "Goto Considered Harmful." Also yes, I think it's harmful. A co-worker and I wanted to use a new up and coming FOSS project that's hosted on GitHub, but we needed a certain killer feature. Said co-worker worked for about 4 weekends in a row, and fully implemented it, with nice abstraction and separation of concerns. The code was then turned down because it was "too seperate…

The right way to do this is to talk to the maintainer about how he wants the feature implemented first. Especially if it involves four weekends of work.

We did, he explained it, then implemented it himself, and it was a bug-ridden, memory-leaking piece of shit that isn't merged in either.

Re: Merge Pull Request Considered Harmful

#97

Post by ForHackernews »

npsimons wrote: post #86
ForHackernews wrote: post #58

Earlier quoted context omitted.

Yeah, I found the notion of a commit being "history worthy" kind of silly. If that's how it happened, then it's history! It's not a value judgement.

There's an issue here where people are conflating two definitions of "history". Sure, what happened in the real world can't be changed, but why should we be constrained by that in the worlds we construct in software? Just because someone calls a record of development "history" doesn't make it inviolate, and quite frankly, as a maintainer, I don't care about every little sneeze that a developer had on a project. I wan…

I guess different people have different workflows. I prefer to make many tiny atomic commits that gives me very granular ability to backtrack if things go wrong.

For "conceptual chunks", I use branches or tags, and don't worry about the individual commits very much.

Re: Merge Pull Request Considered Harmful

#99

Post by mindcrime »

ForHackernews wrote: post #97
npsimons wrote: post #86

Earlier quoted context omitted.

There's an issue here where people are conflating two definitions of "history". Sure, what happened in the real world can't be changed, but why should we be constrained by that in the worlds we construct in software? Just because someone calls a record of development "history" doesn't make it inviolate, and quite frankly, as a maintainer, I don't care about every little sneeze that a developer had on a project. I wan…

I guess different people have different workflows. I prefer to make many tiny atomic commits that gives me very granular ability to backtrack if things go wrong. For "conceptual chunks", I use branches or tags, and don't worry about the individual commits very much.

Same here. I don't generally care how "messy" the git commit log is, but when we reach a point where something is notable, then it's time for a tag/release or whatever.
Post reply on HN