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

161–170 of 200 posts

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

#161

Post by nemetroid »

Someone wrote: post #155
nemetroid wrote: post #117

Earlier quoted context omitted.

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.

I just don't understand why someone would do git checkout existing_directory if they don't want to overwrite files, since that is all the command does.

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

#162

Post by bsder »

HWR_14 wrote: post #67
skrebbel wrote: post #7

Fwiw a branch isn't a named sequence of commits, it's just a label that points to a single commit. It's exactly the same as a tag except that git moves it when you make a new commit. Mercurial calls these bookmarks which IMO is a much better name because it works exactly like real bookmarks (in books, not browsers). A git branch feels a little bit like a branch of a tree because each commit points to their parent. Th…

Am I the only one sad that Git beat out Mercurial as the industry standard? And am I also the only one who still knows how to do things in Mercurial but not how to take the corresponding action in Git? I mean, they're things I haven't had a reason to do in years, but it has some psychological cost to feel like I'm using a system I'm worse at.

> Am I the only one sad that Git beat out Mercurial as the industry standard?

Quibble: Git didn't win. Github won. Git was simply the parasite on the Github host.

However, I feel just like you. Mercurial is just so ridiculously easier to explain to people.

I really don't understand what it is about Git that seems to prevent anybody from coming up with a sane UX for it.

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

#163

Post by masklinn »

dotancohen wrote: post #154
masklinn wrote: post #60

Earlier quoted context omitted.

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.

Not at all is the issue. IIRC svn checkout is git’s clone, git’s checkout combines svn’s switch and revert (and possibly update -r? It’s been a very long time)

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

#164

Post by omegalulw »

skrebbel wrote: post #7

Fwiw a branch isn't a named sequence of commits, it's just a label that points to a single commit. It's exactly the same as a tag except that git moves it when you make a new commit. Mercurial calls these bookmarks which IMO is a much better name because it works exactly like real bookmarks (in books, not browsers). A git branch feels a little bit like a branch of a tree because each commit points to their parent. Th…

> a branch isn't a named sequence of commits, it's just a label that points to a single commit.

True, but in the past majority of cases parent commits in the branch (commits from leaf to the last ancestor that has only one child) would be semantically very related so this understanding is not that bad (so long as you remember a branch is a commit for git operations).

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

#165

Post by shikoba »

bsder wrote: post #162
HWR_14 wrote: post #67

Earlier quoted context omitted.

Am I the only one sad that Git beat out Mercurial as the industry standard? And am I also the only one who still knows how to do things in Mercurial but not how to take the corresponding action in Git? I mean, they're things I haven't had a reason to do in years, but it has some psychological cost to feel like I'm using a system I'm worse at.

> Am I the only one sad that Git beat out Mercurial as the industry standard? Quibble: Git didn't win. Github won. Git was simply the parasite on the Github host. However, I feel just like you. Mercurial is just so ridiculously easier to explain to people. I really don't understand what it is about Git that seems to prevent anybody from coming up with a sane UX for it.

> I really don't understand what it is about Git that seems to prevent anybody from coming up with a sane UX for it.

That's the problem. Git has a sane UX. The only issue is that a lot of people who doesn't understand it, write silly tutorials where they spread their misconception about it. The real issue is the poor quality of tutorials over the internet that mislead a lot of people.

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

#166

Post by shikoba »

TacticalCoder wrote: post #113
pdonis wrote: post #106

Earlier quoted context omitted.

> each commit points to their parent. Therefore, you don't need to track the entire sequence of commits in the branch but just the commit at the tip. This is not entirely true, because it is perfectly possible to create commit graphs in git in which there is not a single well-defined branch for some commits. So just knowing the branch labels at each tip is not sufficient to assign a single well-defined branch to ever…

Yeah I much preferred Mercurial from that standpoint. And branches there were correctly named branch. But you kinda, sorta, can get "what should have been called branches but don't exist in Git" by using named tags when you "start a branch" (a real branch I mean, not a Git "branch"). > Mercurial branches don't work like this: they are actually stored as part of each commit, so even with ambiguous commit graphs each c…

> branch that aren't branch at all

What do you mean? Git branches are branches. What is a branch for you? And why git branches aren't?

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

#167

Post by tigerlily »

dariusj18 wrote: post #22
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…

Tons of people have tried creating GUIs to make using git easier, and many do, but where they fail is when they try and change the terminology to make it easier to understand.

TortoiseGit works without loss of generality. In many respects it may even be more ergonomic.

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

#168

Post by woojoo666 »

shikoba wrote: post #165
bsder wrote: post #162

Earlier quoted context omitted.

> Am I the only one sad that Git beat out Mercurial as the industry standard? Quibble: Git didn't win. Github won. Git was simply the parasite on the Github host. However, I feel just like you. Mercurial is just so ridiculously easier to explain to people. I really don't understand what it is about Git that seems to prevent anybody from coming up with a sane UX for it.

> I really don't understand what it is about Git that seems to prevent anybody from coming up with a sane UX for it. That's the problem. Git has a sane UX. The only issue is that a lot of people who doesn't understand it, write silly tutorials where they spread their misconception about it. The real issue is the poor quality of tutorials over the internet that mislead a lot of people.

I don't think the UX is that intuitive. If you want to tweak a commit that's not the branch head, you have to rebase the parent of that commit. From a technical standpoint this sort of makes sense, but for a casual user this is not intuitive at all

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

#169

Post by mathstuf »

woojoo666 wrote: post #168
shikoba wrote: post #165

Earlier quoted context omitted.

> I really don't understand what it is about Git that seems to prevent anybody from coming up with a sane UX for it. That's the problem. Git has a sane UX. The only issue is that a lot of people who doesn't understand it, write silly tutorials where they spread their misconception about it. The real issue is the poor quality of tutorials over the internet that mislead a lot of people.

I don't think the UX is that intuitive. If you want to tweak a commit that's not the branch head, you have to rebase the parent of that commit. From a technical standpoint this sort of makes sense, but for a casual user this is not intuitive at all

You rebase onto the parent of that commit. The parent doesn't change. Or am I misunderstanding what you're describing here?

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

#170

Post by mathstuf »

HWR_14 wrote: post #67
skrebbel wrote: post #7

Fwiw a branch isn't a named sequence of commits, it's just a label that points to a single commit. It's exactly the same as a tag except that git moves it when you make a new commit. Mercurial calls these bookmarks which IMO is a much better name because it works exactly like real bookmarks (in books, not browsers). A git branch feels a little bit like a branch of a tree because each commit points to their parent. Th…

Am I the only one sad that Git beat out Mercurial as the industry standard? And am I also the only one who still knows how to do things in Mercurial but not how to take the corresponding action in Git? I mean, they're things I haven't had a reason to do in years, but it has some psychological cost to feel like I'm using a system I'm worse at.

I like the stage way more than not having it. I think Mercurial has it now as some extension, but my fingers know Git and git-hg is the only way I interact with the tool these days.

Explicit rename tracking is a mistake though. I think Linus got that one right.

Post reply on HN