threads / patch / 13164

patch, 8 partsAdd a function to set a non-default work tree

Subject: [PATCH 4/8] Add a function to set a non-default work tree

## tl;dr

6 messages between Apr 17, 2008 and Apr 22, 2008. Diffs are folded; open one to read it.

replies: 5people: 3as markdown or json

Daniel Barkalow· Apr 17, 2008, 23:32 UTC · lore

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
 cache.h       |    1 +
 environment.c |    6 ++++++
 2 files changed, 7 insertions(+), 0 deletions(-)

Show changes to 2 files +7 −0

cache.h, environment.c

diff --git a/cache.h b/cache.h
index 96dcb49..d88a4e2 100644
--- a/cache.h
+++ b/cache.h
@@ -311,6 +311,7 @@ extern char *get_index_file(void);
 extern char *get_graft_file(void);
 extern int set_git_dir(const char *path);
 extern const char *get_git_work_tree(void);
+extern void set_git_work_tree(const char *tree);
 
 #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
 
diff --git a/environment.c b/environment.c
index 6739a3f..d6c6a6b 100644
--- a/environment.c
+++ b/environment.c
@@ -81,6 +81,12 @@ const char *get_git_dir(void)
 	return git_dir;
 }
 
+void set_git_work_tree(const char *new_work_tree)
+{
+	get_git_work_tree(); /* make sure it's initialized */
+	work_tree = xstrdup(make_absolute_path(new_work_tree));
+}
+
 const char *get_git_work_tree(void)
 {
 	static int initialized = 0;

-- 
1.5.4.3.610.gea6cd

Johan Herland· Apr 19, 2008, 17:33 UTC · re: Daniel Barkalow · lore

Re: [PATCH 4/8] Add a function to set a non-default work tree

On Friday 18 April 2008, Daniel Barkalow wrote:

Show 30 quoted lines

> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> ---
>  cache.h       |    1 +
>  environment.c |    6 ++++++
>  2 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/cache.h b/cache.h
> index 96dcb49..d88a4e2 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -311,6 +311,7 @@ extern char *get_index_file(void);
>  extern char *get_graft_file(void);
>  extern int set_git_dir(const char *path);
>  extern const char *get_git_work_tree(void);
> +extern void set_git_work_tree(const char *tree);
>  
>  #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
>  
> diff --git a/environment.c b/environment.c
> index 6739a3f..d6c6a6b 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -81,6 +81,12 @@ const char *get_git_dir(void)
>  	return git_dir;
>  }
>  
> +void set_git_work_tree(const char *new_work_tree)
> +{
> +	get_git_work_tree(); /* make sure it's initialized */
> +	work_tree = xstrdup(make_absolute_path(new_work_tree));

Shouldn't we free(work_tree) before resetting it?

Show 5 quoted lines

> +}
> +
>  const char *get_git_work_tree(void)
>  {
>  	static int initialized = 0;

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Junio C Hamano· Apr 20, 2008, 05:07 UTC · re: Daniel Barkalow · lore

Re: [PATCH 4/8] Add a function to set a non-default work tree

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 32 quoted lines

> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> ---
>  cache.h       |    1 +
>  environment.c |    6 ++++++
>  2 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index 96dcb49..d88a4e2 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -311,6 +311,7 @@ extern char *get_index_file(void);
>  extern char *get_graft_file(void);
>  extern int set_git_dir(const char *path);
>  extern const char *get_git_work_tree(void);
> +extern void set_git_work_tree(const char *tree);
>  
>  #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
>  
> diff --git a/environment.c b/environment.c
> index 6739a3f..d6c6a6b 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -81,6 +81,12 @@ const char *get_git_dir(void)
>  	return git_dir;
>  }
>  
> +void set_git_work_tree(const char *new_work_tree)
> +{
> +	get_git_work_tree(); /* make sure it's initialized */
> +	work_tree = xstrdup(make_absolute_path(new_work_tree));
> +}
> +

Somehow this feels wrong. Maybe you would need to move that "static int" variable inside get_git_work_tree() outside so that you can reset from this new function at will?

How should the setting of new work tree from sideways using this interface interact with bareness of the repository?

