* Re: Multiple checkout copies
2015-02-03 1:10 ` Richard Stallman
@ 2015-02-03 7:14 ` Ivan Shmakov
2015-02-03 10:02 ` Achim Gratz
2015-02-03 17:46 ` Stefan Monnier
2 siblings, 0 replies; 31+ messages in thread
From: Ivan Shmakov @ 2015-02-03 7:14 UTC (permalink / raw)
To: emacs-devel
>>>>> Richard Stallman <rms@gnu.org> writes:
[…]
>> Using --shared may be risky, as Git may choose to GC the dangling
>> objects away from emacs-1, not taking into account the possibility
>> of them being used in some other trees. In my case, the source
>> directory is often a “bare” Git repository used only to mirror the
>> upstream one, and thus it has no “local” commits, which are somewhat
>> likely to become dangling after rebases and such.
> Maybe I could use it in that way, but is there no way to make two
> working trees both checked out in parallel from the same repository?
I’m unsure I understand the purpose.
The problem is that a Git repository (as in: working-copy/.git)
is not just the graph of its respective commits, but also the
mapping of branch (and tag) names to commit identifiers. When a
working copy is updated (say, via $ git pull), the respective
branch name (.git/refs/heads/branchname) is also updated to
point to the new head commit of the branch. And I doubt that
sharing such a mapping among several working copies for the same
branch would be sensible.
The approach I use is roughly as follows.
First, I create a local clone of the remote repository /without/
an associated working copy, like:
$ git clone --bare -- \
git://example.org/jrh/example.git ~/public/download/git/example-2015.git
The repository so created can be updated with git-fetch(1):
$ GIT_DIR=~/public/download/git/example-2015.git \
git fetch -t origin master:master
… Or without giving the branches explicitly, should
example-2015.git/config contain an appropriate default, like:
[remote "origin"]
url = git://example.org/jrh/example.git
fetch = master:master example-42:example-42
The working copies may now be created from this local repository
(which git-clone(1) automatically aliases to ‘origin’)
with --shared, and updated with the regular $ git pull command
from there:
$ git clone --shared -- \
~/public/download/git/example-2015.git ~/devel/example-1
$ git clone --shared -- \
~/public/download/git/example-2015.git ~/devel/example-2
…
$ GIT_DIR=~/public/download/git/example-2015.git \
git fetch -t origin master:master ## update the “bare” repository
$ cd ~/devel/example-1
$ git pull origin ## update the working copy
This way, the commits which made it to the upstream are always
available from example-2015.git and get reused upon git-pull(1),
thus saving both time and filesystem space. Furthermore, unless
the upstream decides to “rewrite history” (at which point Git
will require manual intervention), these commits won’t be
eligible to GC, thus eliminating the risks generally associated
with --shared.
The commits made locally to either of the working copies stay in
that same working copy (unless explicitly copied.) I’m unsure
that those of them which get incorporated upstream (and thus
become available from example-2015.git) would be eligible for
GC, but any “temporary” histories held within the individual
example-N/.git (such as those left behind after a successful
$ git rebase) surely would.
The .git/refs/ mappings of these working copies are also
entirely independent.
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 1:10 ` Richard Stallman
2015-02-03 7:14 ` Ivan Shmakov
@ 2015-02-03 10:02 ` Achim Gratz
2015-02-03 10:22 ` David Kastrup
2015-02-03 17:46 ` Stefan Monnier
2 siblings, 1 reply; 31+ messages in thread
From: Achim Gratz @ 2015-02-03 10:02 UTC (permalink / raw)
To: emacs-devel
Richard Stallman writes:
> > $ git clone --shared emacs-1 emacs-2
>
> sounded like just the right thing until you posted
> the caveat. After this, I hesitate to use it:
>
> > Using --shared may be risky, as Git may choose to GC the
> > dangling objects away from emacs-1, not taking into account the
> > possibility of them being used in some other trees. In my case,
> > the source directory is often a “bare” Git repository used only
> > to mirror the upstream one, and thus it has no “local” commits,
> > which are somewhat likely to become dangling after rebases and
> > such.
That's mostly a red herring. The objects shared are hard-linked, so
even if the GC removes objects in a repository that doesn't reference
them anymore they continue to exist in the repository that still needs
them. As long as you do not delete that other repository you cannot
lose anything.
> Maybe I could use it in that way, but is there no way to make two
> working trees both checked out in parallel from the same repository?
The officially sanctioned Git way of getting a new worktree is to make
another clone. If you don't intend to use it as a full repository later
on, you can do a shallow clone or you can use another repository as an
"alternate" to skip copying / linking the object files.
There is a sort-of way of splitting off additional working trees, either
using the --work-tree argument or by setting the GIT_WORK_TREE
environment variable or even manipulating the core.worktree property of
the repository. But you can only ever make changes on a single worktree
anyway since a lot of meta-information regarding the worktree is also
kept in the repository, so while you have those multiple working
directories, only the last of them is properly "checked out".
The way to do this properly is to link all shared information back to
the original repository (I'd only ever use a bare one for this) and keep
the per-worktree files separated. The git-new-workdir script does this,
but it's still in contrib since it doesn't work on some systems.
http://git.kernel.org/cgit/git/git.git/tree/contrib/workdir/git-new-workdir
You are quite likely on a system where that script works, so it would
just be a matter of dropping it into /usr/lib/git and making it
executable.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 10:02 ` Achim Gratz
@ 2015-02-03 10:22 ` David Kastrup
2015-02-03 12:53 ` Achim Gratz
0 siblings, 1 reply; 31+ messages in thread
From: David Kastrup @ 2015-02-03 10:22 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-devel
Achim Gratz <Stromeko@nexgo.de> writes:
> Richard Stallman writes:
>> > $ git clone --shared emacs-1 emacs-2
>>
>> sounded like just the right thing until you posted
>> the caveat. After this, I hesitate to use it:
>>
>> > Using --shared may be risky, as Git may choose to GC the
>> > dangling objects away from emacs-1, not taking into account the
>> > possibility of them being used in some other trees. In my case,
>> > the source directory is often a “bare” Git repository used only
>> > to mirror the upstream one, and thus it has no “local” commits,
>> > which are somewhat likely to become dangling after rebases and
>> > such.
>
> That's mostly a red herring. The objects shared are hard-linked,
No, they aren't.
--shared, -s
When the repository to clone is on the local machine, instead of
using hard links, automatically setup .git/objects/info/alternates
to share the objects with the source repository. The resulting
repository starts out without any object of its own.
And that's what makes this operation potentially dangerous. --shared
has the advantage of never needing additional object space (the hard
links used otherwise will start out with just requiring additional
inodes, but as soon as objects get repacked, their contents are present
twice as well), and being effective even when the repository is not on
the same file system.
The manual explicitly states with regard to --shared
NOTE: this is a possibly dangerous operation; do not use it
unless you understand what it does.
And a corollary to "not not use it unless you understand what it does"
is "do not publish any recipes or workflows containing --shared" because
recipes or workflows are intended for the benefit of people not
understanding every step.
> so even if the GC removes objects in a repository that doesn't
> reference them anymore they continue to exist in the repository that
> still needs them. As long as you do not delete that other repository
> you cannot lose anything.
Apparently you confuse --shared with _not_ using --shared.
--
David Kastrup
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 10:22 ` David Kastrup
@ 2015-02-03 12:53 ` Achim Gratz
2015-02-03 13:15 ` David Kastrup
0 siblings, 1 reply; 31+ messages in thread
From: Achim Gratz @ 2015-02-03 12:53 UTC (permalink / raw)
To: emacs-devel
David Kastrup writes:
> Apparently you confuse --shared with _not_ using --shared.
Indeed, I was reading "--local" instead of "--shared", sorry. :-P
In any case, as long as the repo cloned via "--shared" is a bare
repository that was cloned from upstream Emacs and you do not clone the
second generation again in this manner, "--shared" is still safe. The
possible copy of objects when repack operations are run makes this less
useful as a space-saving measure than one would think, however. It can
still be a net win for throw-away clones needed during a build.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 12:53 ` Achim Gratz
@ 2015-02-03 13:15 ` David Kastrup
2015-02-03 13:37 ` Ivan Shmakov
0 siblings, 1 reply; 31+ messages in thread
From: David Kastrup @ 2015-02-03 13:15 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-devel
Achim Gratz <Stromeko@nexgo.de> writes:
> David Kastrup writes:
>> Apparently you confuse --shared with _not_ using --shared.
>
> Indeed, I was reading "--local" instead of "--shared", sorry. :-P
>
> In any case, as long as the repo cloned via "--shared" is a bare
> repository that was cloned from upstream Emacs and you do not clone the
> second generation again in this manner, "--shared" is still safe.
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.
> It can still be a net win for throw-away clones needed during a build.
Basically the only sensible use is for temporary clones used (and
deleted again) within a script.
--
David Kastrup
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 13:15 ` David Kastrup
@ 2015-02-03 13:37 ` Ivan Shmakov
2015-02-03 13:57 ` David Kastrup
0 siblings, 1 reply; 31+ messages in thread
From: Ivan Shmakov @ 2015-02-03 13:37 UTC (permalink / raw)
To: emacs-devel
>>>>> David Kastrup <dak@gnu.org> writes:
>>>>> Achim Gratz <Stromeko@nexgo.de> writes:
[…]
>> In any case, as long as the repo cloned via "--shared" is a bare
>> repository that was cloned from upstream Emacs and you do not clone
>> the second generation again in this manner, "--shared" is still
>> safe.
> 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?
>> It can still be a net win for throw-away clones needed during a
>> build.
> Basically the only sensible use is for temporary clones used (and
> deleted again) within a script.
I use a separate filesystem for local mirrors, including those
of upstream Git repositories. Thus, --shared is pretty much the
only space-saving option.
Works for me that way since c. 2008.
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 13:37 ` Ivan Shmakov
@ 2015-02-03 13:57 ` David Kastrup
2015-02-03 18:30 ` Ivan Shmakov
0 siblings, 1 reply; 31+ messages in thread
From: David Kastrup @ 2015-02-03 13:57 UTC (permalink / raw)
To: emacs-devel
Ivan Shmakov <ivan@siamics.net> writes:
>>>>>> David Kastrup <dak@gnu.org> writes:
>>>>>> Achim Gratz <Stromeko@nexgo.de> writes:
>
> […]
>
> >> In any case, as long as the repo cloned via "--shared" is a bare
> >> repository that was cloned from upstream Emacs and you do not clone
> >> the second generation again in this manner, "--shared" is still
> >> safe.
>
> > 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. Even without -p, references in frequently rewritten work
branches (like Git's pu or next branches) will disappear eventually.
> >> It can still be a net win for throw-away clones needed during a
> >> build.
>
> > Basically the only sensible use is for temporary clones used (and
> > deleted again) within a script.
>
> I use a separate filesystem for local mirrors, including those
> of upstream Git repositories. Thus, --shared is pretty much the
> only space-saving option.
>
> Works for me that way since c. 2008.
"Works for me" is subject to "until it doesn't". Which is the whole
point about warning about potentially dangerous operations.
--
David Kastrup
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 13:57 ` David Kastrup
@ 2015-02-03 18:30 ` Ivan Shmakov
2015-02-03 18:53 ` David Kastrup
0 siblings, 1 reply; 31+ messages in thread
From: Ivan Shmakov @ 2015-02-03 18:30 UTC (permalink / raw)
To: emacs-devel
>>>>> David Kastrup <dak@gnu.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:
>>>>> David Kastrup <dak@gnu.org> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 18:30 ` Ivan Shmakov
@ 2015-02-03 18:53 ` David Kastrup
2015-02-03 19:17 ` Ivan Shmakov
0 siblings, 1 reply; 31+ messages in thread
From: David Kastrup @ 2015-02-03 18:53 UTC (permalink / raw)
To: emacs-devel
Ivan Shmakov <ivan@siamics.net> writes:
>>>>>> David Kastrup <dak@gnu.org> writes:
>>>>>> Ivan Shmakov <ivan@siamics.net> writes:
>>>>>> David Kastrup <dak@gnu.org> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 18:53 ` David Kastrup
@ 2015-02-03 19:17 ` Ivan Shmakov
2015-02-03 19:41 ` David Kastrup
0 siblings, 1 reply; 31+ messages in thread
From: Ivan Shmakov @ 2015-02-03 19:17 UTC (permalink / raw)
To: emacs-devel
>>>>> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 19:17 ` Ivan Shmakov
@ 2015-02-03 19:41 ` David Kastrup
2015-02-03 20:25 ` Ivan Shmakov
2015-02-04 23:02 ` Richard Stallman
0 siblings, 2 replies; 31+ messages in thread
From: David Kastrup @ 2015-02-03 19:41 UTC (permalink / raw)
To: emacs-devel
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.
In addition, we've had --shared confused with --local (which is implied
anyway). So the takeaway is not to use any options in connection with
creating local clones manually. 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.
--
David Kastrup
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 19:41 ` David Kastrup
@ 2015-02-03 20:25 ` Ivan Shmakov
2015-02-04 23:02 ` Richard Stallman
1 sibling, 0 replies; 31+ messages in thread
From: Ivan Shmakov @ 2015-02-03 20:25 UTC (permalink / raw)
To: emacs-devel
>>>>> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 19:41 ` David Kastrup
2015-02-03 20:25 ` Ivan Shmakov
@ 2015-02-04 23:02 ` Richard Stallman
1 sibling, 0 replies; 31+ messages in thread
From: Richard Stallman @ 2015-02-04 23:02 UTC (permalink / raw)
To: David Kastrup; +Cc: emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
I am pretty sure I don't want to use --shared.
Could we take the dispute about it off this list?
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! See stallman.org/skype.html.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Multiple checkout copies
2015-02-03 1:10 ` Richard Stallman
2015-02-03 7:14 ` Ivan Shmakov
2015-02-03 10:02 ` Achim Gratz
@ 2015-02-03 17:46 ` Stefan Monnier
2 siblings, 0 replies; 31+ messages in thread
From: Stefan Monnier @ 2015-02-03 17:46 UTC (permalink / raw)
To: Richard Stallman; +Cc: Ivan Shmakov, emacs-devel
> Maybe I could use it in that way, but is there no way to make two
> working trees both checked out in parallel from the same repository?
If you mean "same remote repository", then you can simply "cp -a" and
that will work fine (tho there are many other ways to do it).
If you mean "same local repository", then the only option is
git-new-workdir (which is what I use).
Stefan
^ permalink raw reply [flat|nested] 31+ messages in thread