Andrew, If I had a tag pointing to a commit that was so latter hidden could I easily return to the commit and say build it by referencing that tag without having to do any git magic? Brian ________________________________ From: Andrew Ardill [mailto:andrew.ardill@xxxxxxxxx] Sent: Wed 5/16/2012 6:50 PM To: Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600 Cc: git@xxxxxxxxxxxxxxx Subject: Re: Making git history strictly time safe Brian, The first thing to know is that given a unique identifier for a commit, it's sha-1, it is guaranteed that the history of that commit will never change. Perhaps more accurately, the history is encoded with the commit contents as part of the sha-1, so it is as secure as sha-1. What can change are references to commits - branches, the HEAD reference, tags etc. Someone could take the contents of each commit, and use them to create a new history that is slightly altered, but this would be recorded as a different commit object, with a different sha-1. At this point they could point a reference, such as a branch, at this new commit object, and try to convince everyone that the history hasn't changed. Git will viciously warn everyone when they try to update this reference, requiring a force update to continue. My understanding is that the config options you show are enough to stop a remote user from updating a reference that changes history in the way I mentioned. If they did update a reference like this, the previous history would still exist, it would just not be referenced by the branch name etc. Regards, Andrew Ardill On 17 May 2012 08:47, Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600 <brian.p.jones4.ctr@xxxxxxxx> wrote: > I am working towards git adoption on a project. One of the concerns is the fear that git history is not guaranteed to be time safe. How can I configure a git repository so users cannot push or pull changes into it that change it's history? This includes keeping users who work directly in the repository from doing a rebase. > > I've found... > http://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite > > Which recommends setting... > > git config --system receive.denyNonFastforwards true > git config --system receive.denyDeletes true > > ...Is this enough to guarantee time safe history? > > Notes: > 1. Only certain process-central repositories would need time safe history. > 2. Developers can change their history provided it does not impact anyone else. I don't care about this case (yet). > > Brian P. Jones > Senior Software Engineer > Configuration Management > > -- > 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 -- 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