Re: being nice to patch(1)

Johannes Schindelin [off-list ref] writes:

quoted

quoted

quoted

I guess the second choice generally isn't an option, but dammit, 
"git-apply" really is the better program here.

Why not?  git-apply works outside of a git repo ;-)

I was more thinking that people are not necessarily willing to install git 
just to get the "git-apply" program..

But maybe they would be willing to install git to get that wonderful
git-apply program, and that wonderful rename-and-mode-aware
git-diff, and the git-merge-file program, all of which can operate
outside of a git repository. (Take that, hg!)

Well, hmph!  I just rewrote my git-diff-using script to not check
stuff into a throw-away git repository, and guess what: with real-life
use cases (diffing trees of about 500MB size), git-diff runs out of
memory (the machine probably has something like 1.5GB of virtual memory
size) when operating outside of a git repository.

So the usefulness still seems limited, even now that the output format
of --name-status has been fixed.

Any idea whether this is a bug, sloppy programming, or an inherent
restriction/necessity?

Also an idea which of the following scenarios would be best for
catching all of moves/renames/deletes/adds?  Note: any repository is
strictly throw-away.

Experiments are somewhat time-consuming, so every hunch helps.

a) diff directories outside of git (works, but fatal memory footprint
                                    for large cases)
b) diff index against work directory
c) diff revision against work directory
d) diff revision against index
e) diff revision against revision (works, but high disk footprint and
                                   likely slower than alternatives)

Thanks,

-- 
David Kastrup