Re: Tracability in git commits

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 29, 2008, 21:34 UTC
Message-ID: <7vd4o873cm.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1209473739.5642.31.camel@dax.rpnet.com>

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.

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.

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.

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.