Re: Multiple checkout copies

[Ivan Shmakov <ivan@siamics.net>]

>>>>> David Kastrup <dak@gnu.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:
>>>>> David Kastrup <dak@gnu.org> writes:

[…]

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

	How would the branches “accumulate” in the case git-fetch(1) is
	given an explicit list of them to follow?

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

	Because the development happens in several branches in parallel?

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

	… Unless disabled with gc.auto = 0, gc.autopacklimit = 0.

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

	Well, would you then care to explain the wording of the Git
	error message below?

+ git fetch -t origin master:master
From git://github.com/XXX/XXX
 ! [rejected]        master     -> master  (non-fast-forward)

	Not to mention that git-fetch(1) explicitly uses this same term
	(as of Git 2.1.4.)

	I do not generally support the opinion that Git terminology is
	confusing, but I find it quite possible that it may sometimes be
	inconsistent at best.  Maybe it’s just such a case.

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

	Yes.

[…]

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

	The whole idea behind this discussion is to clarify when
	--shared is reasonable, — and when it isn’t.  Isn’t it?

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