Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> > >
>> > > 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
