I know that git add -p applies a patch and that is a great feature of git. Get it. But how can I skip the part where I have to answer to each questions presented to me by git and simply have them already typed in my first query, something like:
git add -p "Filename" "Option selected" "Enter"
The intention of git add -p is to:
interactively choose hunks of patch between the index and the work tree and add them to the index.
The options you seek would defeat the purpose of using git add -p.
While I advocate taking the time to interactively review changes using git add -p, you can use the following command combination to review code more quickly:
git diff -w
git add -u
This allows you to see all changes and then stage them (note only tracked files). Less interactively and therefore quicker, but still maintains a review.
git add -p provides a UI for doing precisely that.For any given file F (where F is the full path, e.g., src/sub/lib.py or whatever), there are, at all times, three copies of F available for your use right now:
HEAD or @);What git add does normally is copy F into the index version.
The index is probably best described as "the files that will be in the next commit". Even though some commands, such as git commit, talk about an "empty" commit, these commits aren't really empty at all: they have all the same files as the previous commit. They're just "empty" if they have no changes from the files in the previous commit. So it's extremely rare for the index to be empty: it's just usually full of the previous commit, until you run git add.
What git add -p does is compare what's in the index right now to what's in the work-tree, by doing a git diff on those two versions of the file. It then lets you update the index version one part at a time, by applying just a little bit of the difference between the work-tree version and the index version. But it's an interactive program, so it really, desperately wants to interact with a human. It is not designed to be driven programmatically.
If you know that you want, say, the first half of the work-tree version and the last half of the index version, there are a bunch of ways to make this happen. Most of them are quite tricky to get right. The simplest (and therefore easiest to get right) non-interactive method is to save a copy of the work-tree version, temporarily replace it with the one you want copied into the index, use git add to copy from work-tree to index, and then re-replace the work-tree version with the saved version.
You can also use git apply --index --recount to feed parts of a patch to git apply. This is what add -p (which is actually written in Perl) does.
All you are doing in the end is copying some variant of the file into the index, so that the HEAD, index, and work-tree versions all differ. You can do this any way you like, as long as you know the tricky bits about copying files into the index (specifically, that any end of line hackery and "clean" filter programs must be run on the content before using git update-index --cacheinfo or --index-info to update the index directly).
git add -p is not supposed to be used that way. You've asked an XY question: you have a problem, and something (Y = git add -p) that you think is the solution, so you have asked about Y ("control git add -p") instead of asking about X ("pick a hunk and apply it"). See my short penultimate paragraph about using git apply.
git add <Filename>, without-p.