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-
On Wed, Jan 28, 2015 at 5:50 PM, Duy Nguyen 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
config.local, bu
Duy Nguyen writes:
> On Wed, Jan 28, 2015 at 5:50 PM, Duy Nguyen 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.
Am 26.01.2015 um 06:39 schrieb Junio C Hamano:
Craig Silverstein 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 s
Craig Silverstein 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
multiple work tree serie
> 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
Craig Silverstein 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 it existed before m
} 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 top-
Craig Silverstein 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 working-tree
>> stat
Ping! (now that the holidays are past)
craig
On Tue, Dec 23, 2014 at 1:51 PM, Craig Silverstein
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 Hamano pobox.com> wr
[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 pobox.com> writes:
>
> H, does that mean that the submodule S in the original
> repository O's working tree and its checkout
Craig Silverstein 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: `. This is a problem
> because the submodule's config file has an entry like `worktree =
> ../../../kh
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: `. This is a problem
because the submodule's config file has an entry like `worktree =
../../../khan-exercises` which is relative to ""
13 matches
Mail list logo
