I'm sorry, but the Go Gopher's eyes[1] will always remind me of boobs. [1]: https://talks.golang.org/2015/state-of-go.slide#21
This probably reveals more about you than anything else.
The State of Go
71–80 of 271 posts
Re: The State of Go
#72Earlier quoted context omitted.
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?
I think the point he tried to make was that if only "hello world" produces a 1.3 megabytes executable, the file size of a fairly complicated program made in Go will be significantly larger than the same program implemented in another language.
That's not a reasoned point then.
Re: The State of Go
#73> Now running Linux, FreeBSD, OpenBSD, and Plan 9 builders on Google Compute Engine. (OS X, Windows coming soon.) What purpose does putting work into Plan 9 support serve other than wastefully gratifying Rob Pike? Most Googlers I've spoken to despise this guy's reactionary lordship over the project, and seeing stuff like this lends evidence to the idea of it being a North Korean situation.
> Most Googlers I've spoken to despise this guy's reactionary lordship over the project Wat‽ Talk to more of us. From where I sit (ie. not related in any way, just an observer who happens to be a Googler) the go team is fantastic.
That's really nice of you to say. Thank you.
Re: The State of Go
#74Earlier 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
The simplest reason is if what I was contributing was done on my employers time and they have strict IP restrictions. It is much, much easier to vet a single changeset than it is to a) verify a whole repo history and b) coordinate around my public/private github identities.
I was hoping for more reasons, since the very first and simple one is usually the one that has the most and simplest workarounds. You could for example make a patch with git on your local machine and attach that to an issue.
Re: The State of Go
#75Personal opinion here, but I much prefer merge commits as opposed to fast forwarded commits. With a merge commit, there's one commit to revoke if something breaks, and there's one commit per PR to step through with git bisect, and more importantly it maintains history, which to my eyes is more useful than a "pretty" repository.
Drafting comments... if you want to draft comments, can't you do that in a separate editor? Better than relying on the browser as an editor.
I agree, though, the public repository requirement for making a PR is a bit awkward.
Re: The State of Go
#76Edit: 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…
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).
Re: The State of Go
#77I'm sorry, but the Go Gopher's eyes[1] will always remind me of boobs. [1]: https://talks.golang.org/2015/state-of-go.slide#21
MFW I read this:
http://makeitthentelleverybody.com/wp-content/uploads/2014/0...
Re: The State of Go
#78Edit: 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…
Yes! I've been wanting to do this and didn't know it was this easy.
Re: The State of Go
#79Earlier quoted context omitted.
That's exactly what we do, and we need to change the commit hash because we want to include the review information in the commit message. Not sure why this is "insane."
It's essentially rewriting history. As a contributor it's nice to know a commit went in exactly as you wrote it, which is not the case when the commit hash changes. Git is powerful because it was written with the ability to merge trees. The cherry pick workflow is throwing all of that in the trash. Why not use SVN at that point? Because of cherry picking in Gerrit, dependent patches are a nightmare to maintain. Say p…
One nice thing about Git is it lets you choose your workflow.
Our general workflow for the Go project is to review single commits, and sometimes do major new work in feature branches. When we submit a single change we cherry-pick. When we merge trees, we create a merge commit.
We don't write commits that depend on other pending work. That's overly complicated (IMO) even if you always use merge commits.
Re: The State of Go
#80> In general, pull request culture is not about code review. This is not true. There are many projects on GitHub which do extensive code reviews on pull requests. It may not be as nice as Gerrit for the type of project like Go (where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient (and arguably more efficient than Gerrit).
> where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient GitHub is painful for non-trivial reviews. Biggest WTFs: - No comment threading (or at least collapsing). On a PR with 100 comments[1] it is unlikely that those revisiting the thread need to see (and download, and render...) the first bazillion comments. - Source "annotations" are lost…
Wait. Force pushes? That's a terrible habit to get into; force pushes have decimated more than a few a open source project's repository.