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

A better pull request

developer.atlassian.com

Post reply on HN
Print view View original

101–110 of 167 posts

Re: A better pull request

#101

Post by jjwiseman »

erikb wrote: post #89

I can't really say why, but many things I've read from Atlassian/Bitbucket in recent months always had the feeling of B class (in contrast to A class). Even at the end of the article I still don't get the real problem that is solved. Commiting Mergeconflicts is not an advantage. And that logical error thingy I have never heard or seen before. Maybe because the people (who's opinion I care about) review commit diffs i…

Atlassian's bug tracker (Jira), wiki (Confluence) and CI system (Bamboo) all feel that way to me; B team, or even C. "Atlassian--we make software that you can eventually get to work in some fashion but will never please you in any way."

Jira is almost OK, but still has that enterprise stank of trying to do too much and inserting itself too much in your workflow, instead of helping you and getting out of your way. Some people are less generous toward Jira than I am: "Next time I'm looking for a job I think use of @jira might be a deal breaker."--Peter Seibel[1].

I have no generosity toward Confluence, their wiki. Bad UI choices, a weird & inconsistent markup language that again becomes another thing to wrestle with indefinitely instead of unobtrusively helping you. I've had to use it at two jobs, and there won't be a third.

Bamboo, their CI system, seems OK, but for some reason I end up debugging a lot of build failures having to do with leftover or broken state on the build machine, which seems like one of the first things a CI system should help you avoid.

[1]https://twitter.com/peterseibel/status/451758184470835200

Re: A better pull request

#103

Post by btilly »

legomaster wrote: post #37
city41 wrote: post #14

I agree this is a better way to look at pull requests, but I'm surprised it's as much of a problem as the post implies. For us, whenever we do a pull request, we always rebase against the latest master first. That can be a cat and mouse game, but it usually isn't. Our repos don't change that rapidly.

Talking to a lot of people at conferences and similar events, rebasing against the target branch before merging is pretty uncommon. Few people think a clean history is that important. Personally I think, rebase + auto-squash/auto-fixit makes the history a lot easier when it's time to look back. It just happens so rarely I wonder if it's really worth the effort I expend on it.

YMMV. I've seen people all over the map on this.

I have noticed that among people I respect, there is a strong correlation between using git-bisect and wanting a clean history.

Re: A better pull request

#104

Post by kannonboy »

GolfyMcG wrote: post #36
chinhodado wrote: post #20

Earlier quoted context omitted.

The problem is, many pull requests take very long to get merged (because of the size of the PR, the review process, etc.), and by the time that they are ready to be merged, the target branch could very well have changed.

This is something that our team has relegated to a product development problem not a software development problem. As a product manager/technical lead you have to realize it's your job to make it as easy as possible for developers to do their job. When you set them up for HUGE merge conflicts - that only makes life harder. If you're really good about constructing discrete, small stories, you can avoid SO many pull re…

Great point. Almost all of the problems I've seen with pull requests and branching workflows stem from the size of the change. If you can avoid long-lived branches / giant diffs, most integration problems just disappear. It's not always possible to avoid them, but bearing it in mind when you're constructing stories and planning your backlog helps a lot.

Re: A better pull request

#105

Post by ngoldbaum »

vezzy-fnord wrote: post #47
fenomas wrote: post #7

Seems quite sensible. This, some commentary on forking[1] I ran across the other day, and the way SourceTree is miles beyond github's client, all make me suspect I should be at least trying out bitbucket. But since literally everything I collaborate with is on github, I've not gotten around to it. Am I missing out, or does bitbucket have its own weak spots? [1] http://zbowling.github.io/blog/2011/11/25/github/

Personally I enjoy Bitbucket for two reasons: a) free private repos mean I can use it as a remote backup for my projects, since I'm of the philosophy that you shouldn't be talking too much until you have at least a 0.1 version to show, b) no gamification and distractions. The gamification and awkward "social coding" environment that GitHub provides just feels forced to me. It's distracting from your work and it makes…

Yes! Mercurial love on HN always makes me happy. Code hosting platforms should encourage choice.

Re: A better pull request

#106

Post by city41 »

comex wrote: post #98
city41 wrote: post #78

Earlier quoted context omitted.

I don't follow because the rebase is done by the person who wrote the code and is proposing the pull request. They rewrite their local history, but that doesn't seem to relevant. They still have to get their code to work with the latest master and remain in control of it. When the PR goes through, it can be a standard merge to maintain history.

True, but while that person probably tested each original commit as they wrote it (at least to the extent the application compiled and didn't completely blow up), they probably didn't do the same for each rebased commit every time they updated to master. If the resulting history turns out to be broken, it isn't the end of the world, but makes bisecting harder. I think rebasing is a good idea anyway, but it's a tradeo…

There's no perfect solution and all of this still requires a fair amount of vigilance to get it right. But I would still argue that if you are proposing a PR, you've done the work to verify your changes work, tests pass, etc. If you later need to rebase your PR, you still should run tests, smoke test, etc.

Small issues can slip through, but on teams I've worked on, submitting a PR that is truly broken is really bad form. Sometimes that does mean submitting PRs is tedious, but that's just how it goes sometimes. Thankfully, it's not that often in my experience.

Re: A better pull request

#107

Post by kannonboy »

snowwrestler wrote: post #95

I'm surprised anyone would be willing to consider merging a branch into master that has not itself pulled the latest head from master. It puts the the person running the merge into the position of having to test someone else's code. It would seem to me that if a branch diffs against an older point in master, then the PR should be rejected as not properly tested. Merging into master should never create a merge conflic…

This is tricky to pull off on busy projects, as master is continually progressing and all open pull request branches would need to be constantly rebased.

With the Bitbucket approach, you get to see the conflict in the pull request UI, but you should still resolve it locally on your branch before merging to master.

Re: A better pull request

#108

Post by jfaucett »

Ok this is nice. Of course, if you're just rebasing before reviewing and merging the PR into master it makes this pointless.

Odd that they never mention this in the post, I was under the assumption that rebasing before creating the PR is standard practice, at least that's how we do it at work and on all the projects I've contributed to.

EDIT: I've never used bitbucket, so maybe this is just a github community thing with the rebasing?

Re: A better pull request

#109

Post by Alupis »

tnorthcutt wrote: post #75
Alupis wrote: post #30

Earlier quoted context omitted.

Bitbucket provides free private repos, and for smaller development teams and/or companies not wanting to deal with the cost of Github (which does admittedly grow exponentially the more repos you require), Bitbucket is a fine choice. When we were making the decision at my company, we went with Github because the dev team cared about having the little green squares show up on the "activity" chart for their account's...…

which does admittedly grow exponentially the more repos you require Just to clarify, GH's pricing doesn't actually grow exponentially. The per repo price gets lower the more you pay for: 5 private repos: $7 10 private repos: $12 20 private repos: $22 50 private repos: $50

For a team, pricing is different. 50 repos is $100 a month, 125 repos is $200 a month ($2,400 a year). Granted, it's not "exponential", I was using a figure-of-speech referring to the pricing becoming significant.

For an internal-dev team which generates a great deal of new repos throughout the year (one-off scripts/programs for different departments, etc...), this adds up very quickly.

If you reach that 126th repo, it jumps to $450 monthly or $5,400 a year. At those prices you get questions from Accounting about why we aren't hosting this internally...

Re: A better pull request

#110

Post by biot »

dominotw wrote: post #88

We run unit tests on jenkins on the merged branch( which github creates automatically) and set the commit status on PR. Shouldn't that take care of logic bugs?

If you have 100% code coverage and have solved the halting problem, yes.
Post reply on HN