Should it reset is_bare_repository_cfg to zero? Should it refuse to set a work tree if is_bare_repository_cfg is true already?

Daniel Barkalow· Apr 20, 2008, 19:52 UTC · re: Junio C Hamano · lore

Re: [PATCH 4/8] Add a function to set a non-default work tree

On Sat, 19 Apr 2008, Junio C Hamano wrote:

Show 38 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> > ---
> >  cache.h       |    1 +
> >  environment.c |    6 ++++++
> >  2 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/cache.h b/cache.h
> > index 96dcb49..d88a4e2 100644
> > --- a/cache.h
> > +++ b/cache.h
> > @@ -311,6 +311,7 @@ extern char *get_index_file(void);
> >  extern char *get_graft_file(void);
> >  extern int set_git_dir(const char *path);
> >  extern const char *get_git_work_tree(void);
> > +extern void set_git_work_tree(const char *tree);
> >  
> >  #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
> >  
> > diff --git a/environment.c b/environment.c
> > index 6739a3f..d6c6a6b 100644
> > --- a/environment.c
> > +++ b/environment.c
> > @@ -81,6 +81,12 @@ const char *get_git_dir(void)
> >  	return git_dir;
> >  }
> >  
> > +void set_git_work_tree(const char *new_work_tree)
> > +{
> > +	get_git_work_tree(); /* make sure it's initialized */
> > +	work_tree = xstrdup(make_absolute_path(new_work_tree));
> > +}
> > +
> 
> Somehow this feels wrong.  Maybe you would need to move that "static int"
> variable inside get_git_work_tree() outside so that you can reset from
> this new function at will?

Yeah, that's better.

> How should the setting of new work tree from sideways using this interface
> interact with bareness of the repository?

I'm only using it before any initialization and when I'm going to force the repository (which doesn't even exist yet; I haven't set git_dir let alone created it, let alone looked at its configuration) to be bare, so I hadn't considered that.

> Should it reset is_bare_repository_cfg to zero?  Should it refuse to set a
> work tree if is_bare_repository_cfg is true already?

is_bare_repository_cfg starts out -1 (not yet specified); this should probably set it to false and require that it not have been specified previously.

	-Daniel
*This .sig left intentionally blank*

Junio C Hamano· Apr 22, 2008, 00:09 UTC · re: Daniel Barkalow · lore

Re: [PATCH 4/8] Add a function to set a non-default work tree

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 9 quoted lines

> On Sat, 19 Apr 2008, Junio C Hamano wrote:
> ...
>> How should the setting of new work tree from sideways using this interface
>> interact with bareness of the repository?
>
> I'm only using it before any initialization and when I'm going to force 
> the repository (which doesn't even exist yet; I haven't set git_dir let 
> alone created it, let alone looked at its configuration) to be bare, so I 
> hadn't considered that.

That is not quite an explanation that builds confidence in a patch that adds a generic-sounding helper function that could be called by later callers. Doesn't it have a very tempting name for people to call?

Daniel Barkalow· Apr 22, 2008, 03:47 UTC · re: Junio C Hamano · lore

Re: [PATCH 4/8] Add a function to set a non-default work tree

On Mon, 21 Apr 2008, Junio C Hamano wrote:

Show 15 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > On Sat, 19 Apr 2008, Junio C Hamano wrote:
> > ...
> >> How should the setting of new work tree from sideways using this interface
> >> interact with bareness of the repository?
> >
> > I'm only using it before any initialization and when I'm going to force 
> > the repository (which doesn't even exist yet; I haven't set git_dir let 
> > alone created it, let alone looked at its configuration) to be bare, so I 
> > hadn't considered that.
> 
> That is not quite an explanation that builds confidence in a patch that
> adds a generic-sounding helper function that could be called by later
> callers.  Doesn't it have a very tempting name for people to call?

My latest version has it die() if you've gotten meaningfully far in initializing the repository state. I'm also not sure there's a tempting use case for it aside for in setup code where it clearly works, at least until we've got support for dealing with multiple working trees in the same process or something of that sort. But, in any case, it'll now fail fast and obviously outside of what I've planned for.

	-Daniel
*This .sig left intentionally blank*