Live data from Hacker News

Shit – An implementation of Git using POSIX shell

git.sr.ht

211–220 of 235 posts

Re: Shit – An implementation of Git using POSIX shell

#211
post #93
post #18

This is great, but I already use "shit" as an alias for "fuck".

I’m just here to support the four people that have a sense of humor on HN.

To be fair, humor (on its own) is often detrimental to HN discussions. At least as top level comments.

But for a toy project like this, it seemed appropriate.

Re: Shit – An implementation of Git using POSIX shell

#212
post #82
post #18

This is great, but I already use "shit" as an alias for "fuck".

Do you type dvorak? I have the same exact alias for that reason.

No, I could never get the hang of Dvorak.

I have it because when I make a command line mistake, I more often say "shit" than "fuck". It feels more natural to type what I'm actually thinking. :)

Re: Shit – An implementation of Git using POSIX shell

#213

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…

You know that Linus wrote first version of git in mostly bash, right?

Re: Shit – An implementation of Git using POSIX shell

#214
post #200

Earlier quoted context omitted.

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

No, it’s not. Commit hashes are exactly what it says on the tin: hash sums of commit objects, which are basically text files that include hash sums of tree objects (directory tree state), hash sums of parent commits, your commit message and other metadata. You can see it with "git cat-file":

    $ git cat-file -p d8defd0bb0062ed541de173a2aec834b64d6adbe
    tree cbdb56fe9bb1766d8fc2b2e53c9c934efbacbf1c
    parent a8a1049c06d100a3f926a82414e6addb9b9af5e8
    author ilammy  1581533224 +0200
    committer ilammy  1581533224 +0200
    
    fixup! Avoid unsigned overflow in length computations
And compute the commit hash manually to verify that:

    $ sha=d8defd0bb0062ed541de173a2aec834b64d6adbe
    $ cat 
Git prefixes object content with object type ("commit" in case of commits), its size in bytes (textual, decimal), terminated by a null byte. And hashes all of that get the commit hash.

Re: Shit – An implementation of Git using POSIX shell

#215
post #94
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…

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 -…

You can also set $GIT_PAGER/core.pager/$PAGER and create an alias to accomplish this:

  #export PAGER='less -SEXIER'
  #export GIT_PAGER='less -SEXIER'
  git config --global core.pager 'less -SEXIER'
  git config --global alias.l 'log --graph --oneline --decorate --color'
  # git diff ~/.gitconfig
  git l
core.pager: https://git-scm.com/docs/git-config#Documentation/git-config...

> The order of preference is the $GIT_PAGER environment variable, then core.pager configuration, then $PAGER, and then the default chosen at compile time (usually less).

Re: Shit – An implementation of Git using POSIX shell

#216
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.

Th specific part that I understood as your argument for non-POSIX solutions:

"'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."

I didn't understand why you write that part at all, considering the goals of the program we discuss (which is to demonstrate some git primitives in POSIX compliant shell code).

Re: Shit – An implementation of Git using POSIX shell

#217
post #144

What's wrong with people nowadays? Couldn't they come with a better name ?

Git is already an insulting term where I come from - I remember one of our children, years ago when they were young, looking at my screen and saying "why are you typing git ??" in a shocked sort of tone. They're much less concerned about their language now. I don't mean to overstate the case - it's not a swearword or the sort of thing you'd really censor, just a playground term for a mean person. All the same it's an…

Mercurial is also an insult. Both projects were started in response to a mercurial git’s actions.

Re: Shit – An implementation of Git using POSIX shell

#218

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.

many places were fine with cvs and svn as well

Was anyone _really_ fine with cvs?

Re: Shit – An implementation of Git using POSIX shell

#219
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

A semi-metaphor?

Re: Shit – An implementation of Git using POSIX shell

#220
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…

Almost everybody I've ever worked with who complained about Git has a conversation with a coworker that goes something like this:

Coworker: "I really hate Git, it's so hard to understand what's going on internally."

Git guy: "Did you read the documentation?"

Coworker: "Nope."

Git guy: "Did you read Git - book?"

Coworker: "Nope."

Git guy: "Did you read Scott Chacon's 'Pro Git'?"

Coworker: "Nope."

Git guy: "..."

Post reply on HN