Live data from Hacker News

Shit – An implementation of Git using POSIX shell

git.sr.ht

151–160 of 235 posts

Re: Shit – An implementation of Git using POSIX shell

#151

Hiya HN. I was ranting on Mastodon earlier today because I feel like people learn git the wrong way - from the outside in, instead of the inside out. I reasoned that git internals are pretty simple and easy to understand, and that the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. I said that the internals were so simple that you could implem…

Would you say if the data format was say JSON, YAML or TOML or any more human and bash friendly format it would have been easy to implement with your current experience? Not to vouch for having Git store things in human format. But I often think about how inefficient JSON API's and YAML storage formats are (in parse time) just to be a benefit of a user debugging it or discovering the API through a browser. But since…

> what is the benefit of the line format being character strings? Wouldn't a binary package not be just as easy translatable into human readable JSON formatted output as a compacted JSON string is?

One benefit is that I can look at an arbitrary file/response and be able to tell with a fairly high certainty whether it's JSON, YAML, or TOML, but there's no way that I tell whether it's messagepack, bson, or protobufs.

Re: Shit – An implementation of Git using POSIX shell

#152
post #135

Earlier quoted context omitted.

Go learn it properly, otherwise you'll be one of the 'users' that, at best, will be stumped on trivial issues, losing productivity and running to others for help. At worst, you'll be making bad decisions and dragging down your team. I have no problem with people on my team asking each other for help, and I definitely don't consider it bad for productivity when they do. If someone on my team suggested people asking th…

I think the point was "trivial issues". What if a Java programmer kept asking their teammates if the statement terminator in Java is colon or semicolon?

Users can resolve trivial issues without knowing the internals though, so that wouldn't make sense.

Re: Shit – An implementation of Git using POSIX shell

#154

Earlier quoted context omitted.

Would you say if the data format was say JSON, YAML or TOML or any more human and bash friendly format it would have been easy to implement with your current experience? Not to vouch for having Git store things in human format. But I often think about how inefficient JSON API's and YAML storage formats are (in parse time) just to be a benefit of a user debugging it or discovering the API through a browser. But since…

> what is the benefit of the line format being character strings? Wouldn't a binary package not be just as easy translatable into human readable JSON formatted output as a compacted JSON string is? One benefit is that I can look at an arbitrary file/response and be able to tell with a fairly high certainty whether it's JSON, YAML, or TOML, but there's no way that I tell whether it's messagepack, bson, or protobufs.

Most of the time you know the format you expect to decode you don't have to guess it anyway.

But I think you should be able to detect the type of format for binary encodings just as well as there spec is pretty specific. Maybe not at glance as a human, but that is the point I'm making. Should all line formats be made absolute human readable and parsable at glance just to the benefit of debugging at the cost of performance. Where with just a simple lens tool you can look at the data in a completely different (human friendly) view. Tools like this already exist in the form of WireShark, only they mostly operate at a deeper level.

Re: Shit – An implementation of Git using POSIX shell

#155

Amusing, but less than the title suggests (no porcelain, no reliability properties, no error checking, etc). Still, fun stuff.

Interesting terminology, I'd never heard of porcelain in the context of git. In case there are others like me, this will save some clicking: https://stackoverflow.com/q/6976473/293064

Am I reading that correctly? A porcelain command is one that's not supposed to be used in scripts, but the --porcelain flag is for when you do want to use things in scripts?

Re: Shit – An implementation of Git using POSIX shell

#156
post #134

Earlier quoted context omitted.

I think the problem is the idea of 'tooling'. A table saw by itself is mostly useless. With a fence and a miter gauge, it becomes useful. With a push block, stop block, subfence, outfeed table, infeed table, featherboard, crosscut sled, tenon jig, and dado set, it is the single most useful tool in a woodshop. Keep in mind it is still one tool and all those accessories are not "tooling", they are accessories to a sing…

I think you're saying that "creating home made tooling is a waste of time, and you should just use professional tools"? In which case I agree, for almost all cases. A carpenter trying to build their own saw or chisel would be laughed out of the workshop, and rightly so. However, the mark of a master craftsman is one who can identify when custom tooling are necessary and knows something about how to build them.

In my opinion, this is simply an over-extended metaphor. Programming ultimately is not carpentry, and custom tooling is justifiable in many more cases.

Re: Shit – An implementation of Git using POSIX shell

#157

Earlier quoted context omitted.

I try to avoid proprietary services.

You know, YouTube is pretty easy. I bet someone could implement it in an afternoon and a dozen lines of shell script...

Is this a challenge?

Re: Shit – An implementation of Git using POSIX shell

#158
post #149

Earlier quoted context omitted.

metaphors. Not being pedantic, it just puzzled me a while to see what was wrong with that word.

what do you get when you cross a metaphor and a semaphore? a metaphore

So it's a metaphor that only a limited amount of people can use at any given time?

Re: Shit – An implementation of Git using POSIX shell

#159
post #127

Hiya HN. I was ranting on Mastodon earlier today because I feel like people learn git the wrong way - from the outside in, instead of the inside out. I reasoned that git internals are pretty simple and easy to understand, and that the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. I said that the internals were so simple that you could implem…

If it's so hard to learn about this tool and so easy to learn about it the wrong way, that's a pretty obvious hint that there's something wrong with the tool. Having to learn about the internals is a giveaway that the tool suffers from poor encapsulation. To me git is definitely one of those tools where one should satisfice and not learn it deeply, because it's not worth the effort. One can successfully stick to a si…

>that's a pretty obvious hint that there's something wrong with the tool.

Or that the problem space is inherently difficult.

Re: Shit – An implementation of Git using POSIX shell

#160

Earlier quoted context omitted.

You'll use git a hundred times a day, every day, for the rest of your career. It's easily worth the hour it'll take to learn it properly.

Sure, but I also use a mouse. I could learn how the optical mouse works. I have some guesses about it too, but never actually learned the details. But I'm a user of it - it works even if I don't understand exactly how and nobody tells me that I learned using the mouse "the wrong way" because of it.

And the other IO device? People absolutely will tell you you're typing the wrong way.
Post reply on HN