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

121–130 of 167 posts

Re: A better pull request

#121

Post by sah2ed »

saraid216 wrote: post #113
SoftwareMaven wrote: post #90

Earlier quoted context omitted.

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?

Perhaps adding "hour" fixes the sentence. " ... she may be on an 18 hour flight to the South Pole with no internet access."

Re: A better pull request

#122

Post by Alupis »

sls wrote: post #119
Alupis wrote: post #109

Earlier quoted context omitted.

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.

GitHub Enterprise is even more expensive than what I quoted above. The quotes above are for private "team" repos under an "Organization" on Github (they host it all).

Re: A better pull request

#123

Post by firethief »

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…

That's a good (and standard) practice that solves the problem if your project never has more than one PR open at a time.

Re: A better pull request

#124

Post by taeric »

serve_yay wrote: post #94
taeric wrote: post #92

Earlier quoted context omitted.

No, if you rebase master into the feature branch, that will move all of the new commits to master into the feature branch. Now, it could be that I am just being a stickler for phrasing here. So, to clarify, if you are on the branch and run 'git rebase master', that is not rebasing master into the feature branch. That is rebasing the feature branch onto master. So, is that what you were doing?

My phraseology was wrong, apologies. Yes that is what I was doing. You can probably tell that my default attitude towards git is one of confusion and frustration, this is no different

No worries. I can not claim that it is a simple problem to just immediately understand. Worse, I am not good enough in my understanding, to explain in a message forum. :(

I can say that it is easy, once you understand it more. It will take some time.

Countering that point, though; if you have a codebase that is rapidly changing at all times... there really isn't anything git can do to help.

Re: A better pull request

#125

Post by taeric »

comex wrote: post #99
taeric wrote: post #79

Earlier quoted context omitted.

Close. Under this convention, somebody has to do a final test before pushing the merge commit. It can be a simple sanity test, not a full blown integration test. But somewhere somebody at least did a compile check. If it fails that test, then you push it back to the person doing the work saying so and they need to fix it.

In a GitHub project I've contributed to (dolphin-emu), a compile check for all supported platforms, plus a few tests, shows up next to the big merge button. So the "other party" doing the merge is a robot, and you can still click the button. I haven't been a committer on any other large GitHub projects, so I'm not sure how common this is.

So, sadly, I don't contribute to really any github projects. This is a new feature to me and does go a long way to addressing my concern. Honestly, it may completely address it. Certainly sounds like it does.

Re: A better pull request

#126

Post by serve_yay »

taeric wrote: post #124
serve_yay wrote: post #94

Earlier quoted context omitted.

My phraseology was wrong, apologies. Yes that is what I was doing. You can probably tell that my default attitude towards git is one of confusion and frustration, this is no different

No worries. I can not claim that it is a simple problem to just immediately understand. Worse, I am not good enough in my understanding, to explain in a message forum. :( I can say that it is easy, once you understand it more. It will take some time. Countering that point, though; if you have a codebase that is rapidly changing at all times... there really isn't anything git can do to help.

Well, the problem for me is what I perceive to be the discrepancy between how rebase is supposed to work, and what it actually does when I use it. I would like to think I understand it but I guess you could argue I don't. At any rate I'm not really learning about it, I just don't do it anymore because I kept getting burnt by it.

My teammates have suggested to simply merge master into the branch so I do that now. It adds a commit to the branch, but Github is smart enough not to litter up the PR diff with the merge commit.

Our codebase doesn't change that much, every commit to master has to go through a PR and get approved. So fortunately we don't have to contend with that.

Re: A better pull request

#128

Post by kannonboy »

azakai wrote: post #117

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

From my experience, Github does attempt a merge commit behind the scenes and indicates that a PR can't be merged via the UI if there are conflicts. However, it still just shows the diff from the merge-base to the tip of your feature branch, which won't include any changes that have been added to master since the branch point.

Re: A better pull request

#129

Post by taeric »

serve_yay wrote: post #126
taeric wrote: post #124

Earlier quoted context omitted.

No worries. I can not claim that it is a simple problem to just immediately understand. Worse, I am not good enough in my understanding, to explain in a message forum. :( I can say that it is easy, once you understand it more. It will take some time. Countering that point, though; if you have a codebase that is rapidly changing at all times... there really isn't anything git can do to help.

Well, the problem for me is what I perceive to be the discrepancy between how rebase is supposed to work, and what it actually does when I use it. I would like to think I understand it but I guess you could argue I don't. At any rate I'm not really learning about it, I just don't do it anymore because I kept getting burnt by it. My teammates have suggested to simply merge master into the branch so I do that now. It a…

Only thing I can say is that rebase is exactly the same as reseting to the merge base, then cherry picking each individual commit that was lost in the reset. This means if you did 10 commits locally, it may stop 10 times to have you fix things. Versus a merge, which just does a single commit.

That said, I will also say that any worries about having merge commits in the history should largely be overcome. They actually provide useful information and are easy to ignore if you want.

Re: A better pull request

#130

Post by kannonboy »

Cub3 wrote: post #127

Forgive my ignorance but wouldn't rebasing your current branch from master before opening a pull request solve this issue?

That would solve the issue until master progresses again. The problem is that on many projects the master branch will progress during the lifetime of a pull request.
Post reply on HN