[chadnickbok]

  The process might seem more complex initially but think
  of it like this: If you add a new member to your team, 
  they would have to fork the repositories on GitHub, clone 
  them locally, make the changes, push to their own fork 
  and then create the pull request

Annndddd we're done - its easy to make a pull request from a branch; this person has no idea what they're doing.

In addition, the new GitHub code review tools address most (if not all) of the stated reasons for this switch. And in my opinion, GitHub's ease-of-use, alongside it being an incredible single point of reference, far outweigh any clunky other tools I've used (like Gerrit).

[jeremiep]

I had the same impression reading the intro; I was done after reading about Agile and consultants. In every single instance I've seen these two combined, mediocrity followed. Even in the cases where they thought they had agility the results were still terrible and unproductive.

Most of the time its people not understanding the tech they're trying to use and instead of spending the time to learn it they look for something they already know how to use or they'll pay someone to do the thinking for them which usually overlooks most of the company's context. I know I'm grossly generalizing but that's the trend I've seen so far.

They'll bash on Git for not being enough like SVN, bash on GitHub/GitLab for not having the same workflow of the previous tool. But will happily pay $200 an hour for someone to tell them what to use/do even if they end up making terrible decisions.

[sopooneo]

A thought just come to my head... For a lot of dev departments at non-tech companies, might consistent mediocrity be an improvement? If management is used to disaster at every turn, and then they hire some consultants, and then things are just lousy all the time, might that not count as a legit win for the consultants?

[jeremiep]

That's what I meant by "overlooking the company's context".

I think the case you describe is where consultants can be a net win, for the very reason you mentioned: dev departments at non-tech companies. These companies are usually happy with "its quirky but works" software since it gets the job done and allows them to focus on their core skills. There's nothing wrong in not having programming as your core expertise.

What I was describing is my experience seeing consultants and Agile brought in at companies where software development is their main area of expertise.

[sickbeard]

I've used gerrit and it's much better than github/bitbucket. My knock on gerrit is it requires one "very good" git person to be on the team however it makes it very easy to support a larger team and do cleaner code reviews.

[joncrocks]

https://xkcd.com/1597/

[ams6110]

:)

Exactly how everyone I know uses git.

[_jb]

This is not the only argument in this piece — I'd even argue that it's a minor one. It hardly makes sense to discredit the author and this article based on this GitHub misconception.

[VLM]

The free floating anxiety and dislike of the article is a symptom of an architectural/mgmt mistake in the article.

OK so there's a new long complicated extremely labor intensive elaborate detailed process. "Surely there had to be a better alternative?" Yes, yes there is. Unfortunately there are many options.

Now the correct answer would have been simplicate and add lightness. Agile manifesto "Individuals and interactions over processes and tools".

Instead, they found an overwhelmingly clunky and complex (their words not mine) tool to automate the complexity, or at least temporarily abstract it away, or at the very least replace one pile of complexity with another (larger?) pile of complexity.

Lets try a less controversial topic. Getting a pencil. All workplaces have different policies for office supplies. Order your own just like you buy your own clothes. Here's your annual office max gift certificate buy whatever you want. Here's a key to a supply closet. But here, we implemented a 15 page process involving teams of employees reviewing and documenting each individual request for a pencil in meetings. That's the bad news. The good news, is we replaced the original 15 page process with a 5 page process by installing an IBM mainframe, DB2, CICS, and writing a simple COBOL app that allows end users with newly installed 3270 terminals to request a pencil, and now we're better off than "ever before". Now most people would have handed out GCs, given out supply closet keys, or just trusted the employees, so you're going to get all kinds of semi-off topic blowback about how the COBOL program should have been the flavor of the month CRUD web JS framework, or instead of DB2 they really should have used nosql on the cloud so they can scale office supply request to all 100 employees not just a small team. But the real problem that everyone is squirming about is they're doin' it all wrong.

[chadnickbok]

My main point here is that on GitHub, making a pull request is super easy. There's even a cool pop-up if you visit the main page of a repo after pushing to a branch that asks if you'd like to make a pull request.

Saying that this is somehow more complex than updating a single commit and learning a whole new tool doesn't change that if you want to convince me, you at least need to correctly identify what's going wrong.

Perhaps if the author had specifically called out their perceived failings of the very latest GitHub pull request changes I'd have given the article more time. But unfortunately the justification given for switching was really shallow.

[ssmoot]

Github isn't exactly a utopia of UX.

Yesterday I was looking for a way to refresh an old fork with upstream. I'm pretty sure there was a button for this at one point. I looked. Couldn't find it. So instead I had to:

  $ cd ~/src
  $ mkdir github
  $ cd github
  $ git clone myfork
  $ cd myfork
  $ git remote add up upstream
  $ git pull up master
  $ git push origin master

Or something like that. I think I got lost somewhere along the way trying to checkout the upstream branch (is it "up/master" or "up master"? It depends) but it took 5-ish minutes.

