"doing this in the terminal requires a crazy number of steps"
"Switching contexts from your browser into your terminal."
"you can simply make the change right there without leaving your browser, saving you time and maintaining your zen-like frame of mind"
Sending a pull request for a typo in someone else's project is way faster using the github web editor, no question, but for everything else?
I'm in a terminal or, most likely, my editor way more often than I'm in the browser and for any non-trivial change it's way faster to use git in the terminal or fugitive (vim-git integration) than the web interface.
Once you have to use the proprietary pull request functionality to send that change it changes the balance a bit but that's just saying that Github's vendor lock-in strategy that forces you to use the Github site makes it faster to use the Github site than both the site and the git command. Not a bragging point, just a reminder that I should be nervous about Github having gotten as far as "embrace" and "extend" in the microsoft playbook even though I really like Github.
"I'm in a terminal or, most likely, my editor way more often than I'm in the browser and for any non-trivial change it's way faster to use git in the terminal or fugitive (vim-git integration) than the web interface."
I've no doubt that this is true for you, but other users have very different situations.
I'm a front-end developer, which means that I live in the browser. For me, if it's just a simple change, I'd much rather do it from the browser than the terminal. This is despite the fact that I know the terminal pretty well (love tmux and tmuxinator, for example).
Oh yeah, I have no doubt that's true for a lot of people but as far as I know you folks are still a small minority.
Even when I'm doing CSS and I spend a lot of time in firebug/dev tools that's just for experimentation, the first step before interacting with git is still changing some file which I do in an editor. Although I also use a lot of "live preview triggered on save" type workflows rather than building stuff in the browser which I know is unusual (not for long I'm guessing).
We have some marketing people who want to make trivial updates to our site, but we don't want to give them write access to the entire repo.
We've given them read-only access so they can fork the repo, make edits and send us (engineering) pull requests. But the missing piece that keeps this from being useful is that they can't keep their fork up to date using github.com. The best they can do is delete the fork and fork again, which stinks.
Is the ability to pull new commits from the original repo into your fork actually missing from github.com, or are we missing it?
If you try to edit a file from a repo you can read, but not write-to, from the GitHub interface, it will fork the repo, make a branch for the edit, then send a PR from that branch. If you try this again in the future, you'll get a different branch.
It is possible to update a fork from the GitHub interface... you make a new pull request from the original tree to your fork, then accept that PR. If you just hit "Pull Request" when looking at your fork, you'll see a "reverse bases" link that will do this.
I'm surprised that GitHub hasn't made git remotes easier to manage. If you fork a repo, AFAIK you have to manually add remotes to keep up to date with the upstream repo. When you fork a repo, why don't they automatically add an "upstream" remote and support git pull/fetch from the web UI?
They should really make another branch before making any changes and then offer that branch up for the merge, once it gets merged they can delete the branch and fast-forward the master branch. The other options would simply be using a form of "git reset" or "git rebase" to clean up their branch.
They kinda do... make a new pull request on the GitHub website, pulling from upstream into your fork, then accept it. It works quite well, except for the extra merge commit.
I think there might be some confusion here. All I suggested was the git flow model[1] AKA forking, making your own branch, changing things, and making a pull request on that branch and if it gets merged, you delete the branch and fast-forward master.
I don't see why they can't pull in updates from the original repo. Are they not adding it as a remote?
"I don't see why they can't pull in updates from the original repo."
Because github doesn't provide a way to do that on the site. Git workflows that can be achieved entirely on github.com were that subject of the story, and my original comment.
Ah, I was a bit confused. GitHub's kind of in-between being a web-UI for git and simply a storage bin for git repos. If they wanted to add the functionality to pull (fetch and merge) they'd have to implement a lot more functionality to handle conflicts. Have you tried looking at the native GitHub clients? They might provide the functionality you're looking for.
I've already experienced some of this flow having experience grabbing pull requests from new developers. Typo fixes or simple one liners are dead simple to add in browser and not over command line.
I only worry this will encourage people new to git to copy paste files for changes into a fork on Github directly instead of cloning for big changes manually. We'll have to see how it plays out.
And why is forking encouraged? its one of my largest pet peeves with github, I cant just clone someones repo, make a patch in a branch and email / send it off, I need to fork the repo and make a pull request.
I dont like having to go to the effort and litter my repository list with repos I want to send a couple of line fixes too.
* Obviously I can, but its more hassle for the owner and less likely to be accepted
Well you answered your own question - it's slightly more convenient to you, but less convenient for the repo owner. That said, some projects certainly do all their patch/merge over email since before github existed (like Linux kernel dev) and have no plans to change that.
How is cloning a benefit over forking? Either way you end up with the repository littering your list.
I suppose if you clone you could immediately delete the clone after submitting the patch, but that seems premature. In both cases, you can delete the repo after the patch is applied, couldn't you?
Forking is a godsend for using patched versions of inactive user's repos.
In my case, an owner of a library was inactive. I noticed other users had fixed issues I was having, so I pointed my gem file at their repo temporarily until the owner of the root repo finally got back.
I look forward to the day when code reviewing a pull request with a significant number of commits across a significant number of files is possible for a human. The top/bottom diff format may be useful for machines, but it's terrible for understanding what actually changed. It'd also be nice if there was some facility for stepping through versions of a given file.
Most visual diff tools use side-by-side diffs. I will occasionally write code in a visual diff so I can compare my new fix with the old code when debugging.
Review Board (reviewboard.org) is a web-based code review tool that uses side-by-side diffs.
Git doesn't track directories directly, but you can create files in subdirectories. Go to <user>/<repo>/new/<branch> (or click the little "+" box where the path is displayed), and type "foo/bar" in the filename box.
This seems kind of silly. When would a person ever want to remove a file but not check that the changes didn't break anything?
In fact, as much as I like GitHub, using it entirely from the web interface seems a little dangerous in general. The only scenario where I see it being useful is for changes along the lines of fixing spelling mistakes. Everything else it's stupid not to test it before pushing...
"Switching contexts from your browser into your terminal."
"you can simply make the change right there without leaving your browser, saving you time and maintaining your zen-like frame of mind"
Sending a pull request for a typo in someone else's project is way faster using the github web editor, no question, but for everything else?
I'm in a terminal or, most likely, my editor way more often than I'm in the browser and for any non-trivial change it's way faster to use git in the terminal or fugitive (vim-git integration) than the web interface.
Once you have to use the proprietary pull request functionality to send that change it changes the balance a bit but that's just saying that Github's vendor lock-in strategy that forces you to use the Github site makes it faster to use the Github site than both the site and the git command. Not a bragging point, just a reminder that I should be nervous about Github having gotten as far as "embrace" and "extend" in the microsoft playbook even though I really like Github.
http://www.wired.com/wiredenterprise/2012/05/torvalds_github...
http://julien.danjou.info/blog/2013/rant-about-github-pull-r...