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

81–90 of 167 posts

Re: A better pull request

#81

Post by rdtsc »

puls wrote: post #18

This is so telling: GitHub had a blog post yesterday[1] about pull requests and now Atlassian does today with a very similar title. The one from GitHub was about social dynamics and how to work together better, while the one from Atlassian is about technical minutiae. Having used both GitHub and Stash, the difference in focus between the two companies comes across plainly, and these two blog posts only back it up. [1…

> The one from GitHub was about social dynamics and how to work together better, while the one from Atlassian is about technical minutiae.

What is it telling us of? Are you implying something to the effect of Atlassian doesn't care about people working together (heck, maybe they hate humans, who knows) and Github loves community...?

Re: A better pull request

#82

Post by z-e-r-o »

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?

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.

Re: A better pull request

#83

Post by taeric »

mkozlows wrote: post #69
taeric wrote: post #66

Earlier 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.

Yes, but this is the diff that is going to happen if it's merged, so it's what reviewers should be looking at.

I disagree still. Fundamentally, I agree that it is important. I'd go further and say that these two diffs should be similar. If they are dissimilar, then there should be a red flag.

Re: A better pull request

#84

Post by alexsop2 »

jbrooksuk wrote: post #5
Revell wrote: post #4

Earlier quoted context omitted.

But still the test would only fail after the merge, whereas you'd want to catch this before.

On GitHub you can have tests run before you've merged, so you know whether it's safe or not.

I'm guessing this is because a merge commit is created before the merge is fully executed.

Re: A better pull request

#85

Post by natrius »

rubiquity wrote: post #76
efuquen wrote: post #68

Earlier quoted context omitted.

That does not solve what I consider the biggest problem, the clean merge that actually results in a logical bug. Without being able to review the diff between the tip of master that will happen with your solution regardless. EDIT : currently I always rebase our feature branches before submitting the PR to try and mitigate this and make sure review happens quickly after that. it doesn't fully solve the problem but it'…

> EDIT: currently I always rebase our feature branches before submitting the PR to try and mitigate this and make sure review happens quickly after that. it doesn't fully solve the problem but it's the best flow I've found. I rebase after the PR has been discussed and "approved" for merging. I feel having the individual commits during discussion time are useful for context, so long as team members are earnest enough…

You can rebase without squashing to get the benefits of both approaches.

Re: A better pull request

#86

Post by serve_yay »

taeric wrote: post #57
serve_yay wrote: post #42

Earlier quoted context omitted.

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.

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)

Re: A better pull request

#87

Post by stevebot »

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.

Re: A better pull request

#89

Post by erikb »

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 in detail and are able to rebase -i anything that looks bad?

Re: A better pull request

#90

Post by SoftwareMaven »

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.

Post reply on HN