Re: Fetching SHA id's instead of named references?

[Nicolas Pitre <nico@cam.org>]

On Wed, 8 Apr 2009, Klas Lindberg wrote:

> 7 apr 2009 kl. 04.34 skrev Nicolas Pitre:
> 
> > In git terms, this is called "history rewriting".  And you really don't
> > want to do that if your repository is pulled by other people, unless
> > there is an explicit statement about that fact.
> 
> I thought you had to use filter-branch to qualify for history rewriting?

That, or 'git rebase', or 'git reset', or 'git commit --amend' on an 
already published commit, or reusing a branch name for a different line 
of development.  Anything that would look like the past has changed to a 
client fetching from you.

> Anyway, the scenario I have in mind is when a new branch is created from the
> old one, the old one deleted and then the name of the old one gets reused. The
> deltas are still there, intact, but now you have to use a different named
> reference to reach them  :-(

Right.  And normally you would use a good name for the new branch that 
clearly indicate its archiving purpose.

> > Thing is, with the distributed nature of git, nothing prevents you from
> > keeping a local version of the commit you're interested in.  Unlike with
> > a central repository where someone else might delete a branch you need,
> > with git you will still have access to that particular commit locally
> > regardless if the remote repository has deleted it or not.
> 
> This is true, and Git is indeed very good at saving your ass on the client
> side. Other systems spend much more effort on saving your ass on the server
> side. My problem is that "my" people responsible for the overall system are
> mostly interested in the server side. At least that is where they put the
> tough requirements on perpetual availability.

Just never allow for any branch to be deleted nor rewound on the server 
then.

> However, it is good enough if there is some way to somehow guarantee that a
> branch or tag will never be misused as outlined above. This could be solved
> through basic file system mechanisms (like write protecting the refs/tags
> files perhaps?) or a backup mechanism that raises an alarm on forbidden
> manipulations, or a host of other more or less weird mechanisms. Git doesn't
> have to provide the mechanism directly, but it would be nice for enterprise
> users if it did.

Git provides you with hooks.  Have a look here:

   http://www.kernel.org/pub/software/scm/git/docs/githooks.html


Nicolas