Duy Nguyen pclo...@gmail.com writes:
On Wed, Jan 28, 2015 at 5:50 PM, Duy Nguyen pclo...@gmail.com wrote:
For git-new-workdir.sh, perhaps we can teach include.path to make
config.local path relative to where the config symlink is, not where
the symlink target is.
Ignore this part. I
On Tue, Jan 27, 2015 at 06:35:41PM +0100, Jens Lehmann wrote:
One way to do so might be to move the bits it stores in the config
file to somewhere else that is more closely tied to the checkout
state and handle that similar to .git/index and .git/HEAD when it
comes to multiple work-trees.
On Wed, Jan 28, 2015 at 5:50 PM, Duy Nguyen pclo...@gmail.com wrote:
For git-new-workdir.sh, perhaps we can teach include.path to make
config.local path relative to where the config symlink is, not where
the symlink target is.
Ignore this part. I originally wanted to use include.path to load
Am 26.01.2015 um 06:39 schrieb Junio C Hamano:
Craig Silverstein csilv...@khanacademy.org writes:
This patch, in adding submodule support, I expect would be
similarly useful to people even though it, also, imposes those
same constraints to the submodule's config files.
I would expect that
Craig Silverstein csilv...@khanacademy.org writes:
This patch, in adding submodule support, I expect would be
similarly useful to people even though it, also, imposes those
same constraints to the submodule's config files.
I would expect that you would see exactly the same issue with Duy's
Craig Silverstein csilv...@khanacademy.org writes:
} Or one new-workdir checkout's branch may check out a top-level
} project from today while the other one may have a top-level project
} from two years ago,
This is also true, but just as much a problem with the 'git
new-workdir' script as
But then, you are saying that the update does not fix these existing
issues around submodule support. So...?
I guess my point is that the existing contrib script has proven to be
useful to people, even though it imposes these constraints on clients
wrt the config file (namely, you can't have
} Or one new-workdir checkout's branch may check out a top-level
} project from today while the other one may have a top-level project
} from two years ago,
This is also true, but just as much a problem with the 'git
new-workdir' script as it existed before my change. It already
symlinks the
Ping! (now that the holidays are past)
craig
On Tue, Dec 23, 2014 at 1:51 PM, Craig Silverstein
csilv...@khanacademy.org wrote:
[Ack, I forgot to cc myself on the original patch so now I can't reply
to it normally. Hopefully my workaround doesn't mess up the threading
too badly.]
Junio C
Craig Silverstein csilv...@khanacademy.org writes:
Doesn't a submodule checkout keep some state tied to the working
tree in its repository configuration file?
Do you mean, in 'config' itself? If so, I don't see it. (Though it's
possible there are ways to use submodules that do keep
The basic problem with submodules, from git-new-workdir's point of
view, is that instead of having a .git directory, they have a .git
file with contents `gitdir: some other path`. This is a problem
because the submodule's config file has an entry like `worktree =
../../../khan-exercises` which is
Craig Silverstein csilvers.m...@gmail.com writes:
The basic problem with submodules, from git-new-workdir's point of
view, is that instead of having a .git directory, they have a .git
file with contents `gitdir: some other path`. This is a problem
because the submodule's config file has an
[Ack, I forgot to cc myself on the original patch so now I can't reply
to it normally. Hopefully my workaround doesn't mess up the threading
too badly.]
Junio C Hamano gitster at pobox.com writes:
H, does that mean that the submodule S in the original
repository O's working tree and its
13 matches
Mail list logo
