Hacker News Reader

Comment by timr | Hacker News Reader

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?

View on HN

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

Reply on news.ycombinator.com