Re: Tracability in git commits

[Richard Purdie <rpurdie@rpsys.net>]

On Tue, 2008-04-29 at 14:34 -0700, Junio C Hamano wrote:
> Richard Purdie <rpurdie@rpsys.net> writes:
> 
> > Assuming a shared server using something like gitosis each set of
> > commits is made under a certain ssh ID and what I'd like is to be able
> > to validate that against the commits so we could tell that commits A-D
> > were made by ID Z.
> 
> First of all, you need to learn the differences between making commits and
> updating remote repositories.  Push does not create commits, it only
> propagates a new part of commit DAG created elsewhere.

I understand that, yes. I also understood the remote repository to be
able to accept or reject commits/merges through its hooks?

> When you grant rights to a person to update the tip of a branch of a
> repository, you are saying that you trust the person to advance the
> history recorded on that branch in a way that is compatible with the goal
> of the branch of your repository.

but you can put a policy in place for that in the hooks if desired?

> Whether you like it or not, git is a distributed system and git does not
> care how that other person came up with the new part of the history.  The
> person may find somebody else's work that is useful and apply patches to
> his history (introducing commits whose authors are not himself), or merge
> it (introducing commits whose committer are not himself), but you trust
> that the person who does so uses good judgement, the same good judgement
> he uses when making changes on his own.

I appreciate this can happen and is often part of the normal workflow. I
have no objection to that, its more a question about whether it can be
controlled or at least logged...

> And then the branch you granted the right to update its tip to that person
> is updated, using that added part of the history.  The updates to the tip
> will be recorded in reflog to record who updated the tip and when, which
> would allow you to go back and point your finger at the person who
> introduced problematic new history and at that point you really do not
> care if the problem you have with the new history was due to faulty
> commits the pusher made himself, was introduced by a merge the pusher did,
> or was applied by the pusher from his mailbox.

This sounds like my answer, it's possible to trace who did what from the
reflog. Which area of code is responsible for updating the reflog, is it
in git itself or is it in the form of a hook? 

I'm asking since if the repository is read/write for several users,
faking the log is easy. If you use something like gitosis it runs under
one user and faking is hard due to the restricted access. There is
probably a need to feed extra information into whatever is making the
log, or generate an additional log though due to the single user?

Thanks,

Richard