10/10 on wordplay
It's cute, but it negatively impacts my ability to effectively advocate for the tool in my workplace.
Shit – An implementation of Git using POSIX shell
81–90 of 235 posts
Re: Shit – An implementation of Git using POSIX shell
#82This 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.
Re: Shit – An implementation of Git using POSIX shell
#83Earlier 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…
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.
Re: Shit – An implementation of Git using POSIX shell
#84Earlier 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…
> A branch is merely a pointer to the tip of a series of commits.
But this is not actually correct because a branch can often point to a commit that is not the tip.
Re: Shit – An implementation of Git using POSIX shell
#85Earlier 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…
> A branch is merely a pointer to the tip of a series of commits. But this is not actually correct because a branch can often point to a commit that is not the tip.
I think I see what it means though. The branch uses that commit as a new tip to then branch off of, not necessarily meaning a new branch starts at the existing 'tip'.
Re: Shit – An implementation of Git using POSIX shell
#86Hiya 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…
Git internals are fine. Now, if the utils gave access to human-oriented operations with those internals without the user googling every time they need something not-yet-memorized, that would be splendid. As it is, the utils are already pretty shitty without a reimplementation.
Re: Shit – An implementation of Git using POSIX shell
#87Hiya 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.
Re: Shit – An implementation of Git using POSIX shell
#88[deleted]
Re: Shit – An implementation of Git using POSIX shell
#89Earlier 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.
[deleted]
Re: Shit – An implementation of Git using POSIX shell
#90Earlier 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…
> A branch is merely a pointer to the tip of a series of commits. But this is not actually correct because a branch can often point to a commit that is not the tip.
It is the tip for that branch. Even if there exist other commits building on the commit the current branch points to, the pointer is still at the tip for that branch.
The point is that a branch is simply a pointer to a commit that automatically encapsulates all of the parent commits.