GitHub Flow in the Browser | Hacker News Reader

GitHub Flow in the Browser

github.com

117 pointsdavidboy36 comments

"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.

http://www.wired.com/wiredenterprise/2012/05/torvalds_github...

http://julien.danjou.info/blog/2013/rant-about-github-pull-r...

"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).

Github has a git wrapper that adds commands for their extra functionality. Pull requests can be done from the command line.

https://github.com/github/hub#git-pull-request

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?

Is there a way to give collaborators read-only access to a private GitHub repo?

I have some projects I'd love for others to see, but I don't want the code to be in public at this point.

Collaborators can have "Read", "Read/Write", or "Admin" privileges. You can choose after you add them.

I don't have that option. I can see that Teams have it, but as an individual with a private repo, I only have the input for entering the username.

https://help.github.com/articles/what-are-the-different-acce...

https://help.github.com/articles/how-do-i-add-a-collaborator

https://help.github.com/articles/how-do-i-set-up-a-team

Guess I have to set up a Team/Org, before I can manage permissions.

Whoops, my mistake. You get the option after you add them as a collaborator. I'll fix my comment above, too.

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.

Yes, they could work from a branch, but then we'd have to give them read-write to the repo. There's no per-branch access control.

Working on a branch in their fork doesn't help. They still can't pull in updates from the original repo.

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?

[1] http://nvie.com/posts/a-successful-git-branching-model/

"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.

They can update their branch in their own repo manually ("git pull upstream; git push origin" or equivalent on their development machines).

Still it'd be awesome if GitHub supported this via a Web interface.

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 jzelinskie's point is that if they make no changes on the main branch in their fork then they can fast forward that main branch.

I don't think it's possible on GitHub but I think Bitbucket has the ability to 'sync' a fork.

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?

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.

> _the missing piece that keeps this from being useful is that they can't keep their fork up to date using github.com_

yep, a year ago removed "Fork Queue" would come in handy there.

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.

Why is copying and pasting to be discouraged?

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

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?

Well, cloning is a git thing, not a github thing. Cloning repositories doesn't put them on your github repository list.

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.

You've probably seen discussion with Linus Torvalds about the problems with "pull request" model for his workflow: https://github.com/torvalds/linux/pull/17#issuecomment-56546...

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.

Bitbucket has side-by-side diffs.

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...

If there is nothing to build. Not everything version-controlled with Git has to be runnable software.

> <h3>Less distruptive workflows</h3>

Quick, somebody submit a pull request to the blog repository! :)

Is it possible to create/delete/move directories yet? I found myself wanting to do that just yesterday.

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.

Reply on news.ycombinator.com