I think what we want to have a hook that on the server repository to
prevent the local pushes, so I think if we using git log on the server
repo, this won't protect us since git log is only created after local
pushes, right? and also since when our developers clone the repo to theri
locals, and hooks won't be cloned, so we need to have a way to check each
developers push to protect our server repo to have the correct codes. So do
you have any suggestion on how we can have this ?
On Wednesday, September 4, 2013 9:36:10 AM UTC-4, Konstantin Khomoutov
> On Wed, 4 Sep 2013 16:59:14 +0400
> > For each ref to be updated:
> > 1) Call `git merge-base $oldname $newname` -- this will give you the
> > name of a commit which is common between the old and the new state
> > of the ref. In the simplest case -- a fast-forward of the ref this
> > will be the old tip commit of that ref ($oldname here), in a more
> > complex case, where a user did a forced push which replaced some (or
> > all) of the ref's history, this will be the nearest (to the
> > prospective new tip) commit which won't be replaced, and this means
> > its log message has already been checked at some point back in time.
> > 2) Having obtained this base commit, call
> > git rev-list $newname ^$basename
> > 3) Iterate over the generated list, calling
> > git cat-file -p $sha1name
> I've just tried, and `git log $newname ^$basename` just did the right
> thing, so if you are okay with a coarse-grained approach, checking each
> ref reduces to grepping the output of
> git log $newname $(git merge-base $oldname $newname)
> (possibly further instrumented with approptiate --format command-line
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.