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

181–190 of 318 posts

Re: Beej's Guide to Git

#181

Post by MrJohz »

ajross wrote: post #166
wruza wrote: post #110

Earlier quoted context omitted.

This doesn’t work. Look: Commits are sets of files. They form a tree. A branch is a named location in this tree. The index aka staging area is a pre-commit that has no message. Workdir is just workdir, it doesn’t go in the repo unless you stage it. HEAD is whereafter commit will put new changes. Do I understand git? Seems like yes. Let’s run a quiz then! Q? A. How to make a branch? Git branch -a? Git checkout -b --ne…

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 conventions that stick around and confuse newcomers). It's kind of a commit, right? In the sense that it's a snapshot of work that represents a change to the code. Except we can't really make it behave like a commit, we have to interact with it using special commands until we turn it into a commit. Are these special commands really doing much differently than we might do with another commit? Not really.

Or take stashes. 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. Again, you need a bunch of extra commands for working with the stash, when really they're just free-standing anonymous commits.

Or take branches. Branches are, as everyone knows, pointers to commits. So why is it important whether I'm checking out a branch or a commit? Why is one of these normal, but the other produces hideous warnings and looks like it loses me data if I haven't learned what a reflog is yet? And if a branch is just a pointer, why can't I move it around freely? I can push it forwards, but I can't move it to another arbitrary commit without fiddling around a lot. Why?

Or take tags, which are like branches, but they don't move. Is "moves" and "doesn't move" such a deeply important distinction that Git needs branches and two different kinds of tag?

---

To be clear, I think Git is a good tool, and I agree that once you've started to familiarise yourself with it, it's not so complicated in day-to-day usage. Yes, you'll probably need to Google a few specific commands every so often, but the general UX of the tool has significantly improved since the early days, and it is getting better.

That said, I also don't like the idea of settling with Git just because it's good. If there are alternatives out there that can do everything that Git can do, but with a simpler conceptual model, then I want to try them! (And, spoiler alert, I think there are better alternatives out there — in particular, I think Jujutsu is just as powerful as Git, if not more so, while simplifying and removing unnecessarily duplicated concepts.)

Re: Beej's Guide to Git

#184

Post by MrJohz »

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 scroll through that log and restore any previous repository state, including changes to individual files.

By default, Jujutsu does the snapshotting thing (i.e. updating the commit with the contents of the local files) every time you run the `jj` command. However, you can set up file watchers so that it does the snapshotting every time a file changes in the repository. If you do this, you should be able to browse through the op log and see all of the changes you've made over time, including reverting to any of those stages when necessary.

In fairness, I've not tried the file watcher thing out personally, but being able to review the op log is fantastic for trying to go back to previous versions of your repository without having to do teeny-tiny "wip" commits manually all the time.

Re: Beej's Guide to Git

#185

Post by stcroixx »

crabbone wrote: post #124
stephen_g wrote: post #16

Earlier quoted context omitted.

I think it's probably the opposite, Git has amassed a lot of complexity because it's been adapted to being a tool that is able to can satisfy the majority of requirements. I've never found that I need to touch most of it in the 15 or so years I've been using it, but it's there if your project needs it.

Nope. It was initially built for the use-case most people will never have: multiple remotes that work on a project with multiple similar products each with its own set of differences from the others, with emphasis and dependency on Unix tools and text-only emails. Most Git users will never have more than one remote per project, and so will only have a single product built from their source code. Probably wouldn't eve…

Spot on. I think it won because of who created it. I love linux and have been a daily user for like 25 years, but that doesn't mean I'm going to have a positive bias towards new tools or projects Linus makes like git. I think had some no name developed this it would have been laughed at by the majority of devs because, as you say, it's target use case is very specific and rare making it the wrong tool for most of us. Might have the worst interface I've ever seen. Before using it, I spent close to zero time thinking about version control and didn't need to understand anything about it's internals and had zero problems in the software dev lifecycle. Now, people are proud to waste time learning implementation details of their version control tool?

Re: Beej's Guide to Git

#186

Post by stcroixx »

Barrin92 wrote: post #18
vvpan wrote: post #14

Earlier quoted context omitted.

It tells me that git is the wrong tool for the majority of people but it just happened to stick.

No. Git is a complex program but version control is an inherently complex problem that requires powerful tools. There's certain set of problems where, as a programmer, you're going to have to sit down and actually read the book. The universe doesn't owe you an easy 10 minute video solution to everything, it's an annoying educational expectation that people seem to have developed. Some things are just that difficult a…

I was a developer for a long time before git and used many different VC systems. Didn't need to read the book on any of them and had no problems. For most cases, VC is simple. Git is just designed for this complicated case that applies to a tiny sliver of developers. I've never once pushed to more than one remote in like 10-15 years of using it.

Re: Beej's Guide to Git

#188

Post by ajross »

wruza wrote: post #116
gitgood wrote: post #86

Earlier quoted context omitted.

I'm always kind of aghast at the number of people who not only don't know git, but who cannot or will not learn it over years, or even decades. Listen, I'm not that smart, and I managed to figure out how to solve even gnarly git issues one summer during an internship... 11 years ago? Ish? Now, I know git well, and not just "the three commands". I would be, honestly, so ashamed if it were a decade on and I still hadn'…

If people can't learn git, I wouldn't trust them with the even harder parts of software development. This idea breaks under pressure. People have limited concentration and the more you demand for daily routine, the less there’s left for the actual job. This argument only makes sense in a relaxed setting with lots of time and coffee breaks. But all these problems tend to happen at friday evening when you’re expected t…

> Nowadays all we have is important dudes with pseudo-deep knowledge of git, css, framework-of-the-month and a collection of playbooks, who cannot make a db-enabled hello username message box in less than a day.

Interestingly that is exactly the opposite of my experience. Git is a practical tool with practical appeal to people who want to do practical things. Egghead gedankentheorists hate it, as evidenced by this very subthread.

In point of fact I find the ability to accomplish workaday tasks with git to be a far better predictor of someone's success as a developer than stuff like being able to recite Rust minutiae. People who like git are people who like getting stuff done.

Re: Beej's Guide to Git

#189

Post by patchd »

beej71 wrote: post #30

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

Not wrong, but worth mentioning. I really found git worktrees to be crucial to my workflow and have heard very few people mention them or even know they exist. Excellent way to keep your branches from getting their streams crossed without the headache of dealing with stashes.

Re: Beej's Guide to Git

#190

Post by woodrowbarlow »

beej71 wrote: post #30

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

joining the crowd to say thank you. i've been using your materials for over a decade.

in my experience, strong writing and communication skills are one of the best ways to stand out as an engineer -- and your articles are maybe the best example of this out there. keep on setting a great example for us. :)

Post reply on HN