111–120 of 271 posts
Earlier quoted context omitted.
This makes me laugh, considering at Google we regularly deploy statically linked C++ programs that are two orders of magnitude larger. "You call that a big binary? THIS..." etc
From what I hear you have the funds and resources to operate at that scale.
My point is, on typical machines today, even a 10mb binary is not an issue at all.
Edit: This commit was written to the original submission: https://talks.golang.org/2015/state-of-go.slide#7 -------------- It seems like these people simply don't understand Github very well. Can only view diffs on a single page (can be very slow). Cannot compare differences between patch sets. Accepting a patch creates a "merge commit" (ugly repo history). Don't use the merge button, just add the requester's repo as…
Don't use the merge button, just This is the smell of git plumbing again. Don't use the obvious UX that's been presented to you, do some other workflow that doesn't appear in the documentation.
(But I am entirely sympathetic to the opinion that git itself exposes too much plumbing and has a pretty baroque end-user interface for doing certain things. And it's also certainly legit to wish or suggest that _github_'s UI worked differently than it does, although the merge commits don't really bother me, and some people prefer them, it's a point of some contention).
Edit: This commit was written to the original submission: https://talks.golang.org/2015/state-of-go.slide#7 -------------- It seems like these people simply don't understand Github very well. Can only view diffs on a single page (can be very slow). Cannot compare differences between patch sets. Accepting a patch creates a "merge commit" (ugly repo history). Don't use the merge button, just add the requester's repo as…
> Don't use the merge button, just add the requester's repo as a remote to yours Actually, you don't need to do that. GitHub provides a special pulls remote "namespace" on the upstream repo, so you can add it as a fetch pattern to your .git/config like so: [remote "upstream"] url = https://github.com/neovim/neovim.git fetch = +refs/heads/*:refs/remotes/upstream/* fetch = +refs/pull/*/head:refs/pull/upstream/* Then wh…
Earlier quoted context omitted.
Honest curiosity here. Given that there's nothing stopping you from deleting your fork after the PR is done, what reasons can you name for this: There are lots of reasons why I may not want my github fork to be public or I don't want to have a github fork at all
If PRs were a instantaneous thing, I don't think it would be a problem. However, if you've ever looked at a network graph of a repo that requires rigorous code review or doesn't have a diligent maintainer, some of those forks can sit in limbo for a really long time. And, as more pull requests pile up, it's very difficult as a user to figure out which version I should be using for my code to run correctly. I just ran…
I've rarely had trouble with assuming master (or ideally a tagged release) on the original repo (not a fork) is the one I should be using. Assume all forks are forks.
In any cases where this hasn't been true, it's been clear to me the blame is due to poor release management (or poor communication of release management, which is the same thing), rather than somehow the fault of github's PR or forking system. Although you can hypothetically argue that certain UI's encourage poor release management and others support it, I personally have not seen this to be an issue in github's UI.
Earlier quoted context omitted.
> GitHub is painful for non-trivial reviews. That may very well be the case. But note how you said for non-tivial reviews , whereas in the presentation about go they said in general (see the line I quoted in my original comment). And argue that the vast majority of pull requests on GitHub are simple ones which don't need much discussion, so in general the GitHub UI works just fine. I don't have any hard numbers to ba…
> And argue that the vast majority of pull requests on GitHub are simple ones which don't need much discussion, so in general the GitHub UI works just fine. Right. And what you say validates my exact point: "pull request culture is not about code review." If all you want to do is cast your eye over it and click "merge", it works great. That's not how we work, though.
Earlier quoted context omitted.
> if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land. I don't think that's necessarily true. Go does a much better job than Java at letting you manage your allocations and re-use memory. You can write tight, performance-critical code in Go without resorting to 'unsafe'; it just requires care, as it does in any language.
I don't know if I completely agree with this. To write truly performance-critical Go, you end up throwing away many of the language's qualities. Channels are slow, defers add overhead, interfaces add overhead (e.g. I2T), etc. Don't get me wrong, I like Go, but in my (and others I work with) experience, it's not the right choice for performance-critical systems.
(That's not me, to be clear.)
We all like Go. Just wish we could discuss these matters without unduly raising temperatures. "It's just code".
Earlier quoted context omitted.
> And argue that the vast majority of pull requests on GitHub are simple ones which don't need much discussion, so in general the GitHub UI works just fine. Right. And what you say validates my exact point: "pull request culture is not about code review." If all you want to do is cast your eye over it and click "merge", it works great. That's not how we work, though.
If you said "GitHub pull requests don't fit our culture" or "The GitHub pull request UI is insufficient for our needs" then it'd accept that. Both are perfectly valid reasons for preferring Gerrit. But placing this blanket statement about the whole "pull request culture" is just wrong.
Earlier quoted context omitted.
Just out of curiosity, have you ever used a tool such as Gerrit or Atlassian Stash? There are different mindsets, and both have their advantages.
I must admit i have not, and to make clear: I am not taking offense to their implication that Github is worse at some things than other tools (it is). My post above is merely objecting to the opinions that were borne out of some lack of knowledge (which is acceptable), yet are posited as facts (which is not).
Fwiw, of the six bullets, I see three which are clearly subjective, one which is a clear advantage of gerrit, and two which I don't really know enough about to refute.
When it comes down to build systems, I think it's very easy to spend a lot of time moving sideways or backwards - and if the tool you're moving to has deficiencies compared with what you had before, it can be very frustrating. Certainly, if the tool people want you to move to offers few advantages over your current infrastructure, a quick dismissal is reasonable.
Getting set up with their current contribution system might seem a little clunky, but I don't think it's particularly hard to do, and definitely seems like a 'run-once' thing. Once it's set up, it seems to integrate into a workflow well.
Their contributors will have their current workflows set up nicely - and unless github's issues system has compelling advantages, it's definitely not worth them switching due to the temporary loss in productivity.
Edit: This commit was written to the original submission: https://talks.golang.org/2015/state-of-go.slide#7 -------------- It seems like these people simply don't understand Github very well. Can only view diffs on a single page (can be very slow). Cannot compare differences between patch sets. Accepting a patch creates a "merge commit" (ugly repo history). Don't use the merge button, just add the requester's repo as…
> Where we're at in February 2015 Still producing 1.3M hello world executables. I wonder if rewriting the linker from C to Go will be primarily rewriting, or maybe they will start fixing it somehow.
Yeah, what an outrage this is. 1.3 megabytes. That's like $0.00004 USD worth of hard drive space. Does the go team think we are all rich or something?