Git add specific lines not interactively

Question

I want to git add only a specific range of lines from a file with a single shell command. I'm imaging something like:

git add -c myfile.go@123..204

I don't want to use git add -i, git add -p, or git -e (interactive git tools) because my file is big and has many changes, and I already know precisely which lines I want. For the sake of argument (get it?), let's say I want to stage lines inclusively 123-204 of a 2000 line file myfile.go.

I also don't want to use a GUI. Either my computer is too old for the new programs, too slow to run them, the screen is too small... whatever. All the of the above. Github GUI, Sourcetree, an (Atom|IntelliJ|VSC|.* plugin, KDiff, Kaleidescope... they're all out.

Can it be done?

Bonus points: can it be done for multiple files at once?

For reference:

Two related, but not duplicate, questions. Neither fits my needs:

• Commit specific lines of a file to git
• Commit only part of a file in Git
  • This comment makes me think it can be done... Commit only part of a file in Git

Git documentation that's close, but no cigar:

• https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging

Answer 1

From comments, it's unclear whether you're concerned about the efficiency of executing the add operation, the typing that needs to be done to instruct the tools what to do, or both.

I wouldn't worry about the former; and if you are worried about it, there's not much you can do anyway. There are more steps than you might think sound reasonable, and they involve processing the whole file; but really, it doesn't matter, in that I've never seen a single-file staging operation take enough time to worry about it.

As for the amount of typing involved, the add options you listed are the closest built-in support git offers. So you can do a little scripting to augment them. But it won't be easy to ensure that it always "gets it right".

In particular, it's trickier than you might realize to define "the changes to this range of lines". The seemingly-obvious issue is that line additions and deletions change the line numbers of lines that occur after them; but you can probably resolve that by defining your line number range in terms of the current working version of the file (since that's what one would likely be looking at most recently when determining the line number range)...

But the bigger problem is detecting the case where all lines in a range were edited, and that range overlaps the end of the range of lines for which you're staging changes. For example, suppose you have the file

1
2
3
4
5

in the index, and your working copy says

1
2
3 THREE
4 FOUR
5 FIVE

Now you specify that you want to stage the changes from lines 2-4.

The patch will look like

@@ -1,5 +1,5 @@
 1
 2
-3
-4
-5
+3 THREE
+4 FOUR
+5 FIVE

And it's pretty clear that in this case the intuitive result is

1
2
3 THREE
4 FOUR
5

But writing code that gets this "right" without getting other cases "wrong" (relative to equally intuitive interpretation) is not so easy. Sometimes it really is open to interpretation. "Was this one operation that changed three lines? Or one operation that deleted three lines, followed by three operations that each added a line? Or..."

The automated tooling in git avoids making those interpretive decisions, first by looking at code in hunks of change (rather than arbitrary line ranges) and making you intervene manually if you want something different (i.e. by using patch-edit mode); and then by inserting conflict markers (and again requiring manual intervention) when interpretation still seems to be required.

So you basically have to make simplifying assumptions to build a tool, and make sure those assumptions are valid when using the tool.

The idea, then, would be to create a script that reads the patch from the file named by its first argument and edits the patch in place; and set that script as the editor (i.e. by setting the GIT_EDITOR environment variable) when running git add -e. You would use lines of the form @@ -#,# +#,# @@ to figure out the affected line numbers for a change, use that information (and your assumptions) to decide if you want to keep or discard a given change line, and if you want to discard it

• if the line starts with -, change the - to a
• if the line starts with +, delete the line

Answer 2

I have looked into this but not extensively. My understanding is that the way git add -p works is by generating patches, providing an intuitive interface to editing them and then applying them.

You could do this process yourself.

The changes in your working tree is provided by git diff. These are changes that can be applied to your index as a patch using git apply

So instead of git add . you could run

git diff . | git apply - --cached

Ie. get all the difference in your working tree at the current directory and apply all them to the index.

So what you could do is modify the output of the diff yourself and producing a different patch before applying it, using scripting or whatever method.

It may be that the process of modifying this using scripting is trickier than opting for a git add -e or git add -p solution but as far as I gather, this is the way to approach the problem if you want to solve it differently.

Addendum:

This is basically exactly what the interactive git commands do, using perl scripts. It creates chunked diff files, then opens them in $EDITOR. Importantly it automatically fixes the diff format after you've done modification (very annoying to do yourself), because the line summary stuff at the top of a diff ++ XYZ / -- zyx needs to be correct for the patch to apply.

I don't remember what command the perl script runs to chunk the diff, but it's in source somewhere.

If I had to solve this problem today I would probably generate the chunked diffs. Delete the ones outside of the line. Then git appy foo.diff --cached && git restore --staged foo.diff && git add -p.