Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I wish everyone knew about Git (Part I)

blog.plover.com

Post reply on HN
Print view View original

121–130 of 200 posts

Re: Things I wish everyone knew about Git (Part I)

#121

Post by kjeetgill »

chronometry888 wrote: post #69
compiler-guy wrote: post #46

Earlier quoted context omitted.

"Just don't make a mistake" is a pretty bad strategy.

But "save your changes before running a command that can clobber" is a pretty good strategy.

Agreed though. I always start with teaching people. If you git add + git commit + git branch BACKUP everything you can very safely do anything you want. If you get confused it's trivial to get to a clean state by git reset --hard.

If you give people a way to get to a clean slate it removes a significant amount of the learning curve. In my experience, push/pull/fetch/log/diff are easy enough it's only really merge/rebase management that gets people caught up. Giving people a short fuck up -> undo -> retry cycle lets people learn pretty quick.

Re: Things I wish everyone knew about Git (Part I)

#122

Post by cryptonector »

chx wrote: post #84
cryptonector wrote: post #78

Earlier quoted context omitted.

Basically, making `git reset --hard` and `git checkout -f` auto-stash would be great.

That's what the script does for the first. Essentially.

But it could just be built in to Git. I mean: it should be.

Re: Things I wish everyone knew about Git (Part I)

#123

Post by lisper »

nemetroid wrote: post #115
lisper wrote: post #11

> But if I were going to tell everyone just one more thing, it would be: > It is very hard to permanently lose work. Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree [UPDATE: if you do 'git checkout [path]', but that is not an uncommon thing to do.] It is true that it is very hard to lose work that you have committed. But even this is not…

> if you do 'git checkout [path]' The entire point of that command is to discard local changes. There is some risk of getting the different forms of checkout mixed up, though, so prefer using switch and restore instead. As far as I know, the only use case of checkout not covered by other commands is checking out a commit that doesn’t have a branch attached to it.

> The entire point of that command is to discard local changes.

I think that's arguable, but it's neither here nor there. Someone who is not well versed in git arcana will be surprised that the level of risk associated with 'git checkout [branch]' is radically different from 'git checkout [directory]'. I think a lot of people will learn this the hard way, especially if they have been told "It is very hard to permanently lose work." It's not true. Permanently losing work is as easy as being careless with git checkout.

Re: Things I wish everyone knew about Git (Part I)

#124

Post by kjeetgill »

cryptonector wrote: post #78
chx wrote: post #30

> When I first used Git it drove me almost to tears of rage and frustration. But I did get it under control. I don't love Git, but I use it every day, by choice, and I use it effectively. Yes. For me the rescue was Charles Duan's git tutorial: Understanding Git conceptually. https://www.sbf5.com/~cduan/technical/git/ > you can only really use Git if you understand how Git works. Merely memorizing which commands you s…

Basically, making `git reset --hard` and `git checkout -f` auto-stash would be great.

If I had to pick my version of this solution to fix 60% of git's learning curve problems:

a) Don't tell people about stash. All Commits Everything.

b) All commands that change the working directory or branches should fail on uncommitted work and ask you to git commit. It already does this for untracked changes.

c) Show people show git branch BACKUP (requiring a commit) + git reset --hard BACKUP will always get you back to where you started safely.

Re: Things I wish everyone knew about Git (Part I)

#125

Post by ingobingo »

pierrebai wrote: post #108
intrepidhero wrote: post #12

> But if you try to understand the commands without the model, you will suffer, because the commands do not make sense. I've read this about git several times and certainly felt it. My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation. Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc? This seems like a similar situati…

> My second question is, if the underlying model is so f*cking elegant, how did it lead to such a confusing interface? This is the consequence of elegance. Elegance at one level usually is characterized by being very data-agnostic, very workflow-agnostic, etc. This leads to anything built on top of it to be so generic its unusable or at least very awkward. Pretty much everyone who works with git daily has a set of sc…

Not only have I never thought about or used a script for day-to-day stuff in more than a decade of using git, I don't know a single person who does...

It's really not as hard or cumbersome as this comment section would have you believe

Re: Things I wish everyone knew about Git (Part I)

#126

Post by stevage »

intrepidhero wrote: post #12

> But if you try to understand the commands without the model, you will suffer, because the commands do not make sense. I've read this about git several times and certainly felt it. My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation. Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc? This seems like a similar situati…

They have, several times. But it's very hard for a third party command line interface to outcompete the native one.

Re: Things I wish everyone knew about Git (Part I)

#127

Post by remram »

cryptonector wrote: post #75
lisper wrote: post #11

> But if I were going to tell everyone just one more thing, it would be: > It is very hard to permanently lose work. Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree [UPDATE: if you do 'git checkout [path]', but that is not an uncommon thing to do.] It is true that it is very hard to lose work that you have committed. But even this is not…

Never `git checkout -f` or `git reset --hard` unless you know you want to throw away extant changes from the workspace. That's it. Know that, live that, and you'll never lose work because of Git.

git checkout with two arguments will clobber the working copy, no -f required

Re: Things I wish everyone knew about Git (Part I)

#128

Post by remram »

stu2b50 wrote: post #80
cryptonector wrote: post #75

Earlier quoted context omitted.

Never `git checkout -f` or `git reset --hard` unless you know you want to throw away extant changes from the workspace. That's it. Know that, live that, and you'll never lose work because of Git.

You can git reset --hard and still get your work back without much trouble. Resets just move the branch pointer back, after all.

It also throws away changes from both the working copy and the staging area.

Re: Things I wish everyone knew about Git (Part I)

#129

Post by brigandish »

hsn915 wrote: post #116
intrepidhero wrote: post #12

> But if you try to understand the commands without the model, you will suffer, because the commands do not make sense. I've read this about git several times and certainly felt it. My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation. Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc? This seems like a similar situati…

> > But if you try to understand the commands without the model, you will suffer, because the commands do not make sense. > I've read this about git several times and certainly felt it. My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation. Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc? What about svn is intuitive?…

Isn't that jujutsu?[1]

> Jujutsu is a Git-compatible DVCS. It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system).

> Compatible with Git > > Jujutsu has two backends. One of them is a Git backend (the other is a native one 1). This lets you use Jujutsu as an alternative interface to Git. The commits you create will look like regular Git commits. You can always switch back to Git.

[1] https://github.com/martinvonz/jj

Re: Things I wish everyone knew about Git (Part I)

#130

Post by ziml77 »

chx wrote: post #30

> When I first used Git it drove me almost to tears of rage and frustration. But I did get it under control. I don't love Git, but I use it every day, by choice, and I use it effectively. Yes. For me the rescue was Charles Duan's git tutorial: Understanding Git conceptually. https://www.sbf5.com/~cduan/technical/git/ > you can only really use Git if you understand how Git works. Merely memorizing which commands you s…

That script is a really smart idea! Now I'm thinking it's almost crazy that's not built in.
Post reply on HN