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

More Productive Git

increment.com

Post reply on HN
Print view View original

91–100 of 147 posts

Re: More Productive Git

#91

Post by crimsonalucard »

saagarjha wrote: post #24
crimsonalucard wrote: post #16

Any interface that forces you to manually visualize a complex internal structure rather than show you the internal structure itself is a design smell. Any interface that forces me to manipulate such a complex structure with obscure textual commands rather than a drag and drop interface is a design smell. The git graph structure is not amenable to command line. When I do "git log" it lies to me. I see a linked list fo…

The command line shows you part of the graph: you choose which part it shows you based on what options you pass it.

Without options it returns something that is implied to be a linked list. Try it. Anything merged into the current branch is shown as part of a single long list. It implies sequentialism in places that are parallel.

Re: More Productive Git

#92

Post by crimsonalucard »

gwright wrote: post #74
crimsonalucard wrote: post #16

Any interface that forces you to manually visualize a complex internal structure rather than show you the internal structure itself is a design smell. Any interface that forces me to manipulate such a complex structure with obscure textual commands rather than a drag and drop interface is a design smell. The git graph structure is not amenable to command line. When I do "git log" it lies to me. I see a linked list fo…

You are seeing a path through the graph. If you want the entire graph: git log --all --graph --oneline

Right, this solves all my problems tack on hundreds of optional tags to every command that I have memorize and suddenly the user interface is perfection.

FYI without those options it is showing me part of the graph and implying that it is a linked list.

Re: More Productive Git

#93

Post by js2 »

olvy0 wrote: post #14
ayushgp wrote: post #5

One of the most common issue I faced when I started learning git was diverging local and remote branches, franatically searching how to fix it and giving up 2 hours later.

Yes, that has been my experience as well. Starting a new repo that has a remote tracking branch has been a source of constant frustration for me. I routinely mess up some incantation and then have no idea how to fix it. The mental overload is high enough with local branches, but I still don't quite follow what it means to have a tracking branch, it seems to complicate the nice and simple mental picture I have of the…

When you fetch from a remote repo, the state of the branches in that repo has to be recorded somewhere locally in your repo. That’s what remote tracking branches are. So if the remote called origin has a branch called master, and you fetch, git downloads the commits you don’t have and then updates .git/refs/remotes/origin/master to the commit ID of whatever master is on origin.

That’s all it is.