Github may be pretty-ish, but I tend to avoid them these days. They're expensive, and they remove useful features. Fool me once, shame on you, fool me twice can't get fooled again.

[xenophonf]

It'd be nice if there were a way to automatically update a fork, including the issue tracker, wiki, releases, etc. The best I've come up with is a set of scripts that iterate over all branches of all forks, running `git checkout $branch; git merge --ff-only upstream/$branch; git push`:

https://gist.github.com/xenophonf/9df09e47a8629bb789ffbb94c7...

I suspect that I'm probably doing forks on GitHub wrong, or at least I'm trying to use them in ways not envisioned by GitHub. In some cases I want to maintain copies of a GitHub repository for archival purposes (e.g., I'm afraid that the developer or GitHub will revoke public access to the repo), while in other cases, I want to institute a kind of code review process prior to merging upstream commits (e.g., I'm afraid of upstream doing something malicious). I will occasionally create branches in my forks, fix something, and send pull requests upstream, but I never feel like I need to maintain those forks---I'll happily delete branches or delete and re-create forks as needed.

[quicklyfrozen]

You can create a PR from the upstream to your repo, then accept that PR. (I know, that's not immediately intuitive, but at least you can do it without pulling a local copy.)

[yxlx]

I tried that once but ended up with a merge-commit with my name on it in the history of my "fork". Is it possible to not end up with such merge-commits?

[quicklyfrozen]

I don't think so -- you'll need to do something like a git rebase, and there's no way to do that via the GitHub UI.

I know many don't like the 'dirty' history, but I like knowing exactly how the updates made it into my repo.

[quantum_nerd]

nice reference to President Bush there at the end :) but I do agree, merging locally(when there are a ton of diffs/merge conflicts that I had to sift through) is still a cumbersome process.

[chadnickbok]

That's really great point, and something I'd love GitHub to put some more time into.

But it's not the argument made by the author :-/

[therealmarv]

I'm not a git expert but I've contributed to repos which refused to merge the github pull request to keep their history clean. I mean, seriously?! So I don't know what is better...

[stepanhruda]

Github just added a way to squash pull requests to a clean commit last week, so there's that

[Touche]

I've never understood why people think omitting a historical event keeps their "history clean".

[masklinn]

Because I've yet to find a git graphlog tool which made viewing pretty nonlinear git history (as precise a historical record as they are) anything but a pain in the ass, some of them barely even manage to display a dozen concurrent "branches".

This is combined with most of the "historical record" really being worthless garbage: does it matter that you had to implement 12 fixups at various points and rewrite the whole feature thrice after requirements changed? Probably not. Does it need to be enshrined in the project's commit history? Absolutely not.

[marssaxman]

I've yet to find a situation in which I cared even a little bit about the prettiness of a git history. I am having trouble thinking of more than a couple situations, ever, where I cared about the contents of a git history, at all!

I imagine that people must be doing something involving git history which I simply don't have reason to do, or this "make your history pretty by rebasing" meme wouldn't keep floating around, but I really can't imagine what that activity might be.

[u801e]

> I've yet to find a situation in which I cared even a little bit about the prettiness of a git history. I am having trouble thinking of more than a couple situations, ever, where I cared about the contents of a git history, at all!

For me, it's the ability to use git blame and determine which commit was responsible for a line of code and read the commit message about why it was added.

If you don't keep a clean commit history, you end up with a commit message like "fixing some issues based on comments" which affects at least 30% of the lines of code in the file. If I'm looking at that file 6 months after the fact, that commit message gives me no information about why those lines were added/changed.

With a clean history, you can use the same command and see the exact reason why a line of code was added through the commit message that added/changed it.

[caoilte]

Blame is occasionally useful, but for me more than half the time the file gets moved somewhere else or the indentation changes as part of some other change so you lose all context about the original commit.

The code is the thing for me. And the less of it, the better.

[gknoy]

The argument made to me by a coworker (for why we should squish + rebase all PRs before merging) was that it makes it easier to use `git bisect` -- which is basically a binary search for Where a Bug was Added.

In practice, I've never done this. I think it's that I work on a smaller codebase, or that I am 1/3 to 1/2 of the developers, and so it nearly always has seemed easier to read the code + tests, and poke at values in a debugger, than to use binary bug search. If I were on a larger team, or a larger project, `git bisect` might be more useful.

[Touche]

What's the issue with merge commits and git bisect?

[daigoba66]

I think, based reading comments and articles from various sources, it's all because of GitHub pull requests. A lot of people seem to rather a pull request be represented as a single commit.

But I'm in your camp: I work with teams using git (and GitHub as a central repository), and a non-linear history has literally never been an issue. Even ugly graphs 7-10 histories wide aren't an issue. We also don't do pull requests (because we would we?).

We don't have a hard time with code reviews just using GitHub's commit history or even Gitk. In fact merge-commits often sometimes useful as markers of when the developer integrated his/her changes.

Admittedly, I'll occasionally do a rebase of upstream changes before I push if I know the change I made was small an isolated - but I certainly don't encourage other developers to do it.

