sync.pl (Git) is examining all commits all the time

[GoogleCodeExporter]

What steps will reproduce the problem?
1. run:
extensions/VCS/sync.pl --type=Git --as=user@mail.com --project=test --verbose 
/home/user
2. run again:
extensions/VCS/sync.pl --type=Git --as=user@mail.com --project=test --verbose 
/home/user

What is the expected output? What do you see instead?
-Second run should not produce any output. It should know not to parse commits 
from beginning of time.
-Instead it parses all the commits from the start.

What version of the product are you using? On what operating system?
-Latest. Linux.

Please provide any additional information below.
-The script is issuing the following command:
git log --reverse -m
That command shows log from the beginning of the repo. This is not necessary 
and can be expensive as the repo grows old.
Instead we should issue:
git log --reverse -m 2350d1e9c83bd024..

Where "2350d1e9c83bd024" is the commit id when sync.pl was run the last time.
To get current commit id:
git rev-parse HEAD

You can now store that in DB and use it in next call of:
git log --reverse -m 2350d1e9c83bd024..

Original issue reported on code.google.com by rho...@gmail.com on 25 Apr 2011 at 3:28

[GoogleCodeExporter]

Hmm, but Git is a DVCS, how can I know that you didn't do some sort of crazy 
merge or backing-out or switching branches, etc.?

Original comment by mka...@google.com on 25 Apr 2011 at 5:30

[GoogleCodeExporter]

This is what I did:

mkdir test
cd test
git init
touch test.txt
git add .
git commit -m"one"
git log
echo "First line of code" >> test.txt
git add .
git commit -m"two"
git log
git branch crazy
git checkout crazy
echo "Second line of code" >> test.txt
git add .
git commit -m"crazy one"
git log
git log 46ba136687..           {this is commit "one"}
git checkout master
git merge --no-ff crazy
git log
git log 46ba136687..           {this is commit "one"}

The log shows info as expected.
I didn't test any "crazy" stuff. Limited knowledge of git :(.

Original comment by rho...@gmail.com on 25 Apr 2011 at 5:53

[GoogleCodeExporter]

Oh, no, I wasn't accusing you of doing crazy stuff. I was saying in general, I 
need to rescan the whole repository, because I can't know what the user has 
done with it.

Original comment by avatrax...@gmail.com on 26 Apr 2011 at 5:27

[GoogleCodeExporter]

I understand and I didn't think you accused me of anything :)

What I tried to demonstrate is that when you branch and merge, "git log from.." 
will show the comments from withing the branch as well.

The only problem I see (with my limited knowledge of git) is when you have 
stored commit id 46ba136687 in DB and someone removed that commit from the 
repo. In that case "git log 46ba136687.." will tell you that such commit 
doesn't exist and I guess will return -1 which would trigger full scan?

Original comment by rho...@gmail.com on 26 Apr 2011 at 6:00

[GoogleCodeExporter]

Ah, it's actually worse than that. You could change the HEAD pointer to point 
to another branch with an identical commit at the top but different commits 
underneath it.

Original comment by avatrax...@gmail.com on 27 Apr 2011 at 7:21