Re: Multiple checkout copies

[David Kastrup]

Ivan Shmakov <address@hidden> writes:

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

In order not to accumulate temporary branches that are no longer present
in upstream?

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

Why would they?

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

Uh, it's going to get repacked anyway.  Git does that without asking.

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

Maybe it would be worth checking the man pages before making such
statements.  It's just annoying when people spray arbitrary statements
to the list and leave it to others to clean up.

git-fetch does not merge in any manner and consequently also does not
"fast-forward".  It updates references after making them backed by the
respective objects.  You are confusing this with the git-pull action of
updating a local branch based on a remote-tracking branch.

There is a very limited situation when using explicit branch names for
source and target branch where git-fetch will only update a reference to
a non-descendant when given the option -f.  Since there is no way to
trigger a "slow forward" (also known as "merge") without involving the
work directory and index, this is neither the same as a fast forward,
nor referenced as such.

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

"I'm typically interested in" is no base for promoting problematic
workflows since it violates the "do not use it unless you understand
what it does" dictum for the recipient of such a recipe.

-- 
David Kastrup