`git add -p` is such a nice utility. Sometimes I do wish that it could also be used for unstages files, so that if I'm introducing a new file, I could still break its contents up into multiple commits.
Of course, the workaround there is that one adds the initial file into the staging area and then `git add -p` the subsequent changes. It could just be a bit more convenient on that front, is all.
TIL! I seem to have just missed the `-N`/`--intend-to-add` while perusing through the `git-add(1)` manual.
Heh, it[0] even notes a similar use case:
> `-N`
> `--intent-to-add`
>
> Record only the fact that the path will be added later. An entry for the path is placed in the index with no content. This is useful for, among other things, showing the unstaged content of such files with `git diff` and committing them with `git commit -a`.
This is pretty cool. Worth noting that Git does not actually only store full copies of files every time you make a change, this article I found does a really good job at explaining Git's packing: https://gist.github.com/matthewmccullough/2695758
“Objects” rather than “blobs”, in git “blobs” means specifically file contents (/ unstructured as technically you can use blobs for arbitrary storage) but all objects can be delta’d during packing.
Reminds me of this talk [0] led by CB Bailey, a top answerer on StackOverflow for the tag 'git' [1].
They create commits from scratch from the command line--manually creating each /.git/ file with shell commands and a text editor. Really fun talk. Would highly recommend it for people who were planning on learning about git internals at some point.
[0] "How does Git actually work? - CB Bailey & Andy Balaam [ACCU 2019]"
Nice article. What is interesting to me is the reactions to articles like this. Not the fact that the git internals are not widely known, I mean that is true for nearly any more complicated topic. In this case I mean the fact that this is actually well documented.
Don’t get me wrong. I think articles like these help a lot to demystify git and I believe it makes the tool easier to use and reason with when one knows what it does. But why is nobody finding or reading the later chapters in the docs?
Creating a Git commit using low-level commands was always something I wanted to do, but I never found the time to really deepen my knowledge of Git. I have actually googled if I could find a blog post or something in this topic, but I've failed to find one. Finally, I got the chance, and for the past couple of weekends, I’ve been reading the Pro Git book (which it seems it's the same content as git-scm.com/book). I believe it’s a good practice to write a blog post about a topic after finishing a book (teaching is a good way of submitting knowledge in memory). To my surprise, creating a Git commit using plumbing commands was already covered in the final chapters of the book. I thought it would be a good idea to simplify that process and write a blog post which can be read under 10 minutes, allowing those who haven’t read the book yet (like myself in the past) to get a basic understanding of what Git is doing under the hood.
> But why is nobody finding or reading the later chapters in the docs?
I think to read the latest chapter of a book, one usually needs to read the earlier ones too. I personally don't jump directly to the internals when I want to read about something, because I'd then assume I am missing a lot of context and background.
> But why is nobody finding or reading the later chapters in the docs?
Because most people don’t ever read the book period. 90% of users follow a basic tutorial or instruction sheet to get the five commands they’ll use by rote and go no further.
And, separately, the internals section of the book are mostly uselessly shallow, so if you start digging into that you quickly forget that the book even has one such section.
> Normally, only commits which are reachable by a branch are visible in stock Git.
But this is not true: a "soft" tag suffices to keep a pseudo-branch visible to, say git-log --graph. In my own workflow, I've let these replace temporary branches proper.
Fantastic article! It seems to me that the flexibility of low-level git objects would lend itself to be embedded in other software systems for version control purposes (e.g. tracking changes in a CMS)
I used to struggle with formatting my Git commit messages and often forgot the necessary Git commands.
Now, I've found a utility (made by my brother who shared it with me a few days ago and I told him to opensource it since I liked it soo much) that handles all the formatting and rewriting for me. I just write my commits, and it takes care of the rest.
The last thing I want is for some LLM to tell me to rm -rf /. Neat POC but the tech just isn't there yet and I hope that everyone on HN who isn't shilling an AI product knows that.
That repo is only nine hours old, so I’m assuming you wrote this tool yourself. If so, I think the lack of a disclaimer (that you’re promoting your own tool) is somewhat dishonest.
> Files in Git can be in one of these three states: Modified, Staged, Committed
> Staged: The current version of the modified file is staged to be included in the next commit.
A bit of a nitpick, but if I change a file, "git add" it, and then change it again, both of these statements are false.
I use git add -p somewhat frequently to do partial staging of a file to split up my changes into multiple commits.
`git add -p` is such a nice utility. Sometimes I do wish that it could also be used for unstages files, so that if I'm introducing a new file, I could still break its contents up into multiple commits.
Of course, the workaround there is that one adds the initial file into the staging area and then `git add -p` the subsequent changes. It could just be a bit more convenient on that front, is all.
It can, you just gotta do a magic incantation first.
The first command signals to git that you intend to add the file. That makes its entire content show up in the patch editor.TIL! I seem to have just missed the `-N`/`--intend-to-add` while perusing through the `git-add(1)` manual.
Heh, it[0] even notes a similar use case:
> `-N` > `--intent-to-add` > > Record only the fact that the path will be added later. An entry for the path is placed in the index with no content. This is useful for, among other things, showing the unstaged content of such files with `git diff` and committing them with `git commit -a`.
[0]: <https://git-scm.com/docs/git-add#Documentation/git-add.txt--...>
Alternately:
Wow, I have been using git for ages but I did not know about this. I was relying on magit (for Emacs) and git-cola.
Magit does interactive staging (and unstaging) a lot better than git itself does.
In d u, you can “s” on a file or hunk and it’ll stage just that. And if you select lines (c-spc?) it’ll stage just those lines.
To unstage, go to d s and use “u” the same way.
The massive advantage aside from line-wise staging is that you don’t need to stage linearly.
You can also discard changes that way, e.g.:
I will have to read about how to use it, because it shows some hunks on a page, and I do not want to stage all of them, for example.
When it shows you a hunk that's bigger than you like, you can use 's' to split it into smaller hunks.
Thank you!
Cherrypick (-p) is wonderful. A command I also like is rebase interactive(-I)
Git rebase -i HEAD~[number of commits]
Yeah, I use `git rebase -i HEAD~n` a lot.
I think if the word "Files" was replaced with "A change [in a file]", then the statement holds true. Perhaps a better phrasing:
> In Git, a change in a file, can be in one of these three states: unstaged, Staged, Committed
This is pretty cool. Worth noting that Git does not actually only store full copies of files every time you make a change, this article I found does a really good job at explaining Git's packing: https://gist.github.com/matthewmccullough/2695758
It actually does. Until you run git gc or it runs automatically, and your blobs are packed.
“Objects” rather than “blobs”, in git “blobs” means specifically file contents (/ unstructured as technically you can use blobs for arbitrary storage) but all objects can be delta’d during packing.
Also see https://git-scm.com/docs/pack-heuristics
I really recommend doing the "Build your own git" challenge on CodeCrafters in order to gain a deep understanding of git internals.
https://app.codecrafters.io/courses/git/overview
I really enjoyed watching Jon Gjengset work through this here: https://www.youtube.com/watch?v=u0VotuGzD_w
Nice writeup. Reminds me of a Julia Evans post (which is the highest praise I could give it).
Reminds me of this talk [0] led by CB Bailey, a top answerer on StackOverflow for the tag 'git' [1].
They create commits from scratch from the command line--manually creating each /.git/ file with shell commands and a text editor. Really fun talk. Would highly recommend it for people who were planning on learning about git internals at some point.
[0] "How does Git actually work? - CB Bailey & Andy Balaam [ACCU 2019]"
https://www.youtube.com/watch?v=N0m42TKk_dc
[1] https://stackoverflow.com/tags/git/topusers
I love blog posts like this. Content like this is what I come to hacker news for.
Thank you.
Nice article. What is interesting to me is the reactions to articles like this. Not the fact that the git internals are not widely known, I mean that is true for nearly any more complicated topic. In this case I mean the fact that this is actually well documented.
Don’t get me wrong. I think articles like these help a lot to demystify git and I believe it makes the tool easier to use and reason with when one knows what it does. But why is nobody finding or reading the later chapters in the docs?
https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Creating a Git commit using low-level commands was always something I wanted to do, but I never found the time to really deepen my knowledge of Git. I have actually googled if I could find a blog post or something in this topic, but I've failed to find one. Finally, I got the chance, and for the past couple of weekends, I’ve been reading the Pro Git book (which it seems it's the same content as git-scm.com/book). I believe it’s a good practice to write a blog post about a topic after finishing a book (teaching is a good way of submitting knowledge in memory). To my surprise, creating a Git commit using plumbing commands was already covered in the final chapters of the book. I thought it would be a good idea to simplify that process and write a blog post which can be read under 10 minutes, allowing those who haven’t read the book yet (like myself in the past) to get a basic understanding of what Git is doing under the hood.
> But why is nobody finding or reading the later chapters in the docs?
I think to read the latest chapter of a book, one usually needs to read the earlier ones too. I personally don't jump directly to the internals when I want to read about something, because I'd then assume I am missing a lot of context and background.
I haven't read a "book" like this chapter-by-chapter since I first learned Python by reading the docs.
> But why is nobody finding or reading the later chapters in the docs?
Because most people don’t ever read the book period. 90% of users follow a basic tutorial or instruction sheet to get the five commands they’ll use by rote and go no further.
And, separately, the internals section of the book are mostly uselessly shallow, so if you start digging into that you quickly forget that the book even has one such section.
It was learning about the topics in this post that enabled me to create this repo:
https://github.com/grantm/no-more-f-s-repo
Parental Advisory: Contains strong language.
> git
On the topic, I'm just going to plug the tool git-branchless. Completely transformative for my use of git at work. Stacked commits that actually work!
From the git-branchless wiki:
https://github.com/arxanas/git-branchless/wiki/Concepts#anon...
> Normally, only commits which are reachable by a branch are visible in stock Git.
But this is not true: a "soft" tag suffices to keep a pseudo-branch visible to, say git-log --graph. In my own workflow, I've let these replace temporary branches proper.
Love this!
I think there may be an error around the "git write-tree" step. That or I did something wrong.
Here's my user test: https://www.youtube.com/watch?v=bul4CPRkv6c
Fantastic article! It seems to me that the flexibility of low-level git objects would lend itself to be embedded in other software systems for version control purposes (e.g. tracking changes in a CMS)
Up to commit-tree, a nice programming challenge is implementing those commands from scratch.
I used to struggle with formatting my Git commit messages and often forgot the necessary Git commands.
Now, I've found a utility (made by my brother who shared it with me a few days ago and I told him to opensource it since I liked it soo much) that handles all the formatting and rewriting for me. I just write my commits, and it takes care of the rest.
Here's a video demonstrating this magic (though it's for rsync): [asciinema.org/a/mktcuXSPDTr2Mp1XVbo5tqhK1](https://asciinema.org/a/mktcuXSPDTr2Mp1XVbo5tqhK1).
Check out the utility here: [github.com/zerocorebeta/Option-K](https://github.com/zerocorebeta/Option-K).
The last thing I want is for some LLM to tell me to rm -rf /. Neat POC but the tech just isn't there yet and I hope that everyone on HN who isn't shilling an AI product knows that.
That repo is only nine hours old, so I’m assuming you wrote this tool yourself. If so, I think the lack of a disclaimer (that you’re promoting your own tool) is somewhat dishonest.
You are partially correct, but I am not the owner of this project.
I edited my original post to reflect this