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

211–220 of 318 posts

Re: Beej's Guide to Git

#211

Post by crabbone »

forrestthewoods wrote: post #153
crabbone wrote: post #146

Earlier quoted context omitted.

So, there's a difference between how problems are common, how many of them are there, and how hard it is to deal with them. So, is it possible to deal with Perforce marking files read-only? -- Yes. And it's not complicated, but the whole idea that that how the system should work is stupid. The problem is, however, exceptionally common. In my days working with Perforce there hadn't been a day when this problem didn't…

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.

Re: Beej's Guide to Git

#212

Post by crabbone »

maccard wrote: post #139
crabbone wrote: post #124

Earlier quoted context omitted.

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…

> I don't know why Git won the VCS contest Because GitHub offered free git hosting, and heroku came along and offered free hosting that was pretty much point and go. Combined, you all of a sudden went from needing a sysadmin and two servers (this was pre containers), and the sysadmjn skills to operate SVN and your web app, to “it’s now free and it auto deploys when I commit”.

Bitbucket offered free Mercurial hosting before GitHub even existed, if memory serves. And it's all but dead.

And, I don't know if GitHub succeeded because of Git or the other way around.

Re: Beej's Guide to Git

#215

Post by chuckadams »

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…

> I don't know why Git won the VCS contest.

Because Mercurial was dreadfully slow at the time for anything as big as the Linux kernel tree. Linus also put his thumb on the scale because he was the author and still the primary maintainer of git at the time, so he could bend it to whatever shape he wanted without needing to ask anyone else. Not really a knock on Linus, I'd do the same in his position, but it does explain much of its advantage.

Re: Beej's Guide to Git

#216

Post by [deleted] »

gitgood wrote: post #90
forrestthewoods wrote: post #73

Earlier quoted context omitted.

Honestly? I’m not sure. Here’s the problem: 1. it’s possible to get into a bad state 2. it’s not clear what exactly that state is 3. it’s not clear how you got into that state 4. it’s not clear how to get out of it I understand Git reasonably well. I know a good bit how it works under the hood. When I have a gitastrophe I rarely understand what I did wrong and how to avoid it in the future. Here’s a recent post from…

You've just described computers. It's possible to get into a bad state because git can't read your mind, and, at the end of the day, it is incumbent upon you, the programmer, to make the computer do what you want. That is our responsibility as practitioners. You need to think about what you're actually trying to accomplish, and that requires having a mental model of how the tool works. And no, I don't mean under the…

[deleted]

Re: Beej's Guide to Git

#217

Post by chuckadams »

gitgood wrote: post #90
forrestthewoods wrote: post #73

Earlier quoted context omitted.

Honestly? I’m not sure. Here’s the problem: 1. it’s possible to get into a bad state 2. it’s not clear what exactly that state is 3. it’s not clear how you got into that state 4. it’s not clear how to get out of it I understand Git reasonably well. I know a good bit how it works under the hood. When I have a gitastrophe I rarely understand what I did wrong and how to avoid it in the future. Here’s a recent post from…

You've just described computers. It's possible to get into a bad state because git can't read your mind, and, at the end of the day, it is incumbent upon you, the programmer, to make the computer do what you want. That is our responsibility as practitioners. You need to think about what you're actually trying to accomplish, and that requires having a mental model of how the tool works. And no, I don't mean under the…

I appreciate that you are at least honest enough to name your shill account for what it is.

Re: Beej's Guide to Git

#218

Post by crabbone »

sampullman wrote: post #137
crabbone wrote: post #121

Earlier quoted context omitted.

You are using Git in a non-automated way, basically, as a substitute for rsync (you never edit history, you only append to it, you don't deal with a possibility of multiple remotes, you don't deal with modular projects and you don't automate anything). At least, this is what it looks like from your own description. This is, probably, what most people do with it most of the time. And the weird corners will be found wh…

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.)

Another example: generating various statistics for the repository (again, automatically). This is something we used to do to analyze the situation with build servers: how many do we need, how to load-balance them etc.

Another example: automated builds, where the build system needs to integrate with Git, extracting necessary info, rebasing, committing, parsing commit messages for guidance etc.

> rsync

What I mean by this is that most programmers use Git as an append-only database. And, by and large, aren't bothered by the state of the history, never utilize the history for anything. As long as they are all able to access the source code in some sort of sane state, they are fine.

This creates a lot of problems for the automation / infra / release people because they want history to have certain properties, which are lost if it's treated as append-only log, but usually our pleas are ignored if they are even heard.

Re: Beej's Guide to Git

#219

Post by jayd16 »

maccard wrote: post #141
crabbone wrote: post #125

Earlier quoted context omitted.

Why I agree with many points you make... let's keep Perforce out of it. The amount of damage that program done to my source code, and the amount of pain caused by it in daily use tells me that 10 minutes will not cut it. Here's a simple example of how people shoot themselves in the foot with Perforce all the time: it makes files you edit read-only, and then you run with your pants on fire trying to figure out how to…

Why does git get a free pass for shitty defaults but perforce doesn’t? Perforce long predates git, and the checkout operation (which can be done on save with any modern editor) fixes that immediately.

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.

Re: Beej's Guide to Git

#220

Post by martinvonz »

forrestthewoods wrote: post #129
sunshowers wrote: post #123

Earlier quoted context omitted.

Why not switch forward to Jujutsu? It's simpler and more powerful than Git.

I've been using Jujutsu a little and over the weekend lost a bunch of files. I'd been working happily in an anonymous branch. I had a bunch of content in a thirdparty folder that was hidden by .gitignore. I couldn't figure out how to merge my anonymous branch into master. Somehow wound up on the old master and it deleted all of my gitignored files. Then jj status got totally fubar and couldn't complete in under 5 min…

When updating the working copy from one commit to another, I didn't think we would delete files that were not untracked in the first commit. I suspect the files are actually still available in the repo, but we'd appreciate a bug report if you can reproduce the problem.

The other issue you ran into with ignored files becoming tracked is a known limitation. I agree that it's really annoying. We have talked about it many times before but we didn't have a proper issue for tracking it, so I created one now: https://github.com/jj-vcs/jj/issues/5596

Post reply on HN