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:

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

 > And the manual page clearly states that it requires to know what you
 > are doing.  That makes it feasible for use in a script, and
 > unfeasible for use in a recipe: the latter _can_ and will be varied,
 > violating the "do not use it unless you understand what it does"
 > prerequisite given in its manual page.

 > And all of the handwaving and qualifications _after_ having the
 > problems pointed out make _very_ obvious that the required
 > information for using it safely is not likely to be communicated in
 > informal discussions.

	I’m getting an impression that the above should make me feeling
	guilt or ashamed of sharing my workflow with the audience.

	But I still do not, nor see the reason to.

 > In addition, we've had --shared confused with --local (which is
 > implied anyway).

	FTR, in my initial message, I’ve indeed confused --shared with
	--local as the /default/ for git-clone(1), and even corrected
	myself [1].  I didn’t confuse the /effects/ of these options.

 > So the takeaway is not to use any options in connection with creating
 > local clones manually.

	I disagree.

 > That steers around all of the not reliably reproducible problems, at
 > a mostly moderate cost in disk usage.

 > "Handling a foot gun is not hard and can be fun" is a frequent
 > software engineering pain vector.

	In this discussion, I saw no scenario under which my approach,
	as given in [1], would fail (but surely would appreciate any.)

	It wasn’t my intent to make claims regarding the use of --shared
	outside of that particular approach.

[1] news:87oapcgp2c.fsf@violet.siamics.net
    http://permalink.gmane.org/gmane.emacs.devel/182278

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