Re: Multiple checkout copies

[Ivan Shmakov]

>>>>> David Kastrup <address@hidden> writes:
>>>>> Ivan Shmakov <address@hidden> writes:
>>>>> David Kastrup <address@hidden> writes:

[…]

 >>> No, it isn't.  You can have both local branches and remote branches
 >>> removed from the cloned bare repo while your --shared clone still
 >>> uses objects that are no longer retained in the first clone.

 >> “Can” in the sense that you /can/ use Git to shoot yourself in the
 >> foot, or are there cases where git-fetch(1) would indeed autoremove
 >> any branch references from a bare repository?

 > If you want to mirror the upstream, you'll use "git fetch -p" in
 > order to have branches that are removed upstream to get deleted in
 > the mirror as well.

        And why would I want that, especially given that I’m already
        aware that a. some of the objects may be used elsewhere (and
        thus such an operation would be potentially unsafe) and b. the
        packs received from the remote are likely to contain a mix of
        Git objects belonging to both removed and extant branches, and
        it would thus /not/ be possible to remove them anyway?

        And as for repacking such a mirror from time to time, — it’s
        going to be a sure nuisance due to backup reasons, etc.

 > Even without -p, references in frequently rewritten work branches
 > (like Git's pu or next branches) will disappear eventually.

        Do fast-forward updates (which git-fetch(1) defaults to) ever
        result in dangling Git objects?

        Also, I’m typically interested in mirroring just a few branches
        (mostly ‘master’ and the latest stable, if any.)  Per my
        experience, such branches rarely (if ever) get “rewritten.”

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A