Basically you have a DAG just like you think. But git needs some way to label some of the nodes in that DAG. It calls those labels “references” or refs, it records them under .git/refs/, and there’s basically just three kinds: local branches (refs/heads/), tags (refs/tags/) and remote tracking branches (refs/remotes//). There’s also the reflog which is a change log of the local branch refs, and a special log for HEAD which keeps track as you switch which branch is currently checked out.

Note: if you start poking around under .git (and you should in a toy repo!), you might not find exactly these files. For performance reasons, git sometimes combines the refs into a single file called packed-refs.

Re: More Productive Git

#94

Post by OJFord »

wyldfire wrote: post #6
jc_sec wrote: post #2

There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.

> Git isn't that hard. It's not, but if you don't use it mostly every day, or if you decide to "Delete repository and clone again" every time there's a problem, you won't ever get to learn how to fix it. The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it. The term `checkout` is multiplexed to do more things than I would've guessed.

> The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it.

I can't even imagine not having it, I extremely rarely commit all changes, to the point where I really might as well alias add=add -p, and now I've thought of it I probably will.

> The term `checkout` is multiplexed to do more things than I would've guessed.

My rule is that if I think that, I've probably got the 'wrong' mental model.

Checkout gets the state of the worktree from somewhere else.

In its simplest usage, from another ref and changes to it.

With -b, as above, but with a new branch name.

With -- files, filter for only the given files, leaving HEAD where it is because moving it would be the opposite operation - taking the inverse list of files from current location to the specified one.

Etc.

Re: More Productive Git

#95

Post by atq2119 »

olvy0 wrote: post #14
ayushgp wrote: post #5

One of the most common issue I faced when I started learning git was diverging local and remote branches, franatically searching how to fix it and giving up 2 hours later.

Yes, that has been my experience as well. Starting a new repo that has a remote tracking branch has been a source of constant frustration for me. I routinely mess up some incantation and then have no idea how to fix it. The mental overload is high enough with local branches, but I still don't quite follow what it means to have a tracking branch, it seems to complicate the nice and simple mental picture I have of the…

A concrete example would be interesting.

The only thing you really need to internalize is that all git operations are entirely local on your machine, except clone/fetch/pull/push.

(Another useful thing to internalize is that git pull is really just git fetch followed by git merge. git fetch is the part that involves network activity, while git merge is entirely local on your machine. I can't remember the last time I've used git pull, actually...)

So when you're doing git log origin/master, you're not looking at the current state of the master branch on a remote machine. Instead, you're looking at what the state was the last time you did a fetch/pull/push.

This is extremely useful for being able to work remotely.

Re: More Productive Git

#96

Post by atq2119 »

kyberias wrote: post #34
derwiki wrote: post #11

Earlier quoted context omitted.

What makes you say that? I use that command nearly every day.

There is something wrong with your workflow if you have to use git reset --hard nearly every day.

git reset --hard makes a lot of sense with printf debugging.

A typical workflow starts by adding printfs or whatever your equivalent is until you've narrowed down the bug. Then you fix the bug, keeping the printfs until the fix is confirmed. Then you use git gui or an equivalent tool to form the commit(s) for your bugfix. Finally, use git reset --hard to remove the debugging detritus.

Re: More Productive Git

#97

Post by finnthehuman »

chiefalchemist wrote: post #31

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

I, on the other hand, see these threads and wonder how arrogant and fraudulent our industry is when programmers have to pat eachother on the back and say the problem is git.

Git is a tool for creating and navigating a directed acyclic graph of revisions. It’s fine to chuckle and make fun about how esoteric that sounds, but at the same time I expect people that work on my team to rise to the challenge of proving that they occasionally attended data structures and algorithms class.

I understand not taking a day to learn git, I really do. It’s hard to find the time to learn everything that comes your way at work, and you’re not exposed to the practical challenges that augment documentation as part of learning if you try to crush it out all at once. But, if someone can’t learn git, I don’t know what to do with them. We’re not cranking out websites in an agile, typewriter-pool style open-office, sweatshop. I need people that can learn things at least as complicated as git, because they’re gonna have to keep up.

Re: More Productive Git

#98

Post by albertgoeswoof »

finnthehuman wrote: post #97
chiefalchemist wrote: post #31

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

I, on the other hand, see these threads and wonder how arrogant and fraudulent our industry is when programmers have to pat eachother on the back and say the problem is git. Git is a tool for creating and navigating a directed acyclic graph of revisions. It’s fine to chuckle and make fun about how esoteric that sounds, but at the same time I expect people that work on my team to rise to the challenge of proving that…

This is self defeating, if git was easier to use your team members could take that extra day and learn something more valuable.

Just because something is hard it doesn’t mean it’s worth doing.

Re: More Productive Git

#99

Post by User23 »

chiefalchemist wrote: post #31

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

> But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got out of the Dark Ages

Tradesmen use all kinds of tools like that, which is why trade schools and apprenticeships are a thing. I bet there are weekly articles on how to get the most out of your Fluke in the trade press, we just don't read them.

Re: More Productive Git

#100

Post by User23 »

alkonaut wrote: post #49
chiefalchemist wrote: post #31

There's one of these articles at least once per week that makes it to top of HN. When are we collective going to come to the realization that Git is a corded drill in a battery-powered drill world? Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got…

Agree (And ironically of course some people agree on this in the discussion on every one of these articles). Git is the C++ of version control. Of course it’s powerful. Of course it can do everything. And of course it’s a huge frustrating footgun with error messages that rival any c++ template compiler error. The problem is that we have made it a de facto standard so it’s hard to replace. Even if a much better VCS em…

Pijul looks cool, but "replace hard to understand directory content snapshots with easy category theory" isn't a compelling proposition outside of maybe the ML/Haskell community.
Post reply on HN