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.
[deleted]
A better pull request
91–100 of 167 posts
Re: A better pull request
#92Earlier quoted context omitted.
If you rebased master into the feature branch, then what you said makes sense. I realize it may look like semantics, but you rebase your feature branch onto the master branch. This means something completely different. I am curious what you use as an alternative.
Huh. If I rebase master into the feature branch, isn't that supposed to move the point at which the feature branched off of master from where it was, to the HEAD of master? About rebasing the feature branch onto master, my team doesn't do that, we squash the feature branch commits into one commit when merging to master. (I don't use anything besides git, but that doesn't mean I can't hate it)
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?
Re: A better pull request
#93Earlier quoted context omitted.
I think the integration with JIRA (which is arguably best-in-breed for moderately heavy-duty issue tracking) is quite a compelling argument for going with an all-Atlassian setup; you can even use their SourceTree product as a git GUI. On the other hand, GitHub's stuff generally does feel nicer to use and better and more thoughtfully UX'd.
Side note, but you can use SourceTree regardless, right? I assume it has some features that are paid (or only work with Bitbucket?), but I've found it brilliant for managing GH repos - one of the nicest free tools I use.
Nope, SourceTree is now 100% gratis. You still have to "register" it and apply a key after 30 days, but this involves a simple signup form on a website.
Re: A better pull request
#94Earlier quoted context omitted.
Huh. If I rebase master into the feature branch, isn't that supposed to move the point at which the feature branched off of master from where it was, to the HEAD of master? About rebasing the feature branch onto master, my team doesn't do that, we squash the feature branch commits into one commit when merging to master. (I don't use anything besides git, but that doesn't mean I can't hate it)
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
Re: A better pull request
#95I'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 conflict; the merge conflict should happen and be resolved on the feature branch first.
Or what am I missing?
Re: A better pull request
#96Earlier 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.
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...…
It can depend highly on your needs. We have a small team but a large number of private repositories. Github basis prices on number of repositories, which makes them incredibly expensive for us. Bitbucket basis prices on team size, which made them cheap for us.
Re: A better pull request
#97Earlier quoted context omitted.
I disagree. It should be both. Specifically because what was tested and run by the person sending in the request was the diff to the master at the time the branch was created. Please let that sink in. Nobody ever tested the diff that this is going to be showing to the user.
But once you click the "Merge" button in GitHub, nobody has ever seen or tested the new state of master. I'd rather see the diff that's going to go into master (tested or not) than see a diff that effectively means nothing (as it will never be applied to anything).
If you use the Travis CI integration, it actually tests the result of merging a PR, rather than the branch being PRed. This seems to solve a lot of problems on projects with thorough testing.
Re: A better pull request
#98Earlier quoted context omitted.
But again, the age-old response to this flow is that it creates an untrue version history. This is great if cleanliness is your exclusive priority, but if you find that you need to actually try to jump into the mind of the person who made the commit (especially if it's someone you've never met and with whose habits you aren't familiar), it's impossible to actually follow along and recreate what really happened. The r…
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 tradeoff.
Re: A better pull request
#99Earlier quoted context omitted.
However, if per convention you state that a branch going under review must always be rebased to the latest commit of [your main branch], you will be reviewing all at once the code that will effectively be merged (by a simple fast-forward), and the code that the requester tested. It seems to me that this is the safest method as, when you add an automated testing tool to the mix, it's pretty much guaranteed that you ca…
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.
Re: A better pull request
#100Seems 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/
I use both. I find Bitbucket just lacks polish— it's hard to come up with specific examples, but various things give off the vibe of it being maintained by a small team within a larger organization for whom it's not really a priority.
Code search is one, but I also find it harder to get to the exact diff or pull request that I want. I don't get Github's nice rendering of filetypes like STLs, and there's a lot less of the context-sensitive popups when you're mentioning users, issues, commits, etc.
Bitbucket's issue tracker is kind of limited from ever getting too good, because it's really just there as a teaser for JIRA.