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.
But for a toy project like this, it seemed appropriate.
211–220 of 235 posts
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.
But for a toy project like this, it seemed appropriate.
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.
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. :)
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…
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.
$ 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.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 -…
#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).
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.
"'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).
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…
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
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…
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: "..."