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

171–180 of 200 posts

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

#171

Post by brianwawok »

HWR_14 wrote: post #103
brianwawok wrote: post #98

Earlier quoted context omitted.

I was on the team of a large org doing a POC between the two. Merc did some stuff better, git did more. I am glad git won out overall. I think the only feature Merc had that I cared about was tracking folders as objects.

Mind if I ask what Git did better? The main selling point for the difference between them was the Linus, Linux and then the whole community chose Git. The only big difference I recall Git winning on was in third party tooling and Git supporting more than two parents merging.

This was a lot of years.. but things like:

1) We used some super crappy Clearcase version control system. It was easier to layer Git on top, letting us have a VC on top of a VC. I can't remember if it was impossible, or just easier to do in Git.

2) Conflicts did better. We made kind of torture test of merges and put both systems through. Git was able to resolve more out of the box.

3) Speed of operations, I think Git was a bit faster out of the box.

None of this was about Github, as it was comparing self hosted HG vs self hoted GIT.

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

#172

Post by dariusj18 »

tigerlily wrote: post #167
dariusj18 wrote: post #22

Earlier quoted context omitted.

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.

TortoiseSVN is IMO the best way to do SVN. I never got into TortoiseGit though.

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

#174

Post by smusamashah »

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…

> but how they interact under the various commands > but about how to deal with different remotes, how to have local branches

If you are saying this in context of CLI. I have no clue. What I am saying is, if you understand the concepts and have a good GUI tool at your disposal you can solve almost all problems with ease.

I have previously used SmartGit which lets you drag and rearrange commits. It also allows interactively selecting the lines/chunks from you want to make part of commit. Same goes for resolving conflicts. IntelliJ also has a very good GUI which I use these days at work.

Something I didn't find much help with was how to squash commits which include merge commits as well. But overall, GUIs help alot if you know what you want to do.

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

#175

Post by cryptonector »

remram wrote: post #173
cryptonector wrote: post #141

Earlier quoted context omitted.

Only if --hard is given.

Which is what we're talking about.

Right, so stop typing that at all. Instead use `git checkout -f` to throw away extant changes. The `-f`/`--force` option is a lot clearer in intent than `--hard`.

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

#176

Post by shikoba »

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

> If you want to tweak a commit

Here we are. You can't tweak a commit in git. You want to recreate a new one. That's why UX is awful, because there is a permanent confusion about what git does.

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

#177

Post by cryptonector »

andrewjl wrote: post #147
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…

To use an example from TFA: how does Reset make any sense based on the Unix filesystem?

`git reset` is analogous to filesystem restore from backup.

Next question.

Note that the analogy to filesystems is not exact. The point is that you can understand higher-level operations in terms of lower level ones / gain insight into higher level operations from knowledge of the lower level concepts. As opposed to the cognitive burden of incomprehensible magic, where every time you get in trouble you've no idea what to do.

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

#178

Post by cryptonector »

lmm wrote: post #144
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…

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.

I would either unstage then stash, or commit, create a branch to point to the new HEAD, stash, then reset the branch to the previous HEAD.

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

#179

Post by shkkmo »

layer8 wrote: post #87
mjd wrote: post #76

Earlier quoted context omitted.

I'm reading it and I think I got it right. The Git community, the Git documentation, and the Git tools all refer to "branches", and I think what they mean when they talk about "branches" is much closer to what I described than to what you did. For example, consider this very ordinary-sounding phrase that I just picked out of the git-rebase man page: > If the upstream branch already contains a change you have made … I…

But what’s the precise rule defining what constitutes the commits of a branch, after you reach a merge point? Does the branch end there? If not, which parent of the merge does it go? It’s not clear a priori.

Every commit contains an ordered list of it's parent commits. You could think of the 'main' history as being the chain of commits that are always the first ancestor to each other and this can be a use thing to display when generating a commit history.

However, the history of a commit is always the entire tree of ancestors. This entire tree is the precise definition of what constitutes all the commits of a branch.

Thus while I agree that it is not wrong to view a branch as a bookmark, I also think that attempts to nitpick the man page's use of the term fall flat here. "Commit contained in a branch" just means: "commit contained in the history of the commit the branch currently points to." and isn't ambiguous.

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

#180

Post by goto11 »

masklinn wrote: post #53
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? Git has the plumbing vs. porcelain separation. Dozens have, but by the time their replacement porcelain gets anywhere near useful they’ve attained a grasp of the plumbing more than good enough they don’t need it anymore. > My second question is, if the underlying model is so f*cking elegant, how did it lead to such a confusing interface? Mastery of structura…

JavaScript is another example. The core model is simple: Closures + dictionaries. But the syntax is clunky and confusing.
Post reply on HN