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

Shit – An implementation of Git using POSIX shell

git.sr.ht

Post reply on HN
Print view View original

101–110 of 235 posts

Re: Shit – An implementation of Git using POSIX shell

#101

Post by na85 »

ddevault wrote: post #49
viraptor wrote: post #45

Earlier quoted context omitted.

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.

A typical mouse has 2-3 buttons, a wheel, and an X/Y axis. Git is 100x more complex, if not more. Give me a break. I'm sick of people glamorizing the idea that you should have your hand held through each step of every tool you use and never expend any effort on becoming an expert in the tools of your trade. Git is an engineering tool, designed by and for professionals. Imagine this kind of obscene complatency in othe…

I don't think it's asking to have one's hand held to complain about git's poor interface. There's no reason other than lazy design to have a tool where to show all remotes it's

$ git remote -v

But to show all branches it's

$ git branch -a

It's like it's been purposefully designed to be obtuse.

Re: Shit – An implementation of Git using POSIX shell

#102

Post by Izkata »

jaytaylor wrote: post #50
downerending wrote: post #9

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

And then there's random stuff like "git status --porcelain", an easily-parsed version of "git status"

Re: Shit – An implementation of Git using POSIX shell

#103

Post by kortilla »

iamEAP wrote: post #53

I once landed a job as a web developer in a marketing department where IT was gatekeeping production hard. Although all the code was in git (the real git), deployment involved a magical shell script someone in IT had written ages ago. Only after a bunch of rocky, outage-causing deployments did we have the sense to start digging into this magic script. It turned out it was just a bad, thousands of lines long re-implem…

Sounded like you traded one incompetence for another. Why in the world would you gatekeep your deployment on an external service?

Re: Shit – An implementation of Git using POSIX shell

#104

Post by RJIb8RBYxzAMX9u »

ddevault wrote: post #29
viraptor wrote: post #28

Earlier quoted context omitted.

> I feel like people learn git the wrong way Why do you think it's the wrong way? I sit somewhere in between and think that some people want to know the details and learning from inside is a good idea. But some other people want to simply be users and for the tool to get out of their way - and that's also good . So if the docs or the UX make either way hard or less effective, that's on the docs or the UX to improve.

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.

I'm not certain that git will be the dominant VCS forever, as I'd used CVS, Perforce, Subversion, Mercurial, in various degrees when they were dominant (or at least relevant).

Who knows, maybe Linus will have another epiphany, while Microsoft somehow mismanages GitHub and squanders all the goodwill away. Then, a group of upstarts...

That said, wanting to learn git's internals for the sake of knowledge is fine as motivation.

Re: Shit – An implementation of Git using POSIX shell

#106

Post by aspaceman »

na85 wrote: post #101
ddevault wrote: post #49

Earlier quoted context omitted.

A typical mouse has 2-3 buttons, a wheel, and an X/Y axis. Git is 100x more complex, if not more. Give me a break. I'm sick of people glamorizing the idea that you should have your hand held through each step of every tool you use and never expend any effort on becoming an expert in the tools of your trade. Git is an engineering tool, designed by and for professionals. Imagine this kind of obscene complatency in othe…

I don't think it's asking to have one's hand held to complain about git's poor interface. There's no reason other than lazy design to have a tool where to show all remotes it's $ git remote -v But to show all branches it's $ git branch -a It's like it's been purposefully designed to be obtuse.

We're all talking about learning the internals of git and how it works, not it's poorly formed command lines. Pointing out how shitty the interface can be doesn't mean you shouldn't learn how your tools work.

Re: Shit – An implementation of Git using POSIX shell

#107

Post by kakakiki »

ddevault wrote: post #22

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…

Couldn't resist looking at it after your repeated warnings. It seems that shellcheck site has some suggestions to improve the code.

Re: Shit – An implementation of Git using POSIX shell

#108

Post by cweagans »

im3w1l wrote: post #43
ddevault wrote: post #29

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.

It's not a given you will use it for the rest of your career. As two examples, neither Google nor Facebook use git.

shrug I'm probably never going to work at either of those places. For pretty much everywhere else, Git works just fine.

Maybe if I play my cards right, I'll use git for the rest of my career. If not, maybe there will be something new eventually, but I imagine that the concepts learned in mastering Git would still be useful.

Re: Shit – An implementation of Git using POSIX shell

#109

Post by _ikke_ »

deathanatos wrote: post #69
ddevault wrote: post #39

Earlier quoted context omitted.

I wanted to have the staging area, and I had decided upfront that I wouldn't make the repository state inconsistent between shit and git. So the index needed to be done. Also, you need to generate a tree out of something. Could just hash the entire worktree every time, but that would be pretty lame.

What I never fully understood is why the staging area isn't simply a commit that gets amended repeatedly as files are staged into it. Maybe just a tree pointer, since the rest of the commit data isn't available until commit, but you could fill in some placeholders. ("(staging)" for the message, current times for the timestamps, etc.) (Note that index doubles for other functions like merging/conflict resolution, but I…

The 'staging' area is implemented through the index. And the index is used for more things then just deciding what gets in the next commit. A lot of gits speed comes from caching Stat data of files so that it does not have to hash the complete working tree for each operation. That's not something you can just ignore.

Someone proposed splitting this up the other day, but even that would come at the cost of performance and an increase of complexity.

Re: Shit – An implementation of Git using POSIX shell

#110

Post by _ikke_ »

smichel17 wrote: post #83
deathanatos wrote: post #69

Earlier quoted context omitted.

What I never fully understood is why the staging area isn't simply a commit that gets amended repeatedly as files are staged into it. Maybe just a tree pointer, since the rest of the commit data isn't available until commit, but you could fill in some placeholders. ("(staging)" for the message, current times for the timestamps, etc.) (Note that index doubles for other functions like merging/conflict resolution, but I…

I've wanted this for a long time, and also a frequently-amended working-tree-as-a-commit. Why? I prefer a each branch to have its own staging area and working tree, which maps better to my mental model of "branch as an under-development feature". Currently my workflow to achieve this involves a lot of stashing.

Do you know about git worktree? Because that sounds exactly what you want. Each worktree has its own index (staging area) and working tree.
Post reply on HN