51–60 of 271 posts
Gerrit still produces merge commits unless they have it configured to cherry-pick onto master, which is insane because you are changing the commit sha at that point.
Not sure why this is "insane."
What is the better alternative Go is using? "Can only view diffs on a single page" You don't need to use GitHub to view diffs. "To create a patch one must fork the repository publicly (weird and unnecessary)." I don't think it's weird. "Accepting a patch creates a "merge commit" (ugly repo history)." You don't need to have a merge commit, although I don't think that creates an ugly repo history. "In general, pull req…
They're probably using Gerrit. Although I agree, I don't think merge commits are ugly. I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way. In fact I find lots of developers just have an obsession with "clean" history, and fetishes for particular tools. It baffles me.
This has absolutely nothing to do with those, especially since they didn't even allow cleaning up histories. There is one very simple reason for why some developers prefer a linear history of master:
It makes debugging very easy.
With branch merges, especially when the branch lines cross, or the merge is an octopus merge, the complexity of the code necessitating inspection to find the root cause of a bug straight-up explodes. Meanwhile with a linear history it's not only easy, but automatable to find a commit that breaks a thing.
I do realize that you may not have had the displeasure yet to be in the situation to learn these things. Please feel free to consider yourself fortunate, but please also do try to understand that the things i just wrote are in fact simple observation of realities.
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…
I have no idea what they specifically mean, but I can tell you, that the github requirement of pr to come from public repositories on github is something that bothers me occasionally. 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 but do want to contribute to a repo hosted there. This is a distributed version control system we are talking about after all.
As for their claim about pull request culture, again I'm not sure what they specifically mean, but I find the github code review tools to be very rudimentary and suspect that lots of other people with experience with more sophisticated code review workflows feel the same way. Github is a great service for some things but it certainly is not centrally about code review.
> Better bindings for calling Go from Java. If that is available for general Java code (i.e. uses JNI) and not just for Android, that could be really huge for Go. Writing performance-sensitive low-level code in Java is still fairly painful, wheras Go still isn't great for writing big programs. I can imagine (for example) Hadoop, Lucene/Elasticsearch and PrestoDB all using this.
You jest? Go is GC'd just like JVM. The only possible benefit -- even if Go catches up at runtime -- is the compact form of memory objects in Go vs Java object. But then again, if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land.
All this can be done with JNI, but JNI is so un-fun that I can see Go making big inroads here.
Gerrit still produces merge commits unless they have it configured to cherry-pick onto master, which is insane because you are changing the commit sha at that point.
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."
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 patch c depends on b, which depends on a. Now say that patch c requires a change that merged into master. Because you can't merge into your development branch, you have to rebase c AND b AND a. This really pissed of the owners of b and a because it shows up as a new changset and wipes out votes. God forbid you depend on two different patches that each have separate dependencies.
You can use the merge commit to add the review information if you want. Then you don't have to molest the code change commit.
Earlier quoted context omitted.
> "Run-time support and type information", why is it linked into a an executable that never allocates memory and does no introspection of any kind? fmt.Print does use reflection. Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something. We do recognise that Go binaries can and should be smaller, but probably not as small as you might hope.…
> Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something. It is not about the size of hello world executable, that is just a symptom. A code smell if you like. There is something badly broken in the dead code (or dead data) elimination area. And I hope that code is in fact dead, because if it is not, add code generation to the list of sme…
It doesn't print just strings. It can print anything. http://golang.org/src/fmt/print.go?s=6420:6467#L221
After doing your research, you're welcome to submit a magical CL and PR that brings down the binary sizes, then you won't need to argue anymore.
Earlier quoted context omitted.
They're probably using Gerrit. Although I agree, I don't think merge commits are ugly. I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way. In fact I find lots of developers just have an obsession with "clean" history, and fetishes for particular tools. It baffles me.
> I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way. This has absolutely nothing to do with those, especially since they didn't even allow cleaning up histories. There is one very simple reason for why some developers prefer a linear history of master: It makes debugging very easy. With branch merges, especially when the branch lines cross, or the merge i…
> Better bindings for calling Go from Java. If that is available for general Java code (i.e. uses JNI) and not just for Android, that could be really huge for Go. Writing performance-sensitive low-level code in Java is still fairly painful, wheras Go still isn't great for writing big programs. I can imagine (for example) Hadoop, Lucene/Elasticsearch and PrestoDB all using this.
You jest? Go is GC'd just like JVM. The only possible benefit -- even if Go catches up at runtime -- is the compact form of memory objects in Go vs Java object. But then again, if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land.
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…
> What exactly is weird about that? I have no idea what they specifically mean, but I can tell you, that the github requirement of pr to come from public repositories on github is something that bothers me occasionally. 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 but do want to contribute to a repo hosted there. This is a distributed version co…
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 allEarlier quoted context omitted.
You jest? Go is GC'd just like JVM. The only possible benefit -- even if Go catches up at runtime -- is the compact form of memory objects in Go vs Java object. But then again, if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land.
> 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.
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.