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

201–210 of 235 posts

Re: Shit – An implementation of Git using POSIX shell

#201

Post by stefco_ »

jasode wrote: post #161
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…

>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. Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git commands (the "porcelain"). Yes, I know that git is a DAG (Directed Acyclic Gr…

Though git's interface is highly flawed, I do think a good VCS needs to expose more of its storage model to the user (or at least a model isomorphic to it) than most apps.

In vi and Word, you're not worried about state changes outside of saving the current state and, possibly, undoing some number of steps. In a VCS, you might need to check out, merge, or compare arbitrary states from the history, and doing this inherently requires a deeper understanding of how the history is stored. A good VCS should expose these internals in a clear way. In my experience, working with even 1 teammate immediately requires you to have some mental model of how your VCS deals with merging different histories.

That said, it's up to the VCS's interface to make these things clear. Git's mental model is simple enough, and the porcelain can do some of this stuff very well, but CLI is arcane; I end up storing extremely common functions as shortcuts because I'd never remember them or want to type them even though I use them dozens of times a day.

Re: Shit – An implementation of Git using POSIX shell

#202

Post by war1025 »

hurrrrrrrr wrote: post #194
kragen wrote: post #71

Earlier quoted context omitted.

> I don't understand how vim works beyond the base conceptual level How much time have you spent trying to figure out how to change the font size in Vim, rotate text 90° in Vim, recalculate a formula in Vim, or insert an image into a document you're editing in it? If the answer is “none”, you probably have a pretty deep understanding of the data model Vim manipulates, even if you aren't aware of it.

On the other hand I understand de data model of git and can't to the most basic shit without looking up which invocation I need via search engine/man pages. Like... deleting a branch `git branch -d` (-D for forced deletion). Deleting a remote? `git remote rm`. Knowing the model teaches me nothing about the ui.

This seems like a good opportunity to plug two aliases I wrote about a year ago that have been very helpful for cleaning up all the extraneous branches that would show up when I ran `git branch`.

I run `git listdead` after I merge and delete a branch and do the next fetch (`git pull --rebase`). That lists the branches that can now be deleted.

Then I run `git prunedead` and it actually removes them.

Previously if I ran `git branch` it would list every development branch I had ever created in nearly a decade of work. Now it lists maybe ten branches.

   listdead = "!sh -c \"git branch -vv | grep ': gone]' | awk '{print \\$1}'\""

   prunedead = "!sh -c \"git branch -vv | grep ': gone]' | awk '{print \\$1}' | xargs git branch -D\""

Re: Shit – An implementation of Git using POSIX shell

#203

Post by Hello71 »

acqq wrote: post #148
Hello71 wrote: post #92

Earlier quoted context omitted.

eh, common.sh is a lot more complicated than it could be. example: write_hex() { hex="$1" echo "$hex" | sed -e 's/../&\n/' | while read -r hexbyte; do printf "\\x$hexbyte" done } you can imagine other shenanigans with xargs or something, but I think this strikes the best balance between performance and readability (as far as shell script goes). read_int16 and read_int32 don't work on big-endian systems, or if int is…

Such a long text... to end with arguing non-POSIX solution. But the initial goal of the project was having a POSIX code, and it can indeed be a valid goal. So the whole post is "a lot more complicated than it could be." Tl dr: you wouldn't make POSIX code.

what the fuck? I specified POSIX alternatives to non-POSIX uses in the code. only one feature, brace expansion, is not POSIX, so I specifically did not recommend its use.

Re: Shit – An implementation of Git using POSIX shell

#204

Post by compiler-guy »

BossingAround wrote: post #174
im3w1l wrote: post #43

Earlier quoted context omitted.

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

> neither Google nor Facebook use git What do Google and FB use as their VCS? Also, any source? I don't mean this to be an attack, I am just genuinely amazed by the statement.

Google uses a custom implementation of the Perforce interface called Piper. Google has looked at git and mercurial, but have concluded that they can't scale to the level they need it to. Read more about it here:

https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

Re: Shit – An implementation of Git using POSIX shell

#206

Post by TeMPOraL »

ilammy wrote: post #200
navaati wrote: post #173

Earlier quoted context omitted.

Completely agree. > Which in case of Git is that it's a DAG And one step beyond that, that it's a Merkel tree. It's key to understanding stuff like "if I change a commit, it changes all commit after that" or "if I move (cherry pick, rebase) this commit, I'm creating a new one, not really moving".

> And one step beyond that, that it's a Merkel tree. Not really, not every block chain is a Merkle tree. Since Git history is not linear, you can’t order the commits in any canonical way. You definitely can order them in some way (like "git log" does) and then construct a tree for that list of hashes, but this is not really useful computation. Git repo integrity is verified simply by HEAD commit hash because you norm…

Is git even a Merkle tree? Git history forms a DAG, not a tree. But I'm not 100% sure about how the hashes are computed - whether they work on the DAG, or on some local subtree.

Re: Shit – An implementation of Git using POSIX shell

#207

Post by iamEAP »

peterwwillis wrote: post #98
angry_octet wrote: post #63

Earlier quoted context omitted.

I really disagree, a small amount of customisation of tools can reap significant productivity gains. I think your anecdote is really just an example of bad management, not bad tooling. Could easily be that some management doofus had prohibited git from being installed on the 'production' system.

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…

My wife is a woodworker by trade and this metaphor is on-point.

I return to my original point: if your company is working on something where "production" is novel/unique/a differentiator, then you probably need to invest a little time in how you manage and deploy to production (e.g. you need something that's more than just a jig, and you can't go down to the store and buy it because it literally doesn't exist).

There is probably a certain point in scaling an engineering org (maybe 50+ devs) where you inevitably have to devote some engineering time to this anyway (e.g. you adopted/bought a tool that requires non-trivial maintenance and customization).

If, on the other hand, you're working on something where production and deployment are a well-understood--maybe even commoditized domain--then you should direct your precious engineering time elsewhere.

Marketing website infrastructure has its nuances, but it's well-understood. CRUD apps that talk to databases are a similarly well-understood area.

Re: Shit – An implementation of Git using POSIX shell

#208

Post by cweagans »

jschwartzi wrote: post #187
cweagans wrote: post #108

Earlier quoted context omitted.

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.

You should give Mercurial a try. When you enable the changeset editing extensions it does everything Git does and is much easier to use and understand. I’ve trained people on both systems and Mercurial is much less creaky. The only reason everyone uses Git is for historical reasons because most of the modules In referring to weren’t added to Mercurial until like 09 when Git started seeing widespread use.

I used mercurial quite a bit back in 2010. It's nice, but I don't see the value in sinking a bunch of time into it these days.

Every one of the projects that I interact with regularly are in a Git repo on some kind of Git hosting service and the projects are run by people who understand/use Git regularly. For those projects, switching to Mercurial is a net loss, even just considering the time it takes to migrate the codebase + related processes (think CI, issue queue integration, even the repo hosting itself).

Sure, I could use hg-git, but that doesn't gain me much either: now I'm the guy with the weird setup. If something goes wrong with my setup, it's too weird for other people to help with. If something goes wrong with somebody else's setup, I'm not that helpful because I have a weird setup.

Re: Shit – An implementation of Git using POSIX shell

#209

Post by kragen »

hurrrrrrrr wrote: post #194
kragen wrote: post #71

Earlier quoted context omitted.

> I don't understand how vim works beyond the base conceptual level How much time have you spent trying to figure out how to change the font size in Vim, rotate text 90° in Vim, recalculate a formula in Vim, or insert an image into a document you're editing in it? If the answer is “none”, you probably have a pretty deep understanding of the data model Vim manipulates, even if you aren't aware of it.

On the other hand I understand de data model of git and can't to the most basic shit without looking up which invocation I need via search engine/man pages. Like... deleting a branch `git branch -d` (-D for forced deletion). Deleting a remote? `git remote rm`. Knowing the model teaches me nothing about the ui.

Myself, I frequently refer to the man pages, as well as StackOverflow.

Re: Shit – An implementation of Git using POSIX shell

#210

Post by acqq »

Hello71 wrote: post #203
acqq wrote: post #148

Earlier quoted context omitted.

Such a long text... to end with arguing non-POSIX solution. But the initial goal of the project was having a POSIX code, and it can indeed be a valid goal. So the whole post is "a lot more complicated than it could be." Tl dr: you wouldn't make POSIX code.

what the fuck? I specified POSIX alternatives to non-POSIX uses in the code. only one feature, brace expansion, is not POSIX, so I specifically did not recommend its use.

I’m sorry if I misunderstood you. I’m indeed interested in what from all you wrote is then what you would suggest to be changed, as I also looked at his code and also read here that it was done in short time so I also believer there are possibilities for improvement. Specifically, reimplementing sha calculation itself should be a non goal, in my opinion. Just that the .sh code itself works on all POSIX shells, not that the whole system has to be POSIX only: calculating sha in shell is surely not the point of demonstrating how git works.
Post reply on HN