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

111–120 of 167 posts

Re: A better pull request

#111

Post by Alupis »

z-e-r-o wrote: post #82
jackweirdy wrote: post #48

Earlier quoted context omitted.

If it’s personal stuff, why do you need an upstream? Assuming it’s for redundancy, why not just copy the folders as part of a normal backup?

In my case, OS X has the latest git, while Windows is stuck on 1.9, and my git folders get corrupted if I do a push on OS X and simply do a status on Windows. I guess something has changed between 1.x and 2.x but this corruption is really not something which should ever happen in a VCS. My solution is to use Gitlab instead of Dropbox only local repos.

I'm not aware of any changes between 1.x and 2.x that would corrupt a repo... I use a mix on various systems, some even still have git 1.7.x on them. The only problem I run into is when you have some script that depends on a newer git feature added in a newer version...

My money would be on Dropbox busting your repo somehow. I don't think Dropbox is an ideal solution for pushing/pulling git repos from.

Re: A better pull request

#112

Post by mindprince »

When I first encountered this behavior on BitBucket, I spent a lot of time reading the man pages and searching the internet trying to find out which option were they providing to `git diff` to get this diff output but couldn't find anything. Looks like there is indeed no such option. It would be awesome if git had something like `git diff branch-name --merge-commit-diff`.

Re: A better pull request

#113

Post by saraid216 »

SoftwareMaven wrote: post #90
stevebot wrote: post #87

Applying the God principle to this, there should never be merge conflicts. I should get notified that the file has changed before I even change it. That is how I imagine it would be if a God made it.

But at the time you modify it, the other file may not be modified. And, when your merge partner modifies it, she may be on an 18 flight to the South Pole with no internet access. Now, sure, you can say "well, God can get around that", but, unfortunately, there are real constraints that cannot be gotten around. Good design is how you deal with those constraints.

Complete tangent: I've never heard the term "an 18 flight". What is that, and what is it from?

Re: A better pull request

#114

Post by Nemo157 »

jfaucett wrote: post #108

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 w…

For smaller projects that's fine, but if you have a lot of outstanding pull requests under discussion that's a lot of continual rebasing as they each get merged. (What if the two fee fixes in the article were done at the same time and reviewed by different project maintainers?)

Re: A better pull request

#115

Post by jfaucett »

Nemo157 wrote: post #114
jfaucett wrote: post #108

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 w…

For smaller projects that's fine, but if you have a lot of outstanding pull requests under discussion that's a lot of continual rebasing as they each get merged. (What if the two fee fixes in the article were done at the same time and reviewed by different project maintainers?)

That sounds really unorganized to me at least, I mean the linux kernel is large and there's only one guy at the end of the day merging all that stuff.

I would think that in larger projects a better practice would be a distributed hierarchy of merges until a PR finally got submitted to master, not a massive blob of just send everything to master as a PR and let various maintainers merge whatever at will.

Re: A better pull request

#116

Post by nucleardog »

SystemOut wrote: post #49
mkinsella wrote: post #27

Earlier quoted context omitted.

Are there that many non-enterprise companies using Bitbucket over Github? Most startups and mid-sized companies I know use Github for private repo hosting.

We use BitBucket since we're a small shop from a developer count standpoint but we have a ton of small repos plus we migrated over a ton of legacy svn repos. GitHub gets expensive real quick when you are in that situation.

For anyone doing 'client work' rather than developing a single/few products, GitHub's pricing is almost prohibitively expensive.

We have a little over a hundred repositories. This puts is in the $200/mo plan for GitHub (125 repository limit).

Atlassian prices per-user. Our small three person dev team costs us nothing. We'll reach the next pricing tier when we hit our 6th developer, at which point it will cost us $10/mo and will remain that cost up to 10 developers.

BitBucket's top plan is $200/mo. That gets you unlimited repositories and users compared to GitHub's 125 repositories.

In the middle tier, GitHub charges $50/mo for 20 repositories whereas BitBucket charges $50/mo for 50 users.

If you have few repositories but many users, GitHub's pricing is advantageous. If you have many repositories but few users, BitBucket makes way more sense.

Re: A better pull request

#117

Post by azakai »

Something doesn't add up for me. I constantly push the github "merge" button, and I've never, ever, seen an error AFTER I push it. It it wasn't checking for mergeability on actually current master, that seems surprising.

Is the issue that the button knows if a pull will merge ok, because it does test on current master, but the diff shown in the UI is different from that, and not on current master, and just on the older commit? If so, I think this could have been clarified better in the post.

Even so, this means that sometimes the button should be red - can't merge, has conflicts - while the diff as shown looks fine. I've never seen that happen. So something is puzzling here.

Re: A better pull request

#118

Post by chinhodado »

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…

This is more of a problem in open-source projects where occasionally someone would drop by a project and submit a PR without any prior planning, and more often than not disappear for a while before coming back to address your comments/review. It is less of a problem in closely-tied teams.

Re: A better pull request

#119

Post by sls »

Alupis wrote: post #109
tnorthcutt wrote: post #75

Earlier quoted context omitted.

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,…

GitHub Enterprise is an appliance VM you run internally. It's charged per seat. The last enterprise-y company I was at used it primarily because you keep your code inside the firewall, but also because the pricing model is more aligned with the usage in that environment, as you suggest.

Re: A better pull request

#120

Post by ajnin »

taeric wrote: post #67
kannonboy wrote: post #59

Earlier quoted context omitted.

In Bitbucket's implementation you still only see the changes that are unique to your branch, but they're diff'd against the current tip of master rather than the merge base.

I've said this in another thread, but I feel it really needs repeating. The diff that bitbucket is showing you is one that has not been tested. That is, the diff against the merge base shows what the requester did and tested. The diff against the current tip, shows what will be the result. I fully agree that it is important to bear that in mind. But, this is all the more reason for the merge to be done by another par…

True, but at least it shows you the actual result of applying the diff to the HEAD, as opposed to all other GUI tools that show you a diff that nobody has seen, let alone tested, in a merged state. So what is done by bitbucket is better in that regard.
Post reply on HN