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

Beej's Guide to Git

beej.us

Post reply on HN
Print view View original

271–280 of 318 posts

Re: Beej's Guide to Git

#271

Post by MatthiasPortzel »

MrJohz wrote: post #181
ajross wrote: post #166

Earlier quoted context omitted.

Literally every one of those questions can be trivially googled. (In previous generations and fora, this is where you'd be mocked with LMGTFY links). You just, to continue to embrace the frame, don't want to do the work. If you insist on memorizing commands for all these tasks (of which there are many ), indeed, you're going to struggle and decide you need a 30 section guide. But you don't, and want to whine about it…

> Literally every one of those questions can be trivially googled. (In previous generations and fora, this is where you'd be mocked with LMGTFY links). You just, to continue to embrace the frame, don't want to do the work. I find this an odd statement. I mean, no, I don't want to do the work! Not if it isn't necessary in the first place. Take staging (or the index, because another of Git's foibles is poor naming conv…

> Stashes are more like commits — they even appear in the reflog! But they also aren't real commits either, in the sense that you can't check them out, or rebase them, or manipulate them directly.

They are real commits, you can check them out (it detaches your HEAD, the syntax to reference them is `stash{N}`). Although I think this furthers, rather than undermining, your point that there are an unnecessary number of other commands to work with the stash.

I think this is a failure of the git CLI as much as the internal data-structures. I think the idea of a commit tree is very good and a lot of people recognize that. The commands that git exposes to work with that tree can sometimes be miserable.

Re: Beej's Guide to Git

#272

Post by jayd16 »

maccard wrote: post #239
jayd16 wrote: post #219

Earlier quoted context omitted.

Have you actually used P4 in anger? Having to add P4 support to any script, sucks. Having to do a network operation when touching files, sucks. Many many many apps have no idea what p4 is and will never get p4 support. Git gets out of the way.

> Have you actually used P4 in anger? Yes. I use it every day. I've ran P4 servers that serve hundreds of GBs per day globally with both commit edges and regular proxies. I've written batch scripts, bash scripts, and tooling in python, go and C# around it. > Having to add P4 support to any script, sucks. I disagree. It's no worse than adding git support to something. p4 zTag isn't the most elegant thing, but it works…

The point is you don't need to add git support.

Yes, network traffic does suck more than spending extra disk space, especially when you need multiple workspace because P4 sucks at switching anyway.

I don't understand what you mean about cloning. If you set up LFS properly it's not much worse than a fresh P4 pull.

Re: Beej's Guide to Git

#273

Post by riffraff »

account42 wrote: post #171
riffraff wrote: post #111

Earlier quoted context omitted.

Git was always confusing to use. There's a reason it has gained a "switch" command, and that's because the "checkout" command was confusing, while being there from the beginning. Probably you've been using it for ten years or more at this point and have internalized it, but when it came out git felt way more confusing than other VCSs. Compare git diff with hg diff for example.

I've never been confused by git checkout. git checkout switches to a branch. git checkout switches to a commit in a detached head state. git checkout switches just the content of a file. You can also combine these ofc but it all works pretty much as expected. The -b switch for creating new branches is someting you need to look up once and then just remember - and it does make sense - you are switching to a new branch…

I've dealt with people who are new to git and the fact that "git checkout X" does one thing or another based on what X is, was confusing for them, even if I could find an explanation for it. If you didn't have the same experience, good for you!

But compare "git switch X" and "git restore X". This makes different things look different, and obvious, which is usually a valuable thing when learning a new tool.

Re: Beej's Guide to Git

#274

Post by olalonde »

aidos wrote: post #148
beej71 wrote: post #30

Hey all--if you find things wrong, post 'em. I'll clean 'em up. :) Love, Beej

Not wrong, but since you’re mentioning vim in the context of git, might be worth adding :cq as a way to exit with a non-zero status to prevent git from finishing the commit / operation.

Mnemonic to help remember: cancel quit

Re: Beej's Guide to Git

#275

Post by MrJohz »

MatthiasPortzel wrote: post #271
MrJohz wrote: post #181

Earlier quoted context omitted.

> Literally every one of those questions can be trivially googled. (In previous generations and fora, this is where you'd be mocked with LMGTFY links). You just, to continue to embrace the frame, don't want to do the work. I find this an odd statement. I mean, no, I don't want to do the work! Not if it isn't necessary in the first place. Take staging (or the index, because another of Git's foibles is poor naming conv…

> Stashes are more like commits — they even appear in the reflog! But they also aren't real commits either, in the sense that you can't check them out, or rebase them, or manipulate them directly. They are real commits, you can check them out (it detaches your HEAD, the syntax to reference them is `stash{N}`). Although I think this furthers, rather than undermining, your point that there are an unnecessary number of…

I did not know you could check them out! But yeah, that really emphasises what I'm saying: there are too many things that are mostly commits but handled in a different way.

And I completely agree that this is about the CLI more than the internal data structures. I pointed at Jujutsu earlier, and that uses Git as the underlying data store (at least in its default configuration). It's an effective strategy in large part because Git-as-a-data-structure works really well already, and the distributed aspect means you can interop very effectively with existing tools like Github just by speaking the right protocol.

But while it keeps much of the same data structures, Jujutsu exposes a very different interface to those data structures, and one that I think is significantly simpler in large part because there aren't so many special cases (such as commits vs staging vs stashes vs ...). You end up with a smaller set of commands, but those commands are more consistent and can be applied in more cases. And you still have staging and stashes, it's just that you can build those yourself more naturally out of the tools that Jujutsu gives you.

Re: Beej's Guide to Git

#276

Post by juped »

diggan wrote: post #194
Sxubas wrote: post #61

> The Old Command: git checkout I didn't even know git switch existed, let alone git checkout was considered the old alternative. I feel old. To be fair I started learning git a little less than 10 years ago but woah, I can't express how it feels that someone learning git today will be confused of why I use git checkout. Like using old fashioned language. More on topic, this guide would've been super useful when I wa…

> I didn't even know git switch existed, let alone git checkout was considered the old alternative. I feel old. I don't think "git checkout" is considered the "old alternative", at least not yet. Last time I checked, `switch` is still experimental, I haven't even considered moving away from the workflows/commands I first learned when I picked up Git ~15 years ago. Everything I want to do still works exactly the same…

switch/restore are not experimental in that sense, they're experimental in the sense that they're not guaranteed stable so don't rely on them for scripts or something (I occasionally tell myself I should adopt them and get them stabilized, but then don't do it)

Re: Beej's Guide to Git

#277

Post by juped »

scrapcode wrote: post #26

I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.

Why are programmers so vehemently angry over the fact that a complex tool which does complex things to a complex data structure might have some complexity to it?

Re: Beej's Guide to Git

#279

Post by HdS84 »

globular-toast wrote: post #161
ajross wrote: post #43

Earlier quoted context omitted.

My sense, bluntly, is that if people spent half the effort learning git that they do whining about it, no one would bother making a 30+ part guide just explaining stuff you could find in a man page. Commits are snapshots of a tree. They have a list of ancestors (usually, but not always, just one). Tags are named pointers to a commit that don't change. Branches are named pointers to a commit that do change. The index…

There is one fundamental piece missing in your description of git that I think is the main reason people don't understand it. You have described a single DAG, but in git there are multiple DAGs . This is what it means to be a distributed version control system. In my experience people come to git and start using it with the centralised paradigm in their heads: that there is one repo and one DAG etc. They think that t…

My problem is that I always use git as a central server. Except that one time when our internal git was down and we used it peer to peer for a day. Honestly, using USB sticks for that would also have been okay.

Re: Beej's Guide to Git

#280

Post by shandor »

MrJohz wrote: post #184
wodenokoto wrote: post #99

On the promise of going back in time, I’m finding myself getting more utility of VS Codes timed snapshots than my own commits. I find it hard to judge when things are in a good enough state to commit and especially good enough to have a title. I might start writing a new function, decide that I want it to be a class only to give up the class and wanting to return to my almost complete function. Snapshot works pretty…

I'm going to cheat and say I use a different VCS, but I do really like Jujutsu's approach here. It has this idea of mutable commits, so essentially you can check out a commit, and then whenever you change a file, the commit is updated with the new file contents. Then internally, whenever a commit gets changed (or any aspect of the repository) that gets recorded in an append-only log. At any point in time, you can scr…

Damn. Every time someone mentions Jujutsu I learn something awesome about it. I really need to give it a proper try one of these days.
Post reply on HN