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 -- 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