Comment by kneath | Hacker News Reader

Comment by kneath | Hacker News Reader

Parent Full thread

(Biased, I work at GitHub and helped design the original GHfM)

I use it every day, almost all of the time. I don't use a lot of it, but what I do use is tremendously useful. My workflow is usually:

1. Navigate to the folder in terminal (old habit, or starting servers) and type in `github .` which launches the client for this repo.

2. Sync to pull in new changes (cmd + s)

3. Create a new branch (cmd + b)

4. Commit as I code (visual diff helps me do light code review on the spot). This is definitely the core usage for me — seeing what uncommitted changes I have, selecting out partial commits, drafting up good commit messages, amending bad commits, etc.

5. When I'm ready to publish my branch, sync again (cmd + s)

The key for me really comes down to some really simple stuff: a visual editor for creating commits, and quick keyboard commands to common actions (branching, switching branches, push/pull). It's possible to do fast in terminal, but muscle memory serves me personally much better with real keyboard commands.

I don't get it. How in the world is that any easier than:

  cd /your/src/dir
  git pull

  <edit stuff>

  git diff

  <look at stuff; possibly edit more stuff>

  git commit -m "edited stuff"
 
  <oops...forgot something; edit another file>

  git commit -a --amend
  git push origin

Which, of course, has the added advantage that you're using git, instead of using a GUI obfuscation layer on top of git, and therefore learning your tools.

I mean...I sort of get why people do git integration in editors (even thought it tends to lead to ignorance of git), but opening up another, non-console, non-editing app, just for git?

Everyone uses software differently; brains work different. I've used Git on the command line for almost a decade now, and I find my current workflow much nicer.

You also left out a lot of the (again simple) commands I've included — switching branches and partial commits, where things like fuzzy autocomplete are very nice if your shell does not hook into Git and support fuzziness.

Good point. I left them out because there's more than one way to do it, and if you let a GUI tool do it for you, you become ignorant of those issues:

  git checkout -b new_branch
  <edit edit edit>
  git commit -a -m "i'll merge this branch"
  git checkout master
  git merge new_branch

vs:

  git checkout -b new_branch
  <edit edit edit>
  git commit -a -m "did stuff that i'll rebase this time"
  git fetch
  git rebase origin/master
  git checkout master
  git merge new_branch

vs:

  git checkout -b new_branch
  <edit foo.txt and bar.txt>
  git add foo.txt
  git commit -m "edited foo"
  git stash
  ...

People think differently, but nothing you've described is conceptually different than using the CLI. It's just a GUI, doing/obscuring the same stuff -- stuff that you need to understand to use git.

We have barely technical people on the team who use GitHub for Mac because they aren't comfortable in a CLI, but they are very comfortable using a regular application they can launch from their doc. That way GitHub gets to design around Git edge cases, and they don't have to get screwed when weird things happen in the CLI.

Yeah, that's the classic argument for wrapping a CLI with a GUI. The only problem is that with git, you can't design around the "weird things"...if the user is in a weird state in version control, they need to know about it.

In other words, it's the leaky abstraction problem. You can pretty up the UI, but ultimately, you have to communicate the concept to the user. It's how we got those "Can I copy The Internet?" questions in Windows 95....

I've found myself using a combination of both GitHub app, and CLI. Usually I'll checkout repos, make commits and push/pull using the GitHub app.

Then I'll switch over to the CLI for branching, merging, resetting and bitsecting (the latter two arent possible in the GitHub app)

for one thing, you are forgetting that people are human. this is what that workflow would more realisticly look like:

    cd /yor/src/dir
    bash: cd: /yor/src/dir: No such file or directory

examines closely to look for typo cd /your/src/dir

    <edit stuff>

    git diff

    git comit -m "edited stuff"
    Did you mean this? git: 'comit' is not a git command. See 'git --help'.

Did you mean this? commit git commit -m "edited stuff"

I think this is enough to get the picture.

> cd /yor/src/dir > bash: cd: /yor/src/dir: No such file or directory <tab> ?

And on anecdotal evidence, I've observed that people who use git intensively everyday often have aliases to these commands that have a low probability of typos.

eg gcom => git commit

Is there any way to revert a single hunk interactively in the client (like git checkout -p)?

I too use it for light code review, but often find spurious whitespace/brace placement changes that I want to revert to make my eventual PR a bit less noisy..

I believe you can select the lines/hunk you want to revert, then right click the filename (on the left) and click "Discard Changes" — but I would definitely ensure that's the case on some throwaway diff before believing me! Discard changes is no joke. I usually commit everything I want, then discard changes when all I'm left with is the bad whitespace/files.

(shameless plug) git-cola can do that, and it's open source.

Reply on news.ycombinator.com