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

251–260 of 318 posts

Re: Beej's Guide to Git

#251

Post by diggan »

maccard wrote: post #244
diggan wrote: post #196

Earlier quoted context omitted.

I'm aware of how to do most of those things in git, but that probably says more about me than git. What I'm curious about though, since I basically entered the software developer workforce just as Git became mainstream and GitHub became popular, how would you do those things with the alternatives at the time; SVN, Mercurial, Perforce and the rest? Would it be easier or harder? Would it work better/worse in a sync/asy…

> without centralized servers? Git is complicated _beacuse_ of this. The defaults are tuned for this. But, most people don't need this. I'm sure there are people out there who set an upstream to their coworkers PC and clone a branch from them, merge it with their work and then someone else takes that and is saved a bunch of work because the commits all line up, but for every 1 of those people there are probably 100,0…

> Git is complicated _beacuse_ of this

Right, but since git specifically was made for usage without decentralized servers, that complexity isn't accidental, it's purposeful as without serving that particular use case, git isn't really git anymore. Most design decisions in git comes from having to serve that use case, for better or worse.

> . It's _so_ much simpler - because it's centralized

Right, but that's also a poor comparison. A bit like saying that `mv` is much simpler than `rsync` because `mv` always move files locally. Yeah, that's true, but the entire point of `rsync` is to do remote sends/receives, so compared it to something that cannot, kind of ruins the comparison.

Re: Beej's Guide to Git

#252

Post by diggan »

RohMin wrote: post #226
diggan wrote: post #194

Earlier quoted context omitted.

> 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…

git switch focuses on switching branches while git checkout extends further than that

Right, so for the folks at home who already know and use `git checkout`, no switch needed (no pun intended) as everything already works fine and probably won't be deprecated in the near future.

Re: Beej's Guide to Git

#254

Post by forrestthewoods »

crabbone wrote: post #211
forrestthewoods wrote: post #153

Earlier quoted context omitted.

I appreciate your hatred of Perforce. But I think you've let your hatred blind yourself to the argument I actually made. In my original comment I made two arguments: 1. Git is complicated 2. Perforce is so simple to use that I can teach an artist or designer who has never even heard of source control how to use it in 10 minutes. Then you came in and said the way Perforce handles read-only files is stupid. You know wh…

To teach someone to use something, in my mind, means that that someone should be able to use whatever they were taught. After 10 minutes, the person unfamiliar with Perforce, will not know how to deal with read-only files. No chance of that happening.

I wish you didn’t ignore the majority of my comment to focus on one tiny part. :(

But yes it does literally include that. Perforce is THE standard tool for gamedevs. It’s not hard.

Re: Beej's Guide to Git

#255

Post by maccard »

diggan wrote: post #251
maccard wrote: post #244

Earlier quoted context omitted.

> without centralized servers? Git is complicated _beacuse_ of this. The defaults are tuned for this. But, most people don't need this. I'm sure there are people out there who set an upstream to their coworkers PC and clone a branch from them, merge it with their work and then someone else takes that and is saved a bunch of work because the commits all line up, but for every 1 of those people there are probably 100,0…

> Git is complicated _beacuse_ of this Right, but since git specifically was made for usage without decentralized servers, that complexity isn't accidental, it's purposeful as without serving that particular use case, git isn't really git anymore. Most design decisions in git comes from having to serve that use case, for better or worse. > . It's _so_ much simpler - because it's centralized Right, but that's also a p…

You’re looking for someone to suggest an alternative to a DVCS - git is the winner in that category. But if you go one step backwards and ask “do you really need distributed”, the answer for the vast, vast, vast majority of people is no, for the vast vast majority of use cases. To use your analogy it’s as if we all used rsync because it’s the best remote file management tool, but we use it locally because everyone else uses it.

Re: Beej's Guide to Git

#256

Post by sampullman »

crabbone wrote: post #218
sampullman wrote: post #137

Earlier quoted context omitted.

I'm not totally sure what you mean by "non-automated" here, can you clarify? I have managed repos for small teams, that's actually the majority of my experience with it. I do deal with multiple remotes quite often and haven't encountered issues. You're right about submodules, I avoid setting up projects with them, even at the expense of more manual work or complicated automation. I'm definitely not using it as a subs…

> non-automated Here are some examples: We have some repositories that are created and maintaned by scripts, mostly for CI purposes. The scripts have to deal with various aspects of how checkouts, commits, automatic rebases etc. are done. For example, I had to write a script that automates "git-rebase -i" (simulating the editor, parsing the contents of the file that git generates in order to configure the rebase etc.…

Hm, I think you've mischaracterized me then. I do plenty of funny stuff with git in CI, but am usually able stick to modifying the repo in the way humans do. Maybe this is why I've mostly avoided edge cases over the years.

Though I have to say, for your examples (generating statistics and automated builds), read-only operations generally suffice for me, aside from pushing tags. I prefer to implement pull-based deployment if possible, and only allow release branches to fast-forward.

Re: Beej's Guide to Git

#258

Post by capitainenemo »

maccard wrote: post #255
diggan wrote: post #251

Earlier quoted context omitted.

> Git is complicated _beacuse_ of this Right, but since git specifically was made for usage without decentralized servers, that complexity isn't accidental, it's purposeful as without serving that particular use case, git isn't really git anymore. Most design decisions in git comes from having to serve that use case, for better or worse. > . It's _so_ much simpler - because it's centralized Right, but that's also a p…

You’re looking for someone to suggest an alternative to a DVCS - git is the winner in that category. But if you go one step backwards and ask “do you really need distributed”, the answer for the vast, vast, vast majority of people is no, for the vast vast majority of use cases. To use your analogy it’s as if we all used rsync because it’s the best remote file management tool, but we use it locally because everyone el…

My favourite rant on this subject. https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs...

Now svn does have things I miss from the Mercurial world.. grep --all, fa --deleted, revsets, phases.. some could be implemented serverside in svn, but svn dev lost a lot of momentum post-DVCS (git esp).

But DVCS has issues that aren't an issue in svn land. History consistency, simple reliable narrow/shallow, people can work on files independently without syncing. (and a significantly more complex dvcs process)

Re: Beej's Guide to Git

#259

Post by alexjm »

ericholscher wrote: post #199
aidos wrote: post #148

Earlier quoted context omitted.

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.

I usually use :q! which seems to do the same thing

The minor difference is that :q! quits without saving but returns zero as the exit code, but :cq quits with a nonzero exit code. Git interprets the nonzero exit code as "editing failed", following the Unix convention that zero means success. If you didn't save the commit message while working on it, :q! will send the empty template back to Git, which Git is smart enough to not commit. But if you accidentally save your work partway through, :q! will still commit the message you wanted to abandon.

Re: Beej's Guide to Git

#260

Post by mbonnet »

vvpan wrote: post #14
dijit wrote: post #3

Well, what's terrifying is that the guide is so long . I am aware that beej's guides are typically quite comprehensive, but the vast nuances of git truly eluded me until this. I guess Jujitsu would wind up being a much slimmer guide, or at least one that would be discoverable largely by humans?

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

git can suck, but it's the best tool we've got for the job.
Post reply on HN