On Fri, Sep 02, 2016 at 11:01:54AM +0200, Dennis Kaarsemaker wrote:
> Well, 'git init' is a valid operation to run inside an existing repo to
> reinitialize some bits, so we definitely need to not ignore the config
> once we're sure we're not creating a new repo.
Good point, I hadn't considered r
On vr, 2016-09-02 at 04:04 -0400, Jeff King wrote:
> On Wed, Aug 31, 2016 at 05:32:33PM +0200, Dennis Kaarsemaker wrote:
>
> >
> > >
> > > We may need to do something like turn off the
> > > need_shared_repository_from_config in init-db, since I think it would
> > > not want to ever read from th
On Fri, Sep 02, 2016 at 04:04:16AM -0400, Jeff King wrote:
> So here's the minimal fix that seems to work for me:
>
> diff --git a/builtin/init-db.c b/builtin/init-db.c
> index 3a45f0b..56e7b9a 100644
> --- a/builtin/init-db.c
> +++ b/builtin/init-db.c
I also wonder if "clone" should be doing so
On Wed, Aug 31, 2016 at 05:32:33PM +0200, Dennis Kaarsemaker wrote:
> > We may need to do something like turn off the
> > need_shared_repository_from_config in init-db, since I think it would
> > not want to ever read from the default config sources in most of its
> > code-paths (OTOH, it should i
On wo, 2016-08-31 at 06:48 -0400, Jeff King wrote:
> On Wed, Aug 31, 2016 at 11:12:26AM +0200, Dennis Kaarsemaker wrote:
>
> >
> > That is indeed a bug. git reads the config of t1 and then thinks a
> > template config has set that value, so it won't override it.
> This is a regression in v2.9.0 d
On Wed, Aug 31, 2016 at 11:12:26AM +0200, Dennis Kaarsemaker wrote:
> That is indeed a bug. git reads the config of t1 and then thinks a
> template config has set that value, so it won't override it.
This is a regression in v2.9.0 due to my ae5f677 (lazily load
core.sharedrepository, 2016-03-11).
That is indeed a bug. git reads the config of t1 and then thinks a
template config has set that value, so it won't override it.
This is caused by git init reading the config via
get_shared_repository. The comment above it indicates that this may not
be needed, and indeed not doing it makes this bu
Hi there,
If 'git init /path/to/repo' is called inside another repository with
'core.logallrefupdates' set to true, it will be not set by default in the
created repository.
This seems to be a bug.
I am using Git v2.9.3 (Arch).
Steps to reproduce:
-
git init t1
cd
8 matches
Mail list logo