Hacker News Reader

As someone who spent 13 years using CVS, 8 with SVN and 3 with git, I can only say that I greatly disagree with you. The idea of adding a file to track, committing locally and pushing your commits on a branch to a remote makes perfect sense if you spend the thirty minutes it takes to learn what git actually does. Moreover, this is the minimum number of commands to effectively use git correctly.

1. Sure, if you're an expert, each command is useful. Practically, I commit only when it's ready (building, passes tests). So why would you commit without pushing (unless you're offline)?

2. I know what it does. I've read some manuals :) . The thing is

a. I'm not a VC (Version Control) expert, and most people aren't being paid to be VC experts.

They're paid to produce code.

Now, I (unlike a lot of people) don't mind spending some time learning my text editor (vi) which I use eight hours a day, but I'm not going to become an expert in a tool I use five times a day at most.

I just don't interact with it that often.

b. Good software is really meant to be gradual interaction. Take vi (which is infamous for being complicated) for example, to use vi, you need to know about 4 or 5 commands, each of which is a single letter or two letters at most, "i" to insert, "x" to delete, ":w" to write and ":q" to quit. Now you can use vi as a glorified notepad.

You need a more complicated workflow, you need to copy,paste, undo, fine. Learn each one as you need it.

And this is one of the more obtuse text-editing programs.

Honestly, if I used a text editor as often as I use git, I'd use nano or something.

> Practically, I commit only when it's ready (building, passes tests). So why would you commit without pushing (unless you're offline)?

I haven't set up a VCS server yet. I've fixed a security issue and haven't hit the embargo date yet. I'm doing exploratory coding (prototypes, refactorings, etc.) that may be discarded or reworked, even if it builds and passes tests right now. It passes all local tests but needs to be fuzz tested overnight before I'm satisfied enough to commit it upstream - but want to keep working in the meantime. I have more related changes to make before wanting to sic reviewers or the CI build process on my changes. I want to push my changes to a dev environment, but not a production environment just yet. I want to rebase to make my history look cleaner, but can't be bothered with doing so just yet.

I commit when it's not ready: I use WIP commits instead of stashes, and sometimes commit more often than I build. This has advantages: It can keep the individual diffs cleaner - an autoreformatting of a file to fix whitespace issues, and hand-implemented refactoring, should be separate commits for cleaner, more readable and reviewable diffs. This has drawbacks: In a centralized VCS, these will either get merged together into one messy commit (common), or they'll get blindly commited without (re)building for all permutations and occasionally break the build, or you'll slow everything down painstakingly testing the entire build after every minor permutation.

> but I'm not going to become an expert in a tool I use five times a day at most.

I'm no expert either. That said: In the interests of smaller, simpler, more reviewable changes - both for whoever might be doing a code review, and for myself if I mess up and want to figure out what I've done in the past few minutes to break something - I interact with my VCS much more frequently.

There are days I make 30 or so commits, and I likely diffed each commit multiple times before committing and/or submitting.

Aside from making it way easier to figure out what the hell it is that I've done, being able to finger a specific small changelist as having broken something has saved me tons of time I'd otherwise squander on false leads and disbelief. One of the nastiest heisenbugs I've had the misfortune to debug, I manually did the equivalent of a 'git bisect' on a perforce repository to track down the offending commit for. Totally innocuous change, totally to blame for a fruitless 2 week session of debugging in vain thanks to a buggy system API it used. So innocuous and seemingly unrelated, that I had to reproduce the issue in a simple test app to convince myself it was really the problem. I could've easily wasted another 2 weeks had the changelist been a little bit larger.

.

TL;DR: Smaller commits have saved me months of work, I figure. Committing without pushing lets me commit without shifting gears, encouraging smaller commits.

If you commit whenever you complete a feature, or fix a bug, you'll quickly see the benefits. You can look back and see exactly why you made a change, or where you introduced a bug. And the best feature is being able to make a branch for dev (or each new feature you are adding), and be able to switch to master if there's a bug you need to fix.

Also, if you work with more than one person, committing early and often is invaluable.

Really, Git takes like an hour to learn. You could also just download tortoisegit if you really want to be lazy about it.

I'm fond of: https://github.com/scmbreeze/scm_breeze

Two people have already described why the git process is so powerful. However, let's put some context to what you are saying. 'git add', 'git commit' and 'git push' take a grand total of 25 characters (including spaces) for three commands. If this is too much overhead and gets in the way of producing, I'd hate to see how much writing a switch statement gets in the way of producing.

