On Wednesday, February 19, 2014 at 09:24 EST,
Christian Zimmermann <
chaos...@gmail.com> wrote:
[...]
> > repo forall -pc ' git log --since=$(cat
> >> /home/chaos/aospal_chaos_changelog/lastbuild_mako.txt) --date-order ' >
> >> /home/chaos/aospal_chaos_changelog/mako-changelog-$(date +%Y-%m-%d).txt
> >
> > date +%d.%m.%Y > /home/chaos/aospal_chaos_changelog/lastbuild_mako.txt
This might be an acceptable approximation, but it's broken. I'm not
sure whether --since looks at the author date or the commit date, but
regardless you can't rely on it. For example, consider what happens
when your new build includes a merge commit that introduces tons of
old commits to the branch.
To get correct results you must let Git traverse the commit graph
between your current position and your last position. To do that
you could save the head SHA-1 of each Git before you sync so that
you can run 'git log <old sha1>' to find all commits that have been
introduced. You can also set a tag to avoid having to deal with
SHA-1s more than necessary. Something like this:
repo forall -c "git tag sync-$(date +%Y%m%d%H%M)"
repo sync
repo forall -c "git log $(git tag -l sync-* | tail -n 1)"
Not sure if the tag list provided by 'git tag' is sorted, so you
might want to throw in a sort command in the pipeline.
Oh, and assuming it's the newly introduced upstream commits you
want to track you shouldn't tag the head commits; tag the upstream
branch(es) you're interested in. The $REPO_RREV variable (available
in 'repo forall commands) will be helpful there.
[...]
--
Magnus Bäck
ba...@google.com