Re: Deprecation/Removal schedule

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, 6 Feb 2007, Alex Riesen wrote:

> On 2/6/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> > > > > git gc (repack -d of it) is too dangerous in a shared repo: it breaks
> > > > > the repos which depend on the master repository, have sent (by some
> > > > > means) some objects over to the master, and accidentally removed
> > > > > the reference, and were pruned afterwards.
> > > >
> > > > We no longer call git-prune automatically in git-gc. You have to say
> > > > "git-gc --prune" to trigger that behaviour.
> > >
> > > repack -d can lose objects, too:
> > >
> > > # fully packed test repo with 2 commits
> > 
> > This is the culprit.
> > 
> > The solution is very easy: do not --reference a repository which resets or
> > deletes branches. IMHO this is all too obvious.
> > 
> 
> Or just do no repack in the referenced repo.

That is not the solution.

The error in your setup is to _rely_ on data which just _might go away_!

IOW do _not_ use an unreliable repository for --reference!

> Anyway, the discussion outlived its usefulness.
> I have what I wanted (git fsck --unreachable), and nobody can force
> me to repack my shared repo, so the issue does not exist for the original
> poster.

Well, I think unless you understand that you do something really fragile, 
the discussion did not yet outlive its usefulness.

Ciao,
Dscho

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]