3

The git diff command (with the --no-index flag) works incredibly well to diff two files, irrespective of whether or not these two files are contained in a Git repo or not.

Example

$ git diff --no-index -- filea fileb
// shows diff between filea and fileb

Question

Is it also possible to use Git to selectively "merge" (i.e. git add) content from one file to another if they are not part of a Git repo? Basically like a git add -p but not from the working directory to the index, but from fileb to filea.

I feel like all the basic building blocks (plumbing commands) should be available. Possibly something involving format-patch and/or apply?

$ <command> filea fileb
// wanted: interactively choose patches/hunks from fileb and apply them to filea
friederbluemle
  • 33,549
  • 14
  • 108
  • 109

2 Answers2

2

The git add -p command is—or at least was1—a big Perl script. To view it, find the "core" directory:

git --exec-path

which will print something like /usr/lib/git-core or /usr/local/libexec/git-core. This is where various Git internal binaries and scripts live.

In whatever directory gets printed out, look for git-add--interactive. This is, or was, the git add -p code.

This Perl program runs the Git diff and apply commands, and should be relatively easy to modify to make it do what you would like done. Note that this is used for all of git add -p, git reset -p, and git checkout -p, which is why it's nearly 2000 lines long.

The Git project folks are in the middle of rewriting all of this to make it impossible for you to modify. :-) Er, that is, to make it written in C to go fast—you'll still have the source, and can still modify it all you like, but as a C program, it will be much harder to work on.

torek
  • 448,244
  • 59
  • 642
  • 775
2

git diff --no-index is pretty much just an ordinary diff, if you want to apply change hunks across arbitrary files, use an ordinary merge tool like vimdiff -- which is even harder to distinguish from vimdiff used as a Git mergetool because it's the same exact thing.

git add is for adding content to the repo, you're not working on two paths from the work tree, you're working on a single path from the work tree and whatever content is indexed at that path. In particular, you don't get the option to have two different names.

But Git itself finds its work tree (and repo, and objects, and index…) only if you don't explicitly tell it where they are. If you've got a snapshot of filea somewhere, say at /path/to/filea, you can

git --work-tree /path/to add -p filea`

and git will obligingly do a patch-add from the filea at that path to the filea content registered in the index.

jthill
  • 55,082
  • 5
  • 77
  • 137
  • Very interesting, this is going in the right direction. However, as you mentioned, it only works well if the two files are in two different directories and both directories are Git repos. – friederbluemle Feb 16 '20 at 03:12
  • No. The other directory can be anything. You can tell it explicitly what directory to treat as the root of the work tree, what directory to treat as the main repo dir, what file to treat as the index listing, and where to find its object db, Git finds all this stuff automatically if you don't tell it, but you can just tell it. – jthill Feb 16 '20 at 03:46
  • Hmm maybe I'm misunderstanding. If `/path/to` is _not_ a Git repo, the command just tells me `No changes.`. Using Git version `2.25.0` – friederbluemle Feb 16 '20 at 03:53
  • 1
    Interesting and useful trick: just set the work-tree for the duration of one `git add -p`. – torek Feb 16 '20 at 03:59
  • @friederbluemle then the `filea` at that path matches the indexed content for it, or the file isn't indexed at all and you should just add it first. Yeah, that's, umm, can we settle on "quirky" for its existing behavior there? I wouldn't argue against "wrong", though. @torek yeah. it makes importing new releases from vendor tarballs super convenient. – jthill Feb 16 '20 at 04:33