We have the following situation:
1) A .gitignore file that contains '*.pyc'
2) A repo with a submodule named jinja2
In normal use, clients of our repo have it checked out and run things
in it, creating files like jinja2/run.pyc.
I deleted the jinja2 submodule (by running `git rm jinja2` and
pushi
> 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
ymlinks the top-level .git/config directory, which lists a remote,
submodules, and many other things. Does symlinking the config file
for submodules add any new wrinkles, that symlinking the config file
for the top-level repository does not?
craig
On Fri, Jan 23, 2015 at 5:37 PM, Junio C Hamano
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.]
>
>
[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
~/khan/webapp/khan-exercises /tmp/webapp/khan-exercises
and saw that /tmp/webapp/khan-exercises was populated correctly,
/tmp/webapp/.git/modules/khan-exercises existed with symlinks, and
/tmp/webapp/khan-exercises/.git was a file with a 'gitdir:' entry
pointing to the .git/modules dire
time
to do, or would we be better off just waiting for the work-tree stuff
to get released? If I do end up doing it, would you be interested in
a pull request (or however patches are submitted in the git world)?
craig
On Mon, Dec 22, 2014 at 7:12 PM, Jonathan Nieder wrote:
> Craig Silverste
involves having some way to suppress the final 'git
checkout -f' (which is the only thing in this script that needs the
worktree entry to resolve somewhere) to allow for post-script cleanup.
craig
On Wed, Dec 17, 2014 at 4:07 PM, Jonathan Nieder wrote:
> Craig Silverstein wrote:
>&g
(Separated out from another thread since this issue seems more general.)
I am planning to use 'git new-workdir', which basically lets several
workspaces share a single .git/refs directory. (Among other dirs in
.git) It's possible that I'll end up running 'git fetch' in these
workspaces simultaneou
On Wed, Dec 17, 2014 at 2:32 PM, Jonathan Nieder wrote:
> You might find 'git new-workdir' from contrib/workdir to be helpful.
> It lets you attach multiple working copies to a single set of objects
> and refs.
Thanks! That does indeed sound promising -- like a more principled
version of my GIT_
At Khan Academy, we are running a Jenkins installation as our build
server. By design, our Jenkins machine has several different
directories that each hold a copy of the same git repository. (For
instance, Jenkins may be running tests on our repo at several
different commits at the same time.) W
11 matches
Mail list logo
