git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Klas Lindberg <klas.lindberg@gmail.com>
To: Nicolas Pitre <nico@cam.org>
Cc: Git Users List <git@vger.kernel.org>
Subject: Re: Fetching SHA id's instead of named references?
Date: Wed, 8 Apr 2009 22:03:49 +0200	[thread overview]
Message-ID: <4CBB910C-24F5-4F51-A02D-7760839CCE18@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0904062214170.6741@xanadu.home>

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? 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  :-(

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

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.

> There is nothing a tool can do for you if someone is determined to be
> stupid with it.  In other words, don't delete a branch if it contains
> important stuff.  You may rename it if you wish.  And if you don't  
> want
> to fetch everything then you may always find out about the right  
> branch
> to pull with "git branch --contains <SHA1>".

This is all very true. And I wasn't aware of the --contains switch  
before. That one covers an entire scenario for me. Thanks!!

BR / Klas

  reply	other threads:[~2009-04-08 20:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-06 12:13 Fetching SHA id's instead of named references? Klas Lindberg
2009-04-06 12:33 ` Johannes Schindelin
2009-04-06 12:41   ` Klas Lindberg
2009-04-06 12:48     ` Johannes Schindelin
2009-04-06 21:50       ` Dmitry Potapov
2009-04-06 12:54     ` Matthieu Moy
2009-04-06 13:06       ` Klas Lindberg
2009-04-06 13:16         ` Finn Arne Gangstad
2009-04-06 14:40   ` Shawn O. Pearce
2009-04-06 16:22     ` Klas Lindberg
2009-04-06 16:55       ` Nicolas Pitre
2009-04-06 23:40         ` Klas Lindberg
2009-04-07  2:34           ` Nicolas Pitre
2009-04-08 20:03             ` Klas Lindberg [this message]
2009-04-08 20:38               ` Nicolas Pitre

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CBB910C-24F5-4F51-A02D-7760839CCE18@gmail.com \
    --to=klas.lindberg@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=nico@cam.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).