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

91–100 of 235 posts

Re: Shit – An implementation of Git using POSIX shell

#91

Post by gruez »

chenhan wrote: post #73
chx wrote: post #44

Earlier quoted context omitted.

> the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. Agreed. I always said the best git tutorial is https://www.sbf5.com/~cduan/technical/git/ > The conclusion I draw from this is that you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s…

I never really understood Git until I read this tutorial: https://github.com/susam/gitpr Things began to click for me as soon as I read this in its intro section: > Beginners to this workflow should always remember that a Git branch is not a container of commits, but rather a lightweight moving pointer that points to a commit in the commit history. A---B---C ↑ (master) > When a new commit is made in a branch, its bra…

>This "moving pointer" model of Git branches led me to instant enlightenment.

As opposed to any other VCS? Feels like that model is the only one that works with SVN too. I struggle to see how "branch is a container of commits" is a viable model to begin with.

Re: Shit – An implementation of Git using POSIX shell

#92

Post by Hello71 »

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…

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 16 bits instead of 32. the latter issue can be easily fixed by explicitly specifying -td2/-td4, but the former issue is not so easy. I think it requires either figuring out the endianness beforehand, or better, something like this:

    od -An -tx1 -j"$offs" -N4 "$path" | while read a b c d; do
     echo $(((0x$a
oddly, this is used in ls-files already. and yes, I checked: 0x$a is POSIX, and the arithmetic evaluation size must be at least a signed long, which is at least 32 bits.

'for x in $y; do printf "$a%s$b" "$x"; done' is equivalent to 'printf "$a%s$b" $y' (assuming neither a nor b contain format specifiers). similarly, 'for i in {1..100}; do printf "$a"; done' is equivalent to 'printf "$a%s.0" {1..100}'. unfortunately, brace expansion is not POSIX, but these are both significantly more efficient (both in code size and execution time) than the loop methods.

sha1sum is not POSIX. I think shell arithmetic provides you enough tools to implement https://en.wikipedia.org/wiki/SHA-1#SHA-1_pseudocode directly, although it may be slightly slower than a C implementation. awk is probably faster than shell.

Re: Shit – An implementation of Git using POSIX shell

#94

Post by Izkata »

chenhan wrote: post #73
chx wrote: post #44

Earlier quoted context omitted.

> the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. Agreed. I always said the best git tutorial is https://www.sbf5.com/~cduan/technical/git/ > The conclusion I draw from this is that you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s…

I never really understood Git until I read this tutorial: https://github.com/susam/gitpr Things began to click for me as soon as I read this in its intro section: > Beginners to this workflow should always remember that a Git branch is not a container of commits, but rather a lightweight moving pointer that points to a commit in the commit history. A---B---C ↑ (master) > When a new commit is made in a branch, its bra…

And you can see this structure if you add to any "git log" command "--graph --oneline --decorate --color". IIRC some of those are unnecessary in recent versions of git, I just remember needing all of them at the point I started using it regularly.

I have a bash function for it (with a ton of other customizations, but it boils down to this):

  function pwlog() {
    git log "$@" --graph --oneline --decorate --color | less -SEXIER
  }
  pwlog --all -20
(...in that "less" command, "S" truncates instead of wraps lines, one "E" exits at EOF, "X" prevents screen-clearing, and "R" is to keep the color output. The second "E" does nothing special, it and "I" (case-insensitive search) are just to complete the word)

Re: Shit – An implementation of Git using POSIX shell

#95

Post by Izkata »

gruez wrote: post #91
chenhan wrote: post #73

Earlier quoted context omitted.

I never really understood Git until I read this tutorial: https://github.com/susam/gitpr Things began to click for me as soon as I read this in its intro section: > Beginners to this workflow should always remember that a Git branch is not a container of commits, but rather a lightweight moving pointer that points to a commit in the commit history. A---B---C ↑ (master) > When a new commit is made in a branch, its bra…

>This "moving pointer" model of Git branches led me to instant enlightenment. As opposed to any other VCS? Feels like that model is the only one that works with SVN too. I struggle to see how "branch is a container of commits" is a viable model to begin with.

It's a good-enough description of SVN, where branches exist in the same directory tree, commits are tied to the branch by way of the path, and the merge tools are "merge this batch of commits from branch A to trunk" (you don't have to take the whole branch at once).

One of the biggest hurdles my co-workers have had learning git after having used svn for years is the "bucket of commits" mental model they've built up for branches. A common question is how to merge a single commit.

Re: Shit – An implementation of Git using POSIX shell

#96

Post by rswail »

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.

What's the difference between a stash and a "working tree as a commit"?

Re: Shit – An implementation of Git using POSIX shell

#97

Post by efreak »

peterwwillis wrote: post #87
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…

Still more sane than JavaScript to me. Would use this over a 500MB Node.js implementation.

Is this a reference to something? I can't imagine it would take 500mb to reimplement git in JavaScript. This one's https://github.com/maryrosecook/gitlet

Re: Shit – An implementation of Git using POSIX shell

#98

Post by peterwwillis »

angry_octet wrote: post #63
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…

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 single tool that increase what you can do with it. The tool always works the same way, and anyone can use it with any of those accessories in any woodshop in the world. In effect it becomes a new, larger solution, made up of many features that extend the utility of the tool.

That's not really what we have. Mostly what we have are jigs. A jig isn't an outfeed table or a crosscut sled. It's a hack for a particular job. If you need to make one specific cut 300 times, you nail together some scrap wood, dial in the miter gauge, angle the saw blade, and make your cuts. And the jig is scrap once again.

But in the heady new world of "DevOps engineering", the jig is now "tooling", and we pat ourselves on the back that we were able to nail some scrap wood together and claim it created business value. Of course, it's not a shitty jig like in the bad old days of shell scripts ("ha ha! remember when we were productive with this simple code that was portable and not gigantic or complicated? how foolish!"), because instead of making it out of scrap wood, we now make it out of scrap steel with a MIG welder. We're advanced now.

And I'll go further. The fact that most woodworkers make their own tablesaw extensions is illustrative of the problem: craftspeople like having fun with their toys. Is there value and experience and dollar savings you get out of making your own crosscut sled? Sure! But it'll also take you 1-2 days of buying parts, measuring, cutting, gluing, clamping, drying, aligning, and finishing. Any business with any sense should have paid $100 to just buy a complete crosscut sled made of aluminum with a good design that will last forever. But they are too dumb to notice they're spending an inordinate amount of time and money on craftspeople making jigs.

I wish the ghost of W. Edwards Deming would rise from the grave and call us what we are: bullshit artists.

Re: Shit – An implementation of Git using POSIX shell

#99

Post by rileymat2 »

gruez wrote: post #91
chenhan wrote: post #73

Earlier quoted context omitted.

I never really understood Git until I read this tutorial: https://github.com/susam/gitpr Things began to click for me as soon as I read this in its intro section: > Beginners to this workflow should always remember that a Git branch is not a container of commits, but rather a lightweight moving pointer that points to a commit in the commit history. A---B---C ↑ (master) > When a new commit is made in a branch, its bra…

>This "moving pointer" model of Git branches led me to instant enlightenment. As opposed to any other VCS? Feels like that model is the only one that works with SVN too. I struggle to see how "branch is a container of commits" is a viable model to begin with.

This is closer to how I would describe HG and SVN. Branches can be traced from start to merge, they are heavy. You know which commits came from what.

In git you can lose track of what came from what branch when you start merging multiple back and forth, this does happen with svn.

Re: Shit – An implementation of Git using POSIX shell

#100

Post by viraptor »

kick wrote: post #78
oefrha wrote: post #66

Earlier quoted context omitted.

Storage is cheap. It’s the delivery that’s costly.

Delivery being costly is a myth propagated by Big Cloud®. Any dollar store VPS that isn't DO will have more than enough for streaming video all day every day. That's irrelevant, though, given the person's question was about storage and archival.

It all depends on the use-case/context. Hosting a single video with few concurrent views is cheaper to do on VPS. Hosting videos with short response time in any region, with high resiliency, etc. is likely cheaper to do on CDNs. It's not a myth. It's "general advice may not work for you".
Post reply on HN