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

51–60 of 167 posts

Re: A better pull request

#51

Post by fenomas »

bshimmin wrote: post #34
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.

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.

Re: A better pull request

#52

Post by AceJohnny2 »

jackweirdy wrote: post #48
baldfat wrote: post #44

Earlier quoted context omitted.

Personal use = BitBucket WHY? Free private repos unlimited in number of repos only limited on how many can access them. So all my .config files and anything private goes to BitBucket. Great product for my own use.

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?

Cloud access? I have a similar problem where my various machines are behind NATs/firewall (personal computer, workstation...). It could just be more convenient to put it in the cloud rather than have to poke port forwarding or VPN rules between the machines.

Re: A better pull request

#53

Post by Kimitri »

jackweirdy wrote: post #48
baldfat wrote: post #44

Earlier quoted context omitted.

Personal use = BitBucket WHY? Free private repos unlimited in number of repos only limited on how many can access them. So all my .config files and anything private goes to BitBucket. Great product for my own use.

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?

Well, there's the obvious benefit of tracking changes and it also provides a nice way to sync files selectively between computers.

Re: A better pull request

#54

Post by wzsddtc »

jackweirdy wrote: post #48
baldfat wrote: post #44

Earlier quoted context omitted.

Personal use = BitBucket WHY? Free private repos unlimited in number of repos only limited on how many can access them. So all my .config files and anything private goes to BitBucket. Great product for my own use.

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?

The benefit that you don't need a git server and can have the code running on different machines! :)

Re: A better pull request

#55

Post by raziel2p »

toong wrote: post #21
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/

What about in-repo code search ? https://bitbucket.org/site/master/issue/2874/ability-to-sear...

I find that the search results from Github are often useless - sorting by relevance is hard in terms of code, I suppose.

Re: A better pull request

#56

Post by pXMzR2A »

stephenr wrote: post #43
Dirlewanger wrote: post #29

Earlier quoted context omitted.

You'd think more start-ups/mid-size ones would use Bitbucket since they have free private repos. I'm guessing the social allure of Github and its superior repo/pull request UI is what trumps Bitbucket to that end.

I'm pretty sure it's wanting to be one of the 'cool kids' that pulls people to GitHub. If your decision about where to host your code repos is decided by how pretty the webpage to create pull-requests is, the wrong people are making decisions such in your business.

> decided by how pretty the webpage to create pull-requests is

i.e. whether the gui is well designed.

Re: A better pull request

#57

Post by taeric »

serve_yay wrote: post #42
legomaster wrote: post #37

Earlier quoted context omitted.

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.

I don't know what it is, but when I try to rebase master into the feature branch, my PR diff ends up littered with commits that aren't part of the PR. Then my reviewers have to wade through a bunch of irrelevant crap to see my changes. I thought the whole point of rebasing was so that wouldn't happen. Anyway, now I just don't do it anymore. Git is a pain in the ass.

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.

Re: A better pull request

#58

Post by wickchuck »

jackweirdy wrote: post #48
baldfat wrote: post #44

Earlier quoted context omitted.

Personal use = BitBucket WHY? Free private repos unlimited in number of repos only limited on how many can access them. So all my .config files and anything private goes to BitBucket. Great product for my own use.

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?

Having an upstream can be useful for CI testing and for deployments with tools like Capistrano. Plus it allows you to pull down your code from other environments if needed and acts as a additional backup, so there are potentially lots of reasons to have one.

Re: A better pull request

#59

Post by kannonboy »

bhuga wrote: post #50

Wouldn't this result in an ever-growing diff? You'd see everything that's gone into master since the branch last rebased/merged master as "changed". When I think about a branch, I want to see changes unique to it, not what's going on in the rest of the codebase. Showing merge conflicts inline like that is pretty cool, though.

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.

Re: A better pull request

#60

Post by b6fan »

I think both the old and new diff worth a look. Maybe showing them using different colors is a good idea.

Phabricator uses light colors to show changes not introduced in this patch but a rebase against master [1]. The experience is pretty good if the workflow is to always fast-forward and the patch author does rebase. Changes introduced by other people are in light green and red. Duplicated-line issue can be obviously seen.

[1]: https://secure.phabricator.com/book/phabricator/article/diff...

Post reply on HN