3 ms·
I'm not downvoting you but the git branch command is orthogonal to checking out a branch. The branch command adds, removes and lists branches. The checkout comm
by weaksauce 15y ago
I'm not downvoting you but the git branch command is orthogonal to checking out a branch. The branch command adds, removes and lists branches. The checkout command switches between them. There is a convenience command that does a checkout and create. The main thrust of the checkout command is to change branches so if a branch does not exist they give you a convenience method to do so.
edit: git add -p(atch) is supposed to create patches of existing files assuming that that is the most common use case. Use --interactive if you want to add new files and still do interactive patching.
- Argorak 15y agoI am aware why the distinction exists - from the perspective of "git(1) manipulates the git file system", it make sense (as I wrote). But most people I know tend to use "branch" for all their branching work (as the name implies) and never bother about the finer details. But the fact that this sore point exists and is real makes the git UI problematic. I don't bother, because I know the details, but if I have to explain it to every new guy in the office, there is something wrong. About git add -p: yes, I am aware of -i, but it doesn't give you the easy "give me all changes to the file system and let me sign them off"-interaction that git add -p has. They are two completely different interaction modes.
- weaksauce 15y agogit add -i 5<enter> *<enter>(all changed files) or 1-5<enter>(files 1-5 in the list) or 1,5,3<enter>(files 1, 5 and 3) etc... then <enter> gets you to the staging that you are used to. this will get you into the quick patch mode that -p does. -p is just a short circuit of this.