> Heh. Maybe you could just use the rename logic?
>
> [How-to snipped]
Clever idea, but I think the real problem was to figure out what VERSION
of the file was the base; i.e. to look through history.
Still, it should be possible to adapt the technique...
#!/bin/sh
# List of files we are looking to copy from
SRC="drivers/serial/"
# Temporary work directory
DST=/tmp/work
git-clone -l -n -s . $DST
{ cd $DST; git-symbolic-ref HEAD refs/heads/DELETEME; }
for i in `git-rev-list v2.6.20..v2.6.24-rc6 -- $SRC`; do
j=`git-describe $i`
git-archive --prefix="$j/" $i -- $SRC | tar xf - -C $DST
# This is abusing the index, but it saves space...
{ cd $DST; git add $j; rm -rf $j; }
done
# And now proceed as per Linus's idea...
# Except we have it all in the index; no need
# to actually make a commit...
cd $DST
cp $target_file $DST
{ cd $DST; git-diff-files -M...; }
Maybe a real git wizard will show me how to insert the index entries
directly without ever doing anything as pedestrian as extracting, hashing,
and then deleting the files, but it's still not that bad.
And it's kind of a neat example of using the index as a staging area
for a commit.
(Exercise for the reader: the above gets a complete copy of every file in
the directory for every commit in qhich ANY file in the directory changed.
Better would be to do the git-rev-list per-file, so you only add unique
file versions. This requires an outer loop over file names and a more
careful pathname specification to git add in the inner loop.)
-
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
