From: Junio C Hamano <gitster@pobox.com>
To: Richard Purdie <rpurdie@rpsys.net>
Cc: git@vger.kernel.org
Subject: Re: Tracability in git commits
Date: Tue, 29 Apr 2008 14:34:01 -0700 [thread overview]
Message-ID: <7vd4o873cm.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <1209473739.5642.31.camel@dax.rpnet.com> (Richard Purdie's message of "Tue, 29 Apr 2008 13:55:39 +0100")
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.
next prev parent reply other threads:[~2008-04-29 21:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-29 12:55 Tracability in git commits Richard Purdie
2008-04-29 16:08 ` Johannes Schindelin
2008-04-29 21:34 ` Junio C Hamano [this message]
2008-04-29 21:56 ` Richard Purdie
2008-04-30 2:51 ` Shawn O. Pearce
2008-04-30 17:33 ` Ping Yin
2008-04-30 19:46 ` Miklos Vajna
2008-05-01 0:28 ` Shawn O. Pearce
2008-05-01 5:09 ` Ping Yin
2008-04-30 10:06 ` Jakub Narebski
2008-04-30 10:32 ` Richard Purdie
2008-05-01 1:26 ` Martin Langhoff
2008-05-01 7:34 ` Martin Langhoff
2008-05-01 19:03 ` Junio C Hamano
2008-05-01 22:21 ` Martin Langhoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vd4o873cm.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=rpurdie@rpsys.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).