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

151–160 of 200 posts

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

#151

Post by masklinn »

cryptonector wrote: post #74
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 question is why hasn't anyone come along and fixed it? Because the model is simple and easy to understand, and you get a lot of power from understanding it. Whereas opinionated porcelain that tries to insulate the user from the model will tend to fail in obnoxious ways and will not serve the user. Really, there's objects, there's commits, then there's a couple of methods for symbolically naming commits (branches…

> Cherry-pick is just applying a delta from a commit and then re-committing.

That’s trivially not true from its conflict resolution abilities. A cherrypick is a merge which does not create a merge commit, it’s a lot “smarter” that “git show -p | git patch”

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

#152

Post by waynesonfire »

yCombLinks wrote: post #97
cryptonector wrote: post #74

Earlier quoted context omitted.

> My question is why hasn't anyone come along and fixed it? Because the model is simple and easy to understand, and you get a lot of power from understanding it. Whereas opinionated porcelain that tries to insulate the user from the model will tend to fail in obnoxious ways and will not serve the user. Really, there's objects, there's commits, then there's a couple of methods for symbolically naming commits (branches…

The problem isn't requiring knowledge of the model, the problem is inconsistencies in the git commands for working with the model.

Then create yourself some convenient command aliases. It's not like someone is going to create a layer over git and make it 10x better by fixing some inconsistencies. Plus, whatever benefit is added you'll still have to learn the layer below the abstraction.. eventually.. to be productive. Just not worth it. You may as well learn git. You'll use it for the rest of your career. And that's a breath of fresh air that I can say that confidently about a technology.

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

#153

Post by lmm »

fiddlerwoaroof wrote: post #146
lmm wrote: post #144

Earlier quoted context omitted.

If I've partially staged some changes, why can't I stash and unstash them and get back to the same state? The problems with git are not the commits and the DAG. It's all the ancillary stuff that's inconsistent and confusing.

You can, I think, with `git stash push foo.js`

You can't; depending on the options that will either stash your staged changes to foo.js, stash your unstaged changes to foo.js, or stash both but flatten them so that when you apply them they're all staged (or all unstaged). There's no way to stash it so that you can unstash it and get it back how it is now.

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

#154

Post by dotancohen »

masklinn wrote: post #60
dotancohen wrote: post #54

Earlier quoted context omitted.

Git reused much of the terminology of other VCS systems, even though the architecture was completely different. So usage-wise git was familiar to someone familiar with e.g. SVN right from the beginning.

Except that’s not true because a lot of the commands git reused do something rather to completely different from their role in svn.

Different internally, but from the perspective of the user the standard commit - checkout workflow is very similar.

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

#155

Post by Someone »

nemetroid wrote: post #117
Someone wrote: post #111

Earlier quoted context omitted.

I don’t see anybody here claiming that’s git’s fault. But it is an argument supporting the claim being discussed: that the statement “It is very hard to permanently lose work” is not quite true.

Using the command specifically designed to permanently discard work seems ”very hard” to me.

But it’s inconsistent in that. git checkout existing_branch complains with “error: Your local changes to the following files would be overwritten by checkout”* and abort, git checkout existing_directory overwrites files.

That’s what makes it easy to make that mistake, and lose data. It’s safe to use until it suddenly isn’t.

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

#156

Post by seba_dos1 »

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…

I have a handful of aliases, but scripts? What do you script in git? My aliases revolve around pulling MRs from GitLab/GitHub, having some nice pretty formats and pushing things with custom push options consumed by CI. Not much else there.

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

#157

Post by glandium »

brigandish wrote: post #129
hsn915 wrote: post #116

Earlier quoted context omitted.

> > 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 s…

Past discussion about Jujutsu: https://news.ycombinator.com/item?id=30398662

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

#158

Post by seba_dos1 »

buzzwords wrote: post #5

I wonder how many hours have been wasted on fixing mistakes made on git. Recently, I watch a friend spend two days try and figure out what the junior Devs have done with commits and branches

From my experience, I'd say it's negligible compared to number of hours saved by git.

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

#159

Post by seba_dos1 »

layer8 wrote: post #135
smusamashah wrote: post #95

Earlier quoted context omitted.

Rebasing is when a whole branch (a chain of commits) is picked up and moved on to some other commit. It's easy to build up on that. Working tree is current state of files. Index is the staging area or the buffer (if I am not forgetting) where you put your changes you are about to permanently commit. Git is distributed system. Your repo can point to another repo as its remote copy. Can have multiple remotes. The defau…

I’m not talking about understanding what a rebase is supposed to achieve, I’m talking about the merge conflicts than can arise while rebasing, understanding why they happen and how to deal with them. I’m not talking about understanding what the working tree and index are, but how they interact under the various commands, what happens with the working tree and index state for example when you switch a branch, etc. I’m…

> I’m not talking about understanding what a rebase is supposed to achieve, I’m talking about the merge conflicts than can arise while rebasing, understanding why they happen and how to deal with them.

I found it rather obvious? Git usually tells you how to deal with it, and conflict markers are easy to understand. What could be more visible is that rerere exists, as that can save you a lot of energy if you're rebasing frequently. Also, conflicts from stashes are a weird special case, which can be confusing (but so are stashes in general).

> I’m not talking about understanding what the working tree and index are, but how they interact under the various commands, what happens with the working tree and index state for example when you switch a branch, etc.

That's also obvious, and Git tells you what happens as you do this stuff too. If it couldn't switch a branch, it tells you why; if there's an uncommited change, it's listed during checkout. I don't think I'd be able to tell how various commands interact with index without having git in front of me, and yet it doesn't cause me any visible troubles (and I'm a somewhat heavy git user).

> I’m not talking about a basic understanding of what a remote is, but about how to deal with different remotes, how to have local branches, how to push/pull only some branches vs. all branches, and so on.

I don't really understand what's problematic with those. All of the things you mentioned are really basic commands. A good tutorial could easily cover it all.

There's plenty of stuff to criticize about git's UI, but I'm very surprised that this is what you found worth mentioning.

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

#160

Post by nemetroid »

lisper wrote: post #123
nemetroid wrote: post #115

Earlier quoted context omitted.

> 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 permanen…

> 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 disagree that it's a difference in the level of risk. There's no "risk" that git checkout [path] will discard your uncommitted changes, it's a promise and a certainty.

That said, I agree that the breadth of largely unrelated functionality smushed into git checkout is surprising, but it's also one of the few things about Git's user interface that actually has been addressed by new subcommands.

Post reply on HN