Re: being nice to patch(1)

From: David Kastrup <dak@gnu.org>
Date: Jul 6, 2007, 12:38 UTC
Message-ID: <86644xd7wr.fsf@lola.quinscape.zz>
In-Reply-To: <Pine.LNX.4.64.0707031303130.4071@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 13 quoted lines

>> > >
>> > > 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