Yessir. Why over complicate things when we're already working on seperate branches. Include some formatting tools and something I like to do is pushing a code cleanup commit to remove any console.logs I used when debugging.
@@anass9487because when someone else has to figure out why something exists, the commits you left behind will be invaluable to them if they're done carefully. its frustrating when you see a glaring wtf or question mark in the code and the commit that introduced it touched 50 files and has a two word message. and the guy who wrote it is gone or perhaps even dead
In my workflow I don’t see the problem this is solving. I use “git add . “ all the time because I am working a ticket that specifies specific changes. I don’t make a bunch of changes and then have to be selective about what goes in the commit.
It depends a lot on what you are doing. Object files, executables, output files from test runs, the zillions of files that get created by HDL synthesizers, project files. I’ve seen all manner of crap added. Proper use of .gitignore will take care of a lot of this, but a lot of people don’t seem to know how. (I’m dealing with some very junior developers.) Sure use `git add .`, if you want, but please do a `git status` first and think about whether all the changes it shows are all ones you want to commit. Personally, I use sourcetree and smartgit, which just avoids the whole issue by making it very easy to select the changes you want.
I do code reviews, I always prefer clean merge requests. Many times developers will touch many files and make whitespace or formatting changes. This increases the time it takes to review and half of my time is spent in trying to figure out if something is a formatting chage or have they actually made a material change. When I commit, I always do a diff in my IDE and only push the material changes.
You should use a standardized formatter and enforce it before code can be merged. This will filter out irrelevant formatting changes. It also makes the code base consistent which makes reviews quicker as well.
Been a dev for almost 4 years now and this is the first time I heard about patch adding. I think this is what vscode does with their stage selected changes only feature with git which I do a lot since I discovered it. Before that I have branches and stashes and it can get messy real quick.
Been a dev for 12 years and I didn't know this either. Git is the sort of thing that you learn once early on and then just never really revisit... until you need to revert a commit, of course, and then it's off to StackOverflow. Stashes are definitely a quick way to start making a mess of things. I still do use a stash very occasionally if I need to drop something I'm working on to make a quick patch elsewhere, though only if I know it's going to be a quick and easy patch and I'll be right back to the stashed changes.
@@thombrucestashes are great if you’re very disciplined with them. I find they’re incredibly valuable when I’m checking if a build is good to go when I’m working on multiple things at once, which I very often find myself doing (not because I like that but because it is how it is)
This popped up on my recommended. So helpful! I missed using Vim-Fugitive (not able to use Vim at work) because it let you stage changes in chunks, so this will be super handy!
Probably not a good habbit to get in to. By only partially commiting your working directory, the state of the head of your branch is not something thats ever been run. You could easily get the branch in a state where it doesn't work. I prefer to test what i have then commit exactly that, so my branch is always good.
I agree, and as a person who don't work feel very comfortable with git : I prefer knowing what I commit. I would love to know what @ChaelCodes think about that
I almost always use CI to test if the branch is in a working state, so that's not an issue for me. The associated blog post has some more realistic examples of files and changes that you might want locally, but not on the branch. - editorconfigs - overridden api keys - lockfile updates (these should be in a separate PR) This example is a bit contrived to demonstrate how to use patch add. While I do have a bunch of unadded blog posts, normally I have fewer changes locally that aren't ready to merge. I'm normally only leaving whitespace, comments, and debugging statements behind. It's more about sorting a working state into discrete commits. For example, in this case, setting up excerpts and adding the new blog post should really have been 2 different commits, but I wanted to demonstrate adding files and patch adding chunks in one commit for the video.
The reason for patch is so that you can select what to commit and stash or discard the rest. Otherwise if your git ignore file is fine, then the git add . is just perfect. Don’t see a problem with that.
This comment assumes good git hygiene. Patch adding is fantastic for making atomic commits when you get into a flow state and then realize 3 hours later that your changes should be 3 commits instead of 1. I find that any time I want to use a conjunction in my commit message I should have split the commit. In my personal projects, I usually don't care, but for work projects I try to.
@@yramagicman675yes in this case it works just fine. A lot of the time, if you're working with your tasks already outline then in my case, I would commit after I handle a single task. Makes it simple enough to not really mix.
Welcome back! I'll give patch adding a try in the future. My usual method is just adding files individually or directories of files I know are ready to go, do people often just shoot from the hip with "add ."? Scary!
Nice!!! Saves me time. I usually manually added all the files one by one to the stage and cross referenced with git status and removed any ones I accidentally added by doing git checkout - . This saves time!! Ty!!! 😊
I think so too but for a different reason, my preference is to use a tui called lazygit which is far more efficient (it does breakdown for huge monorepos but worked 100% of time on all my repos)
this is cool, I didn't know about this. my usual workflow when committing is to review the diff for all the changed files that i want to commit. this helps me catch extra garbage that i might have left in there, like a logging statement, some messy code i intended to clean up later, etc.
This is the first time I've seen this used. It's pretty slick! What I love most is how utterly intentional and deliberate it is -- it takes a lot of the "oh, whatever" out of the process.
Interesting feature of patch adding is way too time consuming to go through all those changes as I don't ever have changes that aren't intended to be added. If want to have multi change set then create another branch or save it as a stash
Awesome to see that there's a proper terminal way to do this. I've been doing basically this from the IDE's changes viewer, basically checking all of my changes line by line before adding and commiting. Even though I usually don't have any code which I do not wish to commit laying around, it's always good to check for useless white spaces, bad indents and forgotten console.log("entered method"); :D
While I personally would never have edits in a branch that I didn't intend be included with that branch getting merged this was informative at least about the feature - if I had stuff that I had to go back and forth on I heavily use branches. Perhaps before doing a pull request I may squash and review everything this way
I think there are easier solutions than this. Files that are not ready to be committed/wip should be in a separate branch. Juggling multiple states like this can be a major security concern and all around headache. It feels like a gimmick to bandaid deeper problems with the working state
But what I saw is that this is an example of how to use the command, in the real world is useful when you implement a lot of things but at the end want to have them in separate commits, every commit focus on an isolated feature and this helps you with that, I use this all the time with the magit tool in Emacs
I don't think I ever knew the "name" of this type of adding. I might have been on the docs, but I rarely read the docs for how to add. I use this not as much, partly because 1. I don't really find myself adding things that aren't ready to commit or 2. If I am committing to make a checkpoint, even if broken, I do it on a personal branch. I don't usually encounter problems of someone taking a branch and merging my in-development branch, so if they do, that's on them I feel. Overall though this was a lovely tutorial, great work. I usually use the GUI setup on Visual Studio when I need to do this though I mainly use the command line for everything else. Maybe I should use the CLI for this too, but again it's not something I do very commonly.
Thanks!! That's part of why I made it. I see a lot of tutorials (not necessarily for git) that tell people to use git add . and I find myself helping coworkers unlearn this, because they end up with unwanted changes in their commits, and then we have to rebase or amend to fix it. I think being intentional about what goes into the commit really helps people avoid a lot of those issues.
@@ryandsouza2962 Rebase means taking all your local commits and replaying them on top of some other branch or history so that all your changes is in the end of that commit history. I you did a merge instead, your commits would be interspaced between other commits based on time, and that could force you to resolve merge conflicts multiple times for the same code. Rebasing adds all of your in order on the same source so the only time you would need to resolve multiple merge conflicts is between your changes. Also, in case you go back to this later, all you changes will be in one sequence making it easier to follow, and on case you have a branch living for a longer time (you probably should not, but...) you will usually have an easier time to show of your changes in a PR.
I really like the terminal but selecting what goes into my commits is a GUI task for me, both vsc and intellij have git UIs that help me more than the terminal ever could. Maybe I'll switch some day, bookmarked this video for that day.
I like the control and the consistency. I've swapped between a few editors and OS's and the CLI is the same always. I also like that the CLI "just works" if I'm pair programming in someone else's dev setup. Spending time learning how to use the CLI is an investment I don't regret, but if you've got a system that works for you, more power to you!
I was thinking a similar thing. Ultimately, I see the ideal situation being using a GUI for the repetitive trivial stuff, and then the command line exists for when you need to do somthing specific that you might not do that often.
@ChaelCodes Knowing how to commit hunks rather than whole files on the command line is an invaluable skill to have for exactly the reasons you mention. With that said, for general day to day work I'll still take Intellij's side by side Git diff UI any day of the week! It's just so clean compared to anything I've seen in CLI world. And this is coming from someone who uses the command line religiously for things like Neovim, Lazygit, and Tmux
I agree. In my case I use sourcetree, so it's not depending on a specific ide or editor. I like how I can see the code with syntax highlighting, allowing me to exclude chunks of code (ie white space changes) etc. I do use git cli occasionally for collecting stats for reports, correcting corrupted git repos and line endings for example.
That might not be the best habit as you should test the code as you are committing it. If you are adding patches the you are obviously not doing it. I would say stashing any changes you don't want to be committed might be a better idea. You can use the technique in the video to help you do that.
I agree. Adding individual files might work for small projects, but for bigger projects keeping track on which files contain changes you want and making sure a file does not contain changes linked to other files you do not commit will very quickly become a serious problem, I use feature branches for separation always. Sure, if I do a minimal change of a single or just 2-3 files and I know I have not touched them for any other purpose I do sometimes commit just those, but in most cases I would still branch and then in the branch remove any other change. The reason is that I can then push that branch to the shared repo and have others check it out easily instead of having them picking just a commit, as picking the commit only could end up creating conflicting identical commits. This is of cause not a problem for a single dev, and for a small blog, sure, but as a general advice, no, definitely no :)
I tend to do a git diff and go through all the changes making notes that will become the commit message. Any changes I don't want in the commit I'll manually tidy up. But again, cheers for that I'll certainly add that to my toolbox.
I suggest something like gitui (or lazygit) to make these things easier. Using CLI for patch adding is not very intuitive IMO. TUI applications make it easy.
Cool trick, gonna give this a go next time i need it. It doesn’t necessarily replace ‘git add .’ But there are definitely cases where i would use one over the other. Thanks for sharing
Huh, my usual approach is to look at git diff for each of the files I’m considering adding, and if it looks good, adding the whole thing, and if not, I might use got add --patch on that file, and then finally I do commit -m , I didn’t know you could do the patching in the commit step rather than in the add step. Huh!
I'm usually using git status when I am setting up a project to tweak the .gitignore file before using git add . But, this -p is new to me, so interesting.
I rather use git add than git -p, but I can see using pagination at times if I happen to do two things at same time in same file. I've been editing the file before pushing commit if git diff shows up something weird by removing the file from commit and fixing it. Makes commit more straight forward as by having long command will mix it up... For me it's better to update commit message than commit changes at once. Really like you made a video about this feature. I wonder if it works with files already added to commit list... Works. Or with paths... Works using 'git add -p'.
Been using patch adding basically since I started using Git. I never understood why you would just add everything (except if you do a WIP commit to push or if you actually, really, really, really need everything, which mostly happens at initial commit).
I think a lot of people don't know about their options. git's documentation is a bit thick, and a LOT of tutorials use `git add .`. It took me a lot longer to discover patch adding, but I remember falling in love instantly! 😂
Because there is no need to lol. Don't you think it would be far more popular if this was necessary? I use "git commit -am "message"" instead of "git add -A" (git add . is deprecated afaik). "git commit -am """ doesn't add new files but it's apparent if you have missed a file by doing "git status". As to why this patch stuff is not necessary, you can always use a combination of squashing, stashing, cherry picking and merging/rebasing to get what you want. I only do half of the stuff in the terminal (mostly the two commands I mentioned before, git push -f, git rebase, git checkout, git checkout -b, git stash, git reset and git reset --hard), for the rest I use VScode and gitlens/gitless. What I have set up is far superior in terms of productivity than anything else I have seen.
"not necessary" and "your own opinion" are not the same thing. Adding everything can be useful, but the risk of adding code you don't want in a commit is there. Also git add . is not deprecated. Used it yesterday just fine for my initial commits.
Also you ARE patch adding if you're using vs code extensions to manage patches. Terminal vs. GUI is irrelevant to the discussion, that's personal preference only. Some people are productive using a GUI tool, and others are productive using terminal tools. Both essentially do the same thing. As I said, what you're pointing out is just a different way of patch adding.
@@cheebadigga4092 VSCode is all you need lol. I use some terminal commands just because it's more productive that way. You never need this patch adding thing. Either stash your changes, discard, or commit.
love that this got recommended for me - always appreciate more tips/tricks for git. You mentioned in the video that the change made for the white space would only be in the commit and not locally. Is there a way to make that edit in both places simultaenously from that view or execution stage? I wouldn't want to be out of sync
I have a Jekyll site on GitHub Pages! I use a GH action to deploy it, instead of the gh-pages gem, because I have several custom gems (including my own, Jekyll-Twitch). But GitHub updated to add a new GitHub action around releases, and I need to update to that. Here's the PR for this blog post/video - github.com/ChaelCodes/chaelcodes.github.io/pull/87
let's be serious here, most people either work on a feature branch and needs to add ALL the things (and filter out what's not need) to their commit or they use an IDE, and by the same occasion, use git on the IDE, and are able to filter what file they wanna add to their commit nobody actually needs to use any of those features and would be for very niche cases... (aka, wanna commit only one part of a file, which is really neat and actually taught me something)
As a jr dev, I haven't completely understood what you meant in this video but it seems really interesting and I had never heard about it before. Thank you for this.
I gotta say, I found it very difficult to understand the amount of information that is showed on the screen when doing the patch adding. Just by watching the video I got lost trying to understand which part of the code you were adding. In my case, I prefer to use some program to better visualize what I'm adding to the commit. I use Github Desktop, it shows the diff between the files and I can select the parts that I want to add by clicking on the lines. It does the same thing underneath, but I found it easier to understand what I'm doing haha.
For any one interested. The . is not a special git case. The . always refrences the current directory. Same as .. refrencing the parent directory. That is also why ls -a always shows those to "directories"/
I used to use this and totally forgot about it! Thanks for the reminder. Although I will say that `git add .` is still quite useful in most cases for me, because I try to commit as often as possible in an atomic fashion.
I'm sure other have said this, but changes should ideally be in feature branches. This process is ok in a bind, but I would never use it as a general workflow. It's just too prone to error.
This maybe a dumb question, but how do you know which changes worked and which ones didn't if they are all in your working directory? The way I work, and the way I've seen others work, is that I'll be solving a problem or trying to get a test case to pass and when that works, everything that's not ignored through .gitignore are things I want to add/commit, or else my CI pipeline will fail. At the moment that my tests passed locally, I want all of those changes to be committed, if that makes sense. If I pick and choose this way, there's a good chance my CI pipeline will fail when I push and I won't know about it for at least 20 minutes 😅 git add . can still cause problems, so I am not advocating for that and I can understand where git add -p might be useful, but I don't get git commit -p It probably doesn't fit my workflow because I like to squash my commits into one at the end of the day and that interactive rebase is where I handle fixing (or squashing) commit messages and stuff like that.
Most of the changes I skip are whitespace, comments, or dev environment changes. Sometimes I'll skip a refactored method or file, because it turned out not to be necessary. I focused more on the how and why in the blog post - www.chael.codes/2023/09/09/stop-git-add-dot.html These examples are in there.
As a new Git user I was spoiled by Github Desktop, can't ever see myself doing this in a terminal where I could potentially mess things up. Very low chance of that happening from a well thought out GUI like GD.
@@ChaelCodes totally respect that, i like using terminal for many things too, however for this i found that seing it in gui is better for me and lets me move things faster
I do open-source and programming games streams on Twitch, so I need Windows for the recording software and games, but I work with Ruby so a linux dev environment is preferable. VS Code with WSL is a great way to manage that. I have vim bindings turned on in VS Code, because I like to play with them. The editor I'm using for git is still VS Code. I like managing git via the CLI. I have a lot more control, and I don't have to learn a new GUI when I swap editors or OS's. Plus, it just works when I'm pairing with someone. I don't have to learn their git GUI tool. It may seem janky to you, but it works great for my use case.
@@ChaelCodes It is easier to get your HEAD out-of-sync of your working branch with partial commits. It makes accidents of one type more difficult, but easier for accidents of another kind. You moves the problem-space from "do not commit unnecessary things" to "MUST commit all necessary/related things". Patched commits are useful when you make the mistake of not committing often enough. If you find yourself using patched commits to "organize" them better, then this indicative of not making enough commits. It may alleviate the problem, but the real solution is to make commits of all tracked files more often.
@@ChaelCodes I also find it dangerous and error-prone to manually add every dependency. It will break things, a human can never do such a task consistently. And keep it up. The video format is really good, has a nice pace to it.
Good video, but I think "stop using git add ." is a bit of a clickbaity title, because that's not really the point of the video. The point is to only commit the changes you want to commit and to understand that there are ways to not commit everything at once. If git add . is appropriate for the situation, that's what you use. Besides, I'm far more in favor of "do many but small commits" instead of large commits. This one was honestly fairly big if you consider that you added and modified files in the same commit. In the case where you need to revert a change, it's pretty much always nicer to be able to revert a specific commit than manually editing. In many cases you still have to do manual edits though.
Git add . is fine. Oh, no. My computer crashed but I used patch add only to add the finished files and all of the other stuff I have been working on is gone. Just put everything on the hub and update as you go. patch is an unnecessary waste of time.
Yes! One of the more important tips I only got ~4 years after working with git... Also, if you're working with Vim / Neovim (other IDEs as well but this is mine) then you can run a couple of integrations to make this visual and accessible - ruclips.net/video/IyBAuDPzdFY/видео.html
I feel like this would be great if you are in the middle of a task but you have finished part of the code that someone needs. Also this is my first time ever seeing patch in seven years 👀
Great command option when in server environment. On Desktop i usually prefer git gui which comes with git full bundle and offers same features. But sure if you just use basic git package rha doesnt ship git gui you've to use the command line equivalent. 😊
@@ChaelCodes Currently I dont use git on server, but in the past like almost 15years ago, when git was new. Use case was if you deployed code on server i did that with git hooks. Also if code wasnt running well I used to do a Hot-Fix on server and commit/push it afterwards. But with container management tools like docker there was less & less times for doing such stuff on server. But maybe someone that uses a server instead of containers on local machine might still find himself in a situation where he appreciate cli, because of missing a gui.
Ok this may actually be useful but I don’t people who use vscode, and I don’t trust even more to people who commit binaries and pictures and other non-text stuff to git.
@@ChaelCodes Hi I'm doing it in the CLI with Lazygit tool. But this is available in VS Code as well as in JetBrains solutions (I used those two git GUI before moving to full CLI and ultimately Lazygit which is a GUI but in terminal).
@@ChaelCodes So, I've doing some google search. As we all know a GUI doesn't do much more than write cmd for us. So my GUI doing partial stage must be bound to a git add option. It turns out that it is --patch! So I guess there isn't much differences between doing the -p at the commit or at the staging. Except that I find it more logical or convenient to stage chunk then do a commit than adding a bunch of file and then partially committing them This explains why I didnt know what this option bring on the table. Simply because that's more or less what I'm already doing. The more you know...
It's useful for some people since this functionality exists, but I can't see myself using this. I get confused easily so I try to keep commands to a minimum and generalize. git add . is the most general approach so it works fine for me.
That's why I git add . when I finish a specific task before starting something else. This is more an unorganized approach to working on files.
let's be serious when you work on a feature branch, until you merge it you will add all the things you modified in 95% of cases
Yessir. Why over complicate things when we're already working on seperate branches. Include some formatting tools and something I like to do is pushing a code cleanup commit to remove any console.logs I used when debugging.
@@anass9487because when someone else has to figure out why something exists, the commits you left behind will be invaluable to them if they're done carefully. its frustrating when you see a glaring wtf or question mark in the code and the commit that introduced it touched 50 files and has a two word message. and the guy who wrote it is gone or perhaps even dead
In my workflow I don’t see the problem this is solving. I use “git add . “ all the time because I am working a ticket that specifies specific changes. I don’t make a bunch of changes and then have to be selective about what goes in the commit.
It depends a lot on what you are doing. Object files, executables, output files from test runs, the zillions of files that get created by HDL synthesizers, project files. I’ve seen all manner of crap added. Proper use of .gitignore will take care of a lot of this, but a lot of people don’t seem to know how. (I’m dealing with some very junior developers.) Sure use `git add .`, if you want, but please do a `git status` first and think about whether all the changes it shows are all ones you want to commit. Personally, I use sourcetree and smartgit, which just avoids the whole issue by making it very easy to select the changes you want.
I do git commit -am "Commit message" almost every time, followed by git push.
I do code reviews, I always prefer clean merge requests. Many times developers will touch many files and make whitespace or formatting changes. This increases the time it takes to review and half of my time is spent in trying to figure out if something is a formatting chage or have they actually made a material change. When I commit, I always do a diff in my IDE and only push the material changes.
It also pollutes the commit history. If a file has not changed materially in a commit, I don't want to see it in that commit.
I find myself doing this a lot and yes, it is annoying. What's a better strategy to commit formatting changes?
Maybe do a linter check for every PR?
But if formatting was hardly readable then why not change it?
You should use a standardized formatter and enforce it before code can be merged. This will filter out irrelevant formatting changes. It also makes the code base consistent which makes reviews quicker as well.
Been a dev for almost 4 years now and this is the first time I heard about patch adding. I think this is what vscode does with their stage selected changes only feature with git which I do a lot since I discovered it. Before that I have branches and stashes and it can get messy real quick.
I'm glad I was able to share this with you!
Been a dev for 12 years and I didn't know this either. Git is the sort of thing that you learn once early on and then just never really revisit... until you need to revert a commit, of course, and then it's off to StackOverflow.
Stashes are definitely a quick way to start making a mess of things. I still do use a stash very occasionally if I need to drop something I'm working on to make a quick patch elsewhere, though only if I know it's going to be a quick and easy patch and I'll be right back to the stashed changes.
@@thombrucestashes are great if you’re very disciplined with them. I find they’re incredibly valuable when I’m checking if a build is good to go when I’m working on multiple things at once, which I very often find myself doing (not because I like that but because it is how it is)
This popped up on my recommended. So helpful! I missed using Vim-Fugitive (not able to use Vim at work) because it let you stage changes in chunks, so this will be super handy!
Thanks!! I'm glad you liked it!!
They lock down the editor you can use at work? The horror! 😱
Vim-Fugitive is probably the most useful Vim plugin to ever exist
Probably not a good habbit to get in to. By only partially commiting your working directory, the state of the head of your branch is not something thats ever been run. You could easily get the branch in a state where it doesn't work. I prefer to test what i have then commit exactly that, so my branch is always good.
Agreed, is this not the whole point of staging anyway?
Agreed, is this not the whole point of staging anyway?
I agree, and as a person who don't work feel very comfortable with git : I prefer knowing what I commit. I would love to know what @ChaelCodes think about that
I almost always use CI to test if the branch is in a working state, so that's not an issue for me.
The associated blog post has some more realistic examples of files and changes that you might want locally, but not on the branch.
- editorconfigs
- overridden api keys
- lockfile updates (these should be in a separate PR)
This example is a bit contrived to demonstrate how to use patch add. While I do have a bunch of unadded blog posts, normally I have fewer changes locally that aren't ready to merge. I'm normally only leaving whitespace, comments, and debugging statements behind.
It's more about sorting a working state into discrete commits. For example, in this case, setting up excerpts and adding the new blog post should really have been 2 different commits, but I wanted to demonstrate adding files and patch adding chunks in one commit for the video.
@@ChaelCodes Wouldn't relying on CI make the dev cycle very slow?
The reason for patch is so that you can select what to commit and stash or discard the rest. Otherwise if your git ignore file is fine, then the git add . is just perfect. Don’t see a problem with that.
This comment assumes good git hygiene. Patch adding is fantastic for making atomic commits when you get into a flow state and then realize 3 hours later that your changes should be 3 commits instead of 1. I find that any time I want to use a conjunction in my commit message I should have split the commit. In my personal projects, I usually don't care, but for work projects I try to.
@@yramagicman675yes in this case it works just fine. A lot of the time, if you're working with your tasks already outline then in my case, I would commit after I handle a single task. Makes it simple enough to not really mix.
Welcome back! I'll give patch adding a try in the future. My usual method is just adding files individually or directories of files I know are ready to go, do people often just shoot from the hip with "add ."? Scary!
Yeah!! I've had to convince multiple coworkers to try patch adding. All the tutorials say 'git add .' too, so I understand why!
Nice!!! Saves me time. I usually manually added all the files one by one to the stage and cross referenced with git status and removed any ones I accidentally added by doing git checkout - . This saves time!! Ty!!! 😊
I think so too but for a different reason, my preference is to use a tui called lazygit which is far more efficient (it does breakdown for huge monorepos but worked 100% of time on all my repos)
this is cool, I didn't know about this. my usual workflow when committing is to review the diff for all the changed files that i want to commit. this helps me catch extra garbage that i might have left in there, like a logging statement, some messy code i intended to clean up later, etc.
This is a really neat explanation! Patch adding, but also patch checkout, has been incredibly useful in everything I do that's versioned.
This is the first time I've seen this used. It's pretty slick! What I love most is how utterly intentional and deliberate it is -- it takes a lot of the "oh, whatever" out of the process.
Interesting feature of patch adding is way too time consuming to go through all those changes as I don't ever have changes that aren't intended to be added. If want to have multi change set then create another branch or save it as a stash
Awesome to see that there's a proper terminal way to do this. I've been doing basically this from the IDE's changes viewer, basically checking all of my changes line by line before adding and commiting. Even though I usually don't have any code which I do not wish to commit laying around, it's always good to check for useless white spaces, bad indents and forgotten console.log("entered method"); :D
woww, never really knew some feature like this was in git, really helpful to know!! thanks
Thanks! I'm glad you liked it!
Sublime Merge is my preferred solution to this problem. Thanks for the video, it’s nice to brush up on the basics every once in a while
Glad you appreciated it!
While I personally would never have edits in a branch that I didn't intend be included with that branch getting merged this was informative at least about the feature - if I had stuff that I had to go back and forth on I heavily use branches. Perhaps before doing a pull request I may squash and review everything this way
I think there are easier solutions than this. Files that are not ready to be committed/wip should be in a separate branch. Juggling multiple states like this can be a major security concern and all around headache.
It feels like a gimmick to bandaid deeper problems with the working state
But what I saw is that this is an example of how to use the command, in the real world is useful when you implement a lot of things but at the end want to have them in separate commits, every commit focus on an isolated feature and this helps you with that, I use this all the time with the magit tool in Emacs
Yes, exactly! Thank you!
This is usually what I use it for. By breaking large commits up, it makes reverting much easier and the history is more meaningful.
I don't think I ever knew the "name" of this type of adding. I might have been on the docs, but I rarely read the docs for how to add. I use this not as much, partly because 1. I don't really find myself adding things that aren't ready to commit or 2. If I am committing to make a checkpoint, even if broken, I do it on a personal branch. I don't usually encounter problems of someone taking a branch and merging my in-development branch, so if they do, that's on them I feel. Overall though this was a lovely tutorial, great work. I usually use the GUI setup on Visual Studio when I need to do this though I mainly use the command line for everything else. Maybe I should use the CLI for this too, but again it's not something I do very commonly.
I do the same thing with JetBrains IDE. Happy to know that there is a Git-native way for everybody!
Great video! This should be in most Git tutorials :)
Thanks!! That's part of why I made it. I see a lot of tutorials (not necessarily for git) that tell people to use git add . and I find myself helping coworkers unlearn this, because they end up with unwanted changes in their commits, and then we have to rebase or amend to fix it. I think being intentional about what goes into the commit really helps people avoid a lot of those issues.
I'm thinking about following it up with one on interactive rebasing, and some of my favorite flags, but I'm not sure yet.
That would be amazing! Rebase is something that I still need understanding on :)
@@ryandsouza2962 Rebase means taking all your local commits and replaying them on top of some other branch or history so that all your changes is in the end of that commit history. I you did a merge instead, your commits would be interspaced between other commits based on time, and that could force you to resolve merge conflicts multiple times for the same code.
Rebasing adds all of your in order on the same source so the only time you would need to resolve multiple merge conflicts is between your changes.
Also, in case you go back to this later, all you changes will be in one sequence making it easier to follow, and on case you have a branch living for a longer time (you probably should not, but...) you will usually have an easier time to show of your changes in a PR.
I really like the terminal but selecting what goes into my commits is a GUI task for me, both vsc and intellij have git UIs that help me more than the terminal ever could. Maybe I'll switch some day, bookmarked this video for that day.
I like the control and the consistency. I've swapped between a few editors and OS's and the CLI is the same always. I also like that the CLI "just works" if I'm pair programming in someone else's dev setup.
Spending time learning how to use the CLI is an investment I don't regret, but if you've got a system that works for you, more power to you!
I was thinking a similar thing. Ultimately, I see the ideal situation being using a GUI for the repetitive trivial stuff, and then the command line exists for when you need to do somthing specific that you might not do that often.
Two words: sublime merge
@ChaelCodes Knowing how to commit hunks rather than whole files on the command line is an invaluable skill to have for exactly the reasons you mention. With that said, for general day to day work I'll still take Intellij's side by side Git diff UI any day of the week! It's just so clean compared to anything I've seen in CLI world. And this is coming from someone who uses the command line religiously for things like Neovim, Lazygit, and Tmux
I agree. In my case I use sourcetree, so it's not depending on a specific ide or editor. I like how I can see the code with syntax highlighting, allowing me to exclude chunks of code (ie white space changes) etc. I do use git cli occasionally for collecting stats for reports, correcting corrupted git repos and line endings for example.
Never heard of -p. Nice one!
That might not be the best habit as you should test the code as you are committing it. If you are adding patches the you are obviously not doing it. I would say stashing any changes you don't want to be committed might be a better idea. You can use the technique in the video to help you do that.
I agree. Adding individual files might work for small projects, but for bigger projects keeping track on which files contain changes you want and making sure a file does not contain changes linked to other files you do not commit will very quickly become a serious problem, I use feature branches for separation always.
Sure, if I do a minimal change of a single or just 2-3 files and I know I have not touched them for any other purpose I do sometimes commit just those, but in most cases I would still branch and then in the branch remove any other change.
The reason is that I can then push that branch to the shared repo and have others check it out easily instead of having them picking just a commit, as picking the commit only could end up creating conflicting identical commits.
This is of cause not a problem for a single dev, and for a small blog, sure, but as a general advice, no, definitely no :)
I can't believe I had no idea about that command. Thanks for sharing Chael
I tend to do a git diff and go through all the changes making notes that will become the commit message. Any changes I don't want in the commit I'll manually tidy up. But again, cheers for that I'll certainly add that to my toolbox.
Recently worked with people who would git add . without even checking git status to see what they had changed. Was infuriating.
Cleaning up the commits afterwards is harder too! Those changes will still run into merge conflicts on a rebase, even though they weren't needed.
Great tip and really easy to understand explanation! Thanks!
Thank you!
I use `git add -p :/` all the time. You can add changes selectively for all files from any directory in the repository.
Including untracked ones? I've been trying to find a way to do that for a while. I'll have to try this out!
I'll keep using git add . But thanks for the advise.
I suggest something like gitui (or lazygit) to make these things easier. Using CLI for patch adding is not very intuitive IMO. TUI applications make it easy.
Cool trick, gonna give this a go next time i need it. It doesn’t necessarily replace ‘git add .’ But there are definitely cases where i would use one over the other. Thanks for sharing
Thanks! I'm glad you like it!
Great! Nice tip, thank you! Waiting for a lot more
Thanks!
this is interesting!
i always wondered if something like this existed, but never searched
thanks for making the video!
Thanks for the comment! I'm glad you iked it!
Huh, my usual approach is to look at git diff for each of the files I’m considering adding, and if it looks good, adding the whole thing,
and if not, I might use got add --patch on that file,
and then finally I do commit -m ,
I didn’t know you could do the patching in the commit step rather than in the add step. Huh!
Glad I could show you an easier way! Try it out and let me know if you like it?
Very cool ... Nice tool for certain use cases
Thanks!!
I don't see why i would have edits that i don't want to include in a pull request. The only reason to avoid git add . is it can be slow on large repos
Nice neat coverage of a very useful feature. Thanks for that.
Thank you!! I appreciate that!
I'm usually using git status when I am setting up a project to tweak the .gitignore file before using git add . But, this -p is new to me, so interesting.
Glad I was able to show you something new!
I always use “git diff” to inspect my changes before adding
I rather use git add than git -p, but I can see using pagination at times if I happen to do two things at same time in same file.
I've been editing the file before pushing commit if git diff shows up something weird by removing the file from commit and fixing it.
Makes commit more straight forward as by having long command will mix it up...
For me it's better to update commit message than commit changes at once.
Really like you made a video about this feature.
I wonder if it works with files already added to commit list... Works.
Or with paths... Works using 'git add -p'.
Been using patch adding basically since I started using Git. I never understood why you would just add everything (except if you do a WIP commit to push or if you actually, really, really, really need everything, which mostly happens at initial commit).
I think a lot of people don't know about their options. git's documentation is a bit thick, and a LOT of tutorials use `git add .`. It took me a lot longer to discover patch adding, but I remember falling in love instantly! 😂
Because there is no need to lol. Don't you think it would be far more popular if this was necessary? I use "git commit -am "message"" instead of "git add -A" (git add . is deprecated afaik). "git commit -am """ doesn't add new files but it's apparent if you have missed a file by doing "git status". As to why this patch stuff is not necessary, you can always use a combination of squashing, stashing, cherry picking and merging/rebasing to get what you want. I only do half of the stuff in the terminal (mostly the two commands I mentioned before, git push -f, git rebase, git checkout, git checkout -b, git stash, git reset and git reset --hard), for the rest I use VScode and gitlens/gitless. What I have set up is far superior in terms of productivity than anything else I have seen.
"not necessary" and "your own opinion" are not the same thing. Adding everything can be useful, but the risk of adding code you don't want in a commit is there.
Also git add . is not deprecated. Used it yesterday just fine for my initial commits.
Also you ARE patch adding if you're using vs code extensions to manage patches. Terminal vs. GUI is irrelevant to the discussion, that's personal preference only. Some people are productive using a GUI tool, and others are productive using terminal tools. Both essentially do the same thing. As I said, what you're pointing out is just a different way of patch adding.
@@cheebadigga4092 VSCode is all you need lol. I use some terminal commands just because it's more productive that way. You never need this patch adding thing. Either stash your changes, discard, or commit.
love that this got recommended for me - always appreciate more tips/tricks for git. You mentioned in the video that the change made for the white space would only be in the commit and not locally. Is there a way to make that edit in both places simultaenously from that view or execution stage? I wouldn't want to be out of sync
This is really helpful I kept using the built in tools on vscode but I think this will be even easier and will work well for when I use vim
Thank you!! I'm glad you like it! Feedback like this is why I make videos!
What tech stack are you using when you create your blog?
I have a Jekyll site on GitHub Pages!
I use a GH action to deploy it, instead of the gh-pages gem, because I have several custom gems (including my own, Jekyll-Twitch). But GitHub updated to add a new GitHub action around releases, and I need to update to that.
Here's the PR for this blog post/video - github.com/ChaelCodes/chaelcodes.github.io/pull/87
let's be serious here, most people either work on a feature branch and needs to add ALL the things (and filter out what's not need) to their commit
or they use an IDE, and by the same occasion, use git on the IDE, and are able to filter what file they wanna add to their commit
nobody actually needs to use any of those features and would be for very niche cases...
(aka, wanna commit only one part of a file, which is really neat and actually taught me something)
As a jr dev, I haven't completely understood what you meant in this video but it seems really interesting and I had never heard about it before. Thank you for this.
I gotta say, I found it very difficult to understand the amount of information that is showed on the screen when doing the patch adding.
Just by watching the video I got lost trying to understand which part of the code you were adding.
In my case, I prefer to use some program to better visualize what I'm adding to the commit.
I use Github Desktop, it shows the diff between the files and I can select the parts that I want to add by clicking on the lines.
It does the same thing underneath, but I found it easier to understand what I'm doing haha.
Whoa this was really helpful, thanks for sharing!
Thank you!! I appreciate it.
not sure I'll give up git add . completely. But this is a really useful tool have have in my tool belt. Thanks
For any one interested. The . is not a special git case. The . always refrences the current directory. Same as .. refrencing the parent directory.
That is also why ls -a always shows those to "directories"/
Great video! Learned something cool!!!
thanks for the video. this will come in handy
Skipping individual file or code for commit after I tests? Only work for small project really. Spend more time on branch control.
Why i stop using this command if are very usefull, personally check every change in the tab of changes in vscode and add before this revision
My most common is "git commit -a", after that I use "git add
I used to use this and totally forgot about it! Thanks for the reminder. Although I will say that `git add .` is still quite useful in most cases for me, because I try to commit as often as possible in an atomic fashion.
I'm sure other have said this, but changes should ideally be in feature branches. This process is ok in a bind, but I would never use it as a general workflow. It's just too prone to error.
Feature branch here was cc-video-test. :)
Super helpful!
Thanks!! I'm glad you liked it!
If you want to do that from a light gui terminal based tool there is gitui that does an awesome job !
What if I have lots of new/changed files?
I use `git diff` to see what still not added to the stage and `git diff ^HEAD` to see what's in stage but not commited yet.
This maybe a dumb question, but how do you know which changes worked and which ones didn't if they are all in your working directory? The way I work, and the way I've seen others work, is that I'll be solving a problem or trying to get a test case to pass and when that works, everything that's not ignored through .gitignore are things I want to add/commit, or else my CI pipeline will fail. At the moment that my tests passed locally, I want all of those changes to be committed, if that makes sense. If I pick and choose this way, there's a good chance my CI pipeline will fail when I push and I won't know about it for at least 20 minutes 😅
git add . can still cause problems, so I am not advocating for that and I can understand where git add -p might be useful, but I don't get git commit -p
It probably doesn't fit my workflow because I like to squash my commits into one at the end of the day and that interactive rebase is where I handle fixing (or squashing) commit messages and stuff like that.
Most of the changes I skip are whitespace, comments, or dev environment changes. Sometimes I'll skip a refactored method or file, because it turned out not to be necessary.
I focused more on the how and why in the blog post - www.chael.codes/2023/09/09/stop-git-add-dot.html
These examples are in there.
ayyy super useful tip! less resets from stupid commits now lol
Wow, i follow u on twitch and now / today, i find ur yt chanel, amaizing
i will need to revisit this video
Or, if you like your GUIs just use something like sublime merge
Definitely not knocking GUIs here. If you're happy with your GUI, keep at it!
As a new Git user I was spoiled by Github Desktop, can't ever see myself doing this in a terminal where I could potentially mess things up. Very low chance of that happening from a well thought out GUI like GD.
Yes, I also think that using a GUI is less error prone
You can have the best of both worlds by using tig, a command line git client. You can easily stage/unstage hunks with u and individual lines with 1.
I learned something new, thank you
Cool trick, however keep in mind, that this ignores binary file changes.
gone through other videos also good content and passion of working on open source software , subscribed
Thanks!! I'm glad you liked the other videos I've done too! I'm working on becoming more active.
Glad to hear that
at this point i think the best way is still source control tab.. with gitlens obv.
I'm not knocking GUIs, if you're happy with your tools, go for it!
@@ChaelCodes totally respect that, i like using terminal for many things too, however for this i found that seing it in gui is better for me and lets me move things faster
Feels like people obsess over using git CLI, I just use my IDE plugin for git and have no problems
This is added complexity and bs most people don’t need but boot camp graduates care about to signal they finally learned git
awesome thank you!
Thank you for watching! I'm glad you enjoyed it!
Oh, git add .
I thought you were gonna tell me to stop using git add. The latter might be a problem :)
VS-Code for a WSL shell with vim to manage git via CLI seems like such a janky solution to me.
I do open-source and programming games streams on Twitch, so I need Windows for the recording software and games, but I work with Ruby so a linux dev environment is preferable. VS Code with WSL is a great way to manage that.
I have vim bindings turned on in VS Code, because I like to play with them. The editor I'm using for git is still VS Code.
I like managing git via the CLI. I have a lot more control, and I don't have to learn a new GUI when I swap editors or OS's. Plus, it just works when I'm pairing with someone. I don't have to learn their git GUI tool.
It may seem janky to you, but it works great for my use case.
While this is obviously better than blindly doing "git add .", doing patch commits has its own pitfalls that one needs to be mindful of.
Could you elaborate?
@@ChaelCodes It is easier to get your HEAD out-of-sync of your working branch with partial commits. It makes accidents of one type more difficult, but easier for accidents of another kind. You moves the problem-space from "do not commit unnecessary things" to "MUST commit all necessary/related things".
Patched commits are useful when you make the mistake of not committing often enough. If you find yourself using patched commits to "organize" them better, then this indicative of not making enough commits. It may alleviate the problem, but the real solution is to make commits of all tracked files more often.
@@ChaelCodes I also find it dangerous and error-prone to manually add every dependency. It will break things, a human can never do such a task consistently.
And keep it up. The video format is really good, has a nice pace to it.
JetBrains IDEs have these commands as a UI feature by default lol.
What is the colorscheme's name?
Horizon theme
Thanks@@ChaelCodes
Noice. Really useful tutorial.
Good video, but I think "stop using git add ." is a bit of a clickbaity title, because that's not really the point of the video. The point is to only commit the changes you want to commit and to understand that there are ways to not commit everything at once. If git add . is appropriate for the situation, that's what you use.
Besides, I'm far more in favor of "do many but small commits" instead of large commits. This one was honestly fairly big if you consider that you added and modified files in the same commit. In the case where you need to revert a change, it's pretty much always nicer to be able to revert a specific commit than manually editing. In many cases you still have to do manual edits though.
awesome
Thanks!! I'm glad you liked it!
git add . && git commit -m "changes" && git push --force
Git add . is fine. Oh, no. My computer crashed but I used patch add only to add the finished files and all of the other stuff I have been working on is gone. Just put everything on the hub and update as you go. patch is an unnecessary waste of time.
Yes! One of the more important tips I only got ~4 years after working with git...
Also, if you're working with Vim / Neovim (other IDEs as well but this is mine) then you can run a couple of integrations to make this visual and accessible - ruclips.net/video/IyBAuDPzdFY/видео.html
I'm glad you like it!
I feel like this would be great if you are in the middle of a task but you have finished part of the code that someone needs. Also this is my first time ever seeing patch in seven years 👀
very good presenter, good tips.
Hi, which vs code theme are you using?
Horizon theme. It's beautiful!
@@ChaelCodes thank you
Great command option when in server environment. On Desktop i usually prefer git gui which comes with git full bundle and offers same features. But sure if you just use basic git package rha doesnt ship git gui you've to use the command line equivalent. 😊
That's a great point! When do you use git on the server though? Specifically to make commits?
@@ChaelCodes Currently I dont use git on server, but in the past like almost 15years ago, when git was new. Use case was if you deployed code on server i did that with git hooks. Also if code wasnt running well I used to do a Hot-Fix on server and commit/push it afterwards. But with container management tools like docker there was less & less times for doing such stuff on server. But maybe someone that uses a server instead of containers on local machine might still find himself in a situation where he appreciate cli, because of missing a gui.
@@ChristianPiechotta thanks for explaining!
Ok this may actually be useful but I don’t people who use vscode, and I don’t trust even more to people who commit binaries and pictures and other non-text stuff to git.
I would just do smaller changes with smaller PRs. Easier to review. Most of my changes are smaller so I never see a need for git patch.
Or you can stages chunks of files and commit them instead of doing that patches things. I do not get what this patches thing is bring on the table.
Do you have some more info or documentation on this?
Are you talking about in a GUI or using the CLI?
@@ChaelCodes Hi I'm doing it in the CLI with Lazygit tool. But this is available in VS Code as well as in JetBrains solutions (I used those two git GUI before moving to full CLI and ultimately Lazygit which is a GUI but in terminal).
@@ChaelCodes So, I've doing some google search. As we all know a GUI doesn't do much more than write cmd for us. So my GUI doing partial stage must be bound to a git add option.
It turns out that it is --patch! So I guess there isn't much differences between doing the -p at the commit or at the staging. Except that I find it more logical or convenient to stage chunk then do a commit than adding a bunch of file and then partially committing them
This explains why I didnt know what this option bring on the table. Simply because that's more or less what I'm already doing. The more you know...
It's useful for some people since this functionality exists, but I can't see myself using this. I get confused easily so I try to keep commands to a minimum and generalize. git add . is the most general approach so it works fine for me.
git commit -am "tl:dw"
yeah I should probably read the man pages for the commands I use all the time hahaha
No
trust me use a gui folks
so useful