[Touche]

I sort of feel the same way. The whole "prettiness" thing seems like a bit of a fetishism more than about productivity. Sort of like how people fetishize "inbox zero" (but in that case I do see the productivity gain).

I want my git history to be like my server logs, verbose. I can use tooling to reduce the noise and find what I need.

[Karunamon]

does it matter that you had to implement 12 fixups at various points

If you want to come back later during a git bisect and find out exactly when that bug that just took down your production application was introduced, then yes, absolutely. I'd rather look through 12 small commits than one monster one for that use case.

Look at it this way - a bisect cuts the search space in half with each progression, so you can double the number of commits being searched with the relatively minor cost of adding one more call to bisect when bughunting.

If you're tagging your milestones appropriately and otherwise practicing good repo hygiene, having n number of extra commits for any value of n is a feature, not a bug.

[Touche]

> Because I've yet to find a git graphlog tool which made viewing pretty nonlinear git history (as precise a historical record as they are) anything but a pain in the ass, some of them barely even manage to display a dozen concurrent "branches".

I'm not following this at all... what is it you need from this tool and why?

> Does it matter that you had to implement 12 fixups at various points and rewrite the whole feature thrice after requirements changed? Probably not.

Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made. And having many small commits rather than 1 massive one makes it much easier to revert bad commits.

[HolyHaddock]

> Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made.

This is interesting - even places I've worked that have cared about commit messages have been pretty happy with the entirely content-free "Fixes from code review."

Do you summarise code review discussions in the commit messages?

[Touche]

Yes, I do, I try to treat each commit like something that can be read in isolation. But nevertheless, the merge commit will have (if using GitHub) a reference to the pull request where you can see the discussion, which is valuable imo.

[camwest]

Check out http://gitup.co

[jasonlotito]

If you don't understand, then clearly you should investigate why as you cannot form an opinion on something you don't understand.

[Touche]

I have investigated, why are you assuming I have not?

[jasonlotito]

Clearly not enough, because you don't understand. You literally said that. How can you pass a judgement on something you don't understand?

[Touche]

Who said I'm passing judgment? I a lot of people prefer that workflow so I'm guessing there is some merit. I just don't understand it (I've never gotten an explanation that satisfies me).

[StavrosK]

What's wrong about what he said? Which step can you omit?

[arjie]

It needs the context. I've quoted the whole thing below:

> If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request. With Gerrit, you could clone the main repository, do your change and then push it directly to the same remote as you cloned it from.

The objection would be that you can always push to a branch and issue a PR from there in GitHub too. Those steps are identical for both tools in a professional setting.

There are reasons for Gerrit but this isn't one.

[chadnickbok]

Exactly, thanks. My reason for saying I'm done is that, if you haven't yet discovered that GitHub makes it really easy to make a pull request, you're probably not the right person to be criticizing it and proposing a new flow.

[masklinn]

You don't need to fork the repository or push to your own fork (if you have write access to the original obviously, but gerrit seems to assume that), intra-repository pull requests are perfectly well supported.

You do need to create the pull request, but that's no different than pushing to a special magical ref.

[stepanhruda]

Forking the repo

[kevinmgranger]

It's not that any of those steps can be omitted, it's that those steps overall are not difficult or complex.

[StavrosK]

Sure, but the author literally says "pushing to a special branch might seem more complex, but consider X." Those steps are more complex than pushing to a special branch.

[marssaxman]

Just last night I decided not to bother submitting a (tiny, one-line) patch to an open-source project because I didn't feel like going through all that rigmarole. The steps may not seem difficult or complex but they are steps, and they are friction, and eliminating friction is generally a good thing.

[bradyholt]

This is a pattern I've seen in teams to enforce review of code before it's merged. You can make the main repo read-only for most of the team and require PRs be submitted from their own forks. Then, someone with write access on main repo can review and merge the PR. I think this is overkill, personally, but just want to point out that maybe this team was employing this process, rather than them not knowing how to create PRs from a branch.

[chadnickbok]

Sure thing - but that's a more complicated flow brought on by something other than GitHub.

[aeorgnoieang]

Does the new GitHub code review tool handle rebased commits like Gerrit does via "patch sets"? That seems like it would be really useful.

[xintron]

I know they've talked about implement something similar. Since the Open letter to GitHub a lot have changed and I wouldn't be surprised to see GitHub support most of what Gerrit has (and more) in a near future.

[TheSwordsman]

> Annndddd we're done

I stopped reading exactly there, I knew that something was amiss. We followed that workflow at my last job, it worked well.

[jedberg]

Heh, I literally had the same quote in buffer and was coming to make the same comment. Clearly they don't know how GitHub works.

[cname]

Am I missing something? What the article describes seems to be the most common way people use GitHub with a git flow branching style. Is the contention just over the "would _have_ to" part? I think it's likely the author knows that GitHub doesn't _require_ this. And even if not, it doesn't seem pertinent. Doing a PR from a branch of [a clone of] the main repo would require basically the same steps.