I commit often in scenarios where feature I'm working on is complicated and I've broken it down to smaller tasks. When I finish one task A and move on to B, I might end up in situation where A is not actually supporting B so I might need to refactor A . So when I finish A,B and C, refactoring for for A is not needed anymore and in this point, if I wouldn't have the history of modifications to A, I would need to rewrite it, or at least parts instead of just reverting.

And finally, I squash all commits to a single feature commit.

> Sure, if you're an expert (...)

> I'm not a VC (Version Control) expert, and most people aren't being paid to be VC experts.

I agree that git could probably use some UI improvements, but to counterweight that - you're a paid professional, it's expected of you to learn the tools of the trade. It's like saying that carpenters are not being paid to know how to use saws and powerdrills.

You can simplify a tool only so much before it starts losing its utility.

--

People's refusal to sit down and spend literally half an hour learning to use something is astounding. Is that the "distraction culture" at work?

> 2. History - How can I go through a file to see its history? "git show REV"? What if I want a wikipedia style history? What if I want to go through the history of a file? There should be something like "git history main.c"

    git log --stat --patch -- main.c

Make that an alias:

    git config --global alias.history "log --stat --patch --"

What would "update" actually do?

For history, "git log", that is "git log file".

Isn't part three the same as "git checkout HEAD~1 -- file" ?

>What would "update" actually do?

git add . && git commit && git push

>Isn't part three the same as "git checkout HEAD~1 -- file" ?

What if the delete took place three commits ago?

Ah okay. I can see that.

Then you use HEAD~3.

But you first have to find in which commit you deleted the file.

Ah ha, we're starting from different assumptions. Makes sense now, thank you!

> What if the delete took place three commits ago?

The original command he was suggesting a replacement for used `-n 1`, so it seems kind of silly to point this out to him.

As soon as a command requires stuff as "HEAD" and "~" I believe there should be an easier way.

Yep. I really hope someone forks git with these ideas ...

I don't even know if it has to be a fork, maybe a few batch/python scripts could be enough.

The problem is that frequently by the time people become experts in a field, they no longer see the beginner's difficulties.

your 2nd para is gold. I believe this explains the phenomenon where when you join a new company or parachute into a new codebase for the first time, its often painful ramping up. because so much tribal knowledge is undocumented. or docs not kept updated and wrong. or each dev has their own workflow that works for them privately but nobody's maintaining a common one a newbie can use to get started. some shops/projects better about it than others, obviously.

No need for so much work.

Simple commands can be accomplished by adding a git alias. More complex commands can be just a shell script. Put it on PATH with a name like `git-something` and now you can run `git something`.

Yes, git's "frontend" is complicated and confusing. There are a plethora of tools that purport to replace it, partially or fully, with something more intuitive. Just off the top of my head:

http://gitless.com/

http://www.git-legit.org/

However, they never seem to really take off. Why is that? One thought is also a mandatory XKCD: http://xkcd.com/927/

I think most people just have the 5-6 obscure/painful commands they execute more than once a year stuck in an alias, and don't have a strong enough need for Yet Another Thing to Install on fresh systems.

It's also sometimes hard to know what exactly these extra commands will do if you don't use them often enough to know, so safe use still involves checking the docs, at which point you may as well google for "git [description of thing I need to do]"

After having worked with people that were absolutely hell bent on never using the CLI version of git (and having helped them fix the screwups of their GUI tools a good number of times), I actually think most people would be better off trying to understand how git works internally a little bit more instead of just installing another tool after the last one disappointed them. I don't say you'll have to be an expert, but not having a clue what the tool actually tries to do doesn't really help in those cases (neither does it if you want to do something complicated in SVN, for example) - and the abstractions GUIs add on top of git are bound to break sometime.

That is - of course - if you are using git in more than just some basic way. If you're the single person committing code, it will "work" anyway. Perhaps that's the problem: Some people don't see that collaborating on the same set of files in more usable, but also more complex ways (than they are used to) requires more orchestration than just "lock - update - release"...

Thanks for posting the xkcd comic. I was intrigued by the phrase "distributed graph theory tree model." It is definitely missing some hyphens. Ultimately I decided it should be "distributed graph-theory-tree model." That is, "graph theory" is an adjective modifying tree, and tree is an adjective modifying model.

Don't you use an ide/sourcetree ? All that functionality is available.