From: Junio C Hamano <hidden> Date: 2016-06-15 22:55:29
Robin Rosenberg [off-list ref] writes:
If core.symlinks is set to copy then symbolic links in a git repository
will be checked out as copies of the file it points to.
That all sounds nice on surface when the primary thing you care
about is to fetch and check out other people's code and extract it
to the working tree, but how well would that work on the checkin
side? What happens if I check out a symlink that points at a file
(either in-tree or out-of-tree), make some changes that do not
involve the symlink, and before I make the commit, an unrelated
change is made to the file the symlink is pointing at?
- git status - when do we report a diff.
- After checkout we should probably not
- if the "linked" files change?
Yeah, exactly.
- if a change in the copied directory chsnges
That, too.
- if a file in the copied diretory is added/removed
- update, should we update the copied structure automatically
when the link target changes
I personally do not think this is worth it. It would be very useful
on the export/checkout side, so it may make sense to add it to "git
archive", though.
From: Robin Rosenberg <hidden> Date: 2016-06-15 22:55:29
----- Ursprungligt meddelande -----
Robin Rosenberg [off-list ref] writes:
quoted
If core.symlinks is set to copy then symbolic links in a git
repository
will be checked out as copies of the file it points to.
That all sounds nice on surface when the primary thing you care
about is to fetch and check out other people's code and extract it
to the working tree, but how well would that work on the checkin
side? What happens if I check out a symlink that points at a file
(either in-tree or out-of-tree), make some changes that do not
involve the symlink, and before I make the commit, an unrelated
change is made to the file the symlink is pointing at?
quoted
- git status - when do we report a diff.
- After checkout we should probably not
- if the "linked" files change?
Yeah, exactly.
quoted
- if a change in the copied directory chsnges
That, too.
quoted
- if a file in the copied diretory is added/removed
- update, should we update the copied structure automatically
when the link target changes
Some of the questions have proposals in the includes test script. A
little more dangerous than having real symlinks ofcourse, but regardless
of what one does with or without copied symlinks one can make mistakes
and I feel letting Git do the copying is way better than having real
copies in the git repository. Another crappy scm which the users are
converting from does this and it works. A difference to git is that
it (ok clearcase) makes all files read-only so there are fewer mays
of making mistakes with the copies.
I personally do not think this is worth it. It would be very useful
on the export/checkout side, so it may make sense to add it to "git
archive", though.
It makes sense, but it does not solve the problem at hand.
-- robin
From: Michael J Gruber <hidden> Date: 2016-06-15 22:55:30
Robin Rosenberg venit, vidit, dixit 06.12.2012 02:23:
----- Ursprungligt meddelande -----
quoted
Robin Rosenberg [off-list ref] writes:
quoted
If core.symlinks is set to copy then symbolic links in a git
repository
will be checked out as copies of the file it points to.
That all sounds nice on surface when the primary thing you care
about is to fetch and check out other people's code and extract it
to the working tree, but how well would that work on the checkin
side? What happens if I check out a symlink that points at a file
(either in-tree or out-of-tree), make some changes that do not
involve the symlink, and before I make the commit, an unrelated
change is made to the file the symlink is pointing at?
quoted
- git status - when do we report a diff.
- After checkout we should probably not
- if the "linked" files change?
Yeah, exactly.
quoted
- if a change in the copied directory chsnges
That, too.
quoted
- if a file in the copied diretory is added/removed
- update, should we update the copied structure automatically
when the link target changes
Some of the questions have proposals in the includes test script. A
little more dangerous than having real symlinks ofcourse, but regardless
of what one does with or without copied symlinks one can make mistakes
and I feel letting Git do the copying is way better than having real
copies in the git repository. Another crappy scm which the users are
converting from does this and it works. A difference to git is that
it (ok clearcase) makes all files read-only so there are fewer mays
of making mistakes with the copies.
quoted
I personally do not think this is worth it. It would be very useful
on the export/checkout side, so it may make sense to add it to "git
archive", though.
It makes sense, but it does not solve the problem at hand.
-- robin
Well, what is the problem at hand?
Your commit message begins in present tense as if it described the
current state of git, when in fact it describes what the patch is about
to achieve. This is confusing enough already,
I don't see any mention of the purpose, other than "content may be
used", which would be served perfectly by a copy-on-link feature on the
export side, as mentioned by Junio. Is git-archive|tar an option?
Michael
From: Robin Rosenberg <hidden> Date: 2016-06-15 22:55:30
----- Ursprungligt meddelande -----
Robin Rosenberg venit, vidit, dixit 06.12.2012 02:23:
quoted
----- Ursprungligt meddelande -----
quoted
Robin Rosenberg [off-list ref] writes:
quoted
If core.symlinks is set to copy then symbolic links in a git
repository
will be checked out as copies of the file it points to.
That all sounds nice on surface when the primary thing you care
about is to fetch and check out other people's code and extract it
to the working tree, but how well would that work on the checkin
side? What happens if I check out a symlink that points at a file
(either in-tree or out-of-tree), make some changes that do not
involve the symlink, and before I make the commit, an unrelated
change is made to the file the symlink is pointing at?
quoted
- git status - when do we report a diff.
- After checkout we should probably not
- if the "linked" files change?
Yeah, exactly.
quoted
- if a change in the copied directory chsnges
That, too.
quoted
- if a file in the copied diretory is added/removed
- update, should we update the copied structure automatically
when the link target changes
Some of the questions have proposals in the includes test script. A
little more dangerous than having real symlinks ofcourse, but
regardless
of what one does with or without copied symlinks one can make
mistakes
and I feel letting Git do the copying is way better than having
real
copies in the git repository. Another crappy scm which the users
are
converting from does this and it works. A difference to git is that
it (ok clearcase) makes all files read-only so there are fewer mays
of making mistakes with the copies.
quoted
I personally do not think this is worth it. It would be very
useful
on the export/checkout side, so it may make sense to add it to
"git
archive", though.
It makes sense, but it does not solve the problem at hand.
-- robin
Well, what is the problem at hand?
The problem is that I'm converting a repo from clearcase to git and
there are lots of symbolic links. Symbolic links in clearcase on
Windows is treated as file copy in snapshot views which means that
you get a copy of the linked file when you update the view. If the
link target changes you can update your view to refersh your copies.
Your commit message begins in present tense as if it described the
current state of git, when in fact it describes what the patch is
about
to achieve. This is confusing enough already,
You're right.
I don't see any mention of the purpose, other than "content may be
used", which would be served perfectly by a copy-on-link feature on
the
export side, as mentioned by Junio. Is git-archive|tar an option?
I want the copy on checkout. The intent is to change things and
then commit.
Perhaps I can convince people to let a script copy stuff instead.
-- robin