In message <CAKLmikNaqVRb=pGUhbvVQTX2tYWT0HSS2R6Ezmico3X0rMgvYQ@xxxxxxxxxxxxxx>, Mitar writes:
I am a git newbie, but after few hours or reading and searching I have
not found a simple way to get a list of revisions retrieved by a
fetch
The output of fetch seems to do that, quite nicely.
----------------------------------------------------------------------
> git fetch
remote: Counting objects: 24155, done.
remote: Compressing objects: 100% (6651/6651), done.
remote: Total 21446 (delta 15831), reused 20146 (delta 14640)
Receiving objects: 100% (21446/21446), 6.78 MiB | 239 KiB/s, done.
Resolving deltas: 100% (15831/15831), completed with 574 local objects.
>From git://git.kernel.org/pub/scm/git/git
ea2c69e..edf1412 maint -> origin/maint
ae4479d..8275905 master -> origin/master
+ b6b16ad...8a79d96 next -> origin/next (forced update)
+ 47db9a0...30b8c95 pu -> origin/pu (forced update)
ce29fc8..3ca5cbc todo -> origin/todo
----------------------------------------------------------------------
OK, ignoring that output:
----------------------------------------------------------------------
> git branch -r | grep -v ' -> ' | while read b; do git reflog -n 1 "$b"; done
edf1412 refs/remotes/origin/maint@{0}: fetch: fast-forward
ea2c69e 8275905 refs/remotes/origin/master@{0}: fetch: fast-forward
ae4479d 8a79d96 refs/remotes/origin/next@{0}: fetch: forced-update
b6b16ad 30b8c95 refs/remotes/origin/pu@{0}: fetch: forced-update
47db9a0 3ca5cbc refs/remotes/origin/todo@{0}: fetch: fast-forward
----------------------------------------------------------------------
The reflog, of course, only gives you the latest change for each
branch, which means that two fetches in a row will return the same
output if no changes were received. Of course there is the classic:
----------------------------------------------------------------------
git for-each-ref | pcregrep 'commit\srefs/remotes/' > /tmp/old
git fetch
git for-each-ref | pcregrep 'commits\srefs/remotes/' > /tmp/new
diff /tmp/old /tmp/new
----------------------------------------------------------------------
I'm in favor of more git hooks myself, but there is a solution to your
needs without it.
Even if there is a way to reconstruct data passed to post-receive (to
be given to post-fetch), I am concerned about race-condition of this.
If you care about race conditions (and really, a lockfile(1) call can
take care of that easily enough), then parse the output of fetch which
will make it clear what *this* call did.
-Seth Robertson
--
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