threads / patch / 39594

patchAllow to control the namespace for replace refs

Subject: [PATCH] Allow to control the namespace for replace refs

## tl;dr

9 messages between Jun 11, 2015 and Jun 12, 2015. Diffs are folded; open one to read it.

replies: 8people: 2as markdown or json

Mike Hommey· Jun 11, 2015, 01:47 UTC · lore

It can be useful to have grafts or replace refs for specific use-cases while keeping the default "view" of the repository pristine (or with a different set of grafts/replace refs).

It is possible to use a different graft file with GIT_GRAFT_FILE, but while replace refs are more powerful, they don't have an equivalent override.

Add a GIT_REPLACE_NAMESPACE environment variable to control where git is going to look for replace refs.

Signed-off-by: Mike Hommey <mh@glandium.org>
---

I'm not sure if I need to care about avoiding strlen in log-tree.c, or if I should handle the lack of a / at the end of GIT_REPLACE_NAMESPACE.

 builtin/replace.c | 6 +++---
 cache.h           | 2 ++
 environment.c     | 6 ++++++
 log-tree.c        | 5 +++--
 refs.c            | 3 ++-
 5 files changed, 16 insertions(+), 6 deletions(-)
Show changes to 5 files +16 −6

builtin/replace.c, cache.h, environment.c, log-tree.c, refs.c

diff --git a/builtin/replace.c b/builtin/replace.c
index 54bf01a..bb5bc84 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -104,9 +104,9 @@ static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
 			continue;
 		}
 		full_hex = sha1_to_hex(sha1);
-		snprintf(ref, sizeof(ref), "refs/replace/%s", full_hex);
+		snprintf(ref, sizeof(ref), "%s%s", git_replace_namespace, full_hex);
 		/* read_ref() may reuse the buffer */
-		full_hex = ref + strlen("refs/replace/");
+		full_hex = ref + strlen(git_replace_namespace);
 		if (read_ref(ref, sha1)) {
 			error("replace ref '%s' not found.", full_hex);
 			had_error = 1;
@@ -134,7 +134,7 @@ static void check_ref_valid(unsigned char object[20],
 			    int force)
 {
 	if (snprintf(ref, ref_size,
-		     "refs/replace/%s",
+		     "%s%s", git_replace_namespace,
 		     sha1_to_hex(object)) > ref_size - 1)
 		die("replace ref name too long: %.*s...", 50, ref);
 	if (check_refname_format(ref, 0))
diff --git a/cache.h b/cache.h
index badf3da..9553edc 100644
--- a/cache.h
+++ b/cache.h
@@ -384,6 +384,7 @@ static inline enum object_type object_type(unsigned int mode)
 #define EXEC_PATH_ENVIRONMENT "GIT_EXEC_PATH"
 #define CEILING_DIRECTORIES_ENVIRONMENT "GIT_CEILING_DIRECTORIES"
 #define NO_REPLACE_OBJECTS_ENVIRONMENT "GIT_NO_REPLACE_OBJECTS"
+#define GIT_REPLACE_NAMESPACE_ENVIRONMENT "GIT_REPLACE_NAMESPACE"
 #define GITATTRIBUTES_FILE ".gitattributes"
 #define INFOATTRIBUTES_FILE "info/attributes"
 #define ATTRIBUTE_MACRO_PREFIX "[attr]"
@@ -605,6 +606,7 @@ extern unsigned long pack_size_limit_cfg;
  * been sought but there were none.
  */
 extern int check_replace_refs;
+extern char *git_replace_namespace;
 
 extern int fsync_object_files;
 extern int core_preload_index;
diff --git a/environment.c b/environment.c
index a40044c..c836b61 100644
--- a/environment.c
+++ b/environment.c
@@ -47,6 +47,7 @@ const char *askpass_program;
 const char *excludes_file;
 enum auto_crlf auto_crlf = AUTO_CRLF_FALSE;
 int check_replace_refs = 1;
+char *git_replace_namespace;
 enum eol core_eol = EOL_UNSET;
 enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
 unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
@@ -109,6 +110,7 @@ const char * const local_repo_env[] = {
 	GRAFT_ENVIRONMENT,
 	INDEX_ENVIRONMENT,
 	NO_REPLACE_OBJECTS_ENVIRONMENT,
+	GIT_REPLACE_NAMESPACE_ENVIRONMENT,
 	GIT_PREFIX_ENVIRONMENT,
 	GIT_SHALLOW_FILE_ENVIRONMENT,
 	NULL
@@ -145,6 +147,7 @@ static void setup_git_env(void)
 {
 	const char *gitfile;
 	const char *shallow_file;
+	const char *replace_namespace;
 
 	git_dir = getenv(GIT_DIR_ENVIRONMENT);
 	if (!git_dir)
@@ -156,6 +159,9 @@ static void setup_git_env(void)
 	git_graft_file = git_path_from_env(GRAFT_ENVIRONMENT, "info/grafts");
 	if (getenv(NO_REPLACE_OBJECTS_ENVIRONMENT))
 		check_replace_refs = 0;
+	replace_namespace = getenv(GIT_REPLACE_NAMESPACE_ENVIRONMENT);
+	git_replace_namespace = xstrdup(replace_namespace ? replace_namespace
+							  : "refs/replace/");
 	namespace = expand_namespace(getenv(GIT_NAMESPACE_ENVIRONMENT));
 	namespace_len = strlen(namespace);
 	shallow_file = getenv(GIT_SHALLOW_FILE_ENVIRONMENT);
diff --git a/log-tree.c b/log-tree.c
index c931615..9e60137 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -96,11 +96,12 @@ static int add_ref_decoration(const char *refname, const unsigned char *sha1, in
 
 	assert(cb_data == NULL);
 
-	if (starts_with(refname, "refs/replace/")) {
+	if (starts_with(refname, git_replace_namespace)) {
 		unsigned char original_sha1[20];
 		if (!check_replace_refs)
 			return 0;
-		if (get_sha1_hex(refname + 13, original_sha1)) {
+		if (get_sha1_hex(refname + strlen(git_replace_namespace),
+				 original_sha1)) {
 			warning("invalid replace ref %s", refname);
 			return 0;
 		}
diff --git a/refs.c b/refs.c
index 67d6745..0993d1c 100644
--- a/refs.c
+++ b/refs.c
@@ -2089,7 +2089,8 @@ int for_each_remote_ref_submodule(const char *submodule, each_ref_fn fn, void *c
 
 int for_each_replace_ref(each_ref_fn fn, void *cb_data)
 {
-	return do_for_each_ref(&ref_cache, "refs/replace/", fn, 13, 0, cb_data);
+	return do_for_each_ref(&ref_cache, git_replace_namespace, fn,
+			       strlen(git_replace_namespace), 0, cb_data);
 }
 
 int head_ref_namespaced(each_ref_fn fn, void *cb_data)
-- 
2.4.3.1.gb3b6c0d.dirty
Junio C Hamano· Jun 11, 2015, 04:55 UTC · re: Mike Hommey · lore

Re: [PATCH] Allow to control the namespace for replace refs

Mike Hommey <mh@glandium.org> writes:
Show 15 quoted lines
> It can be useful to have grafts or replace refs for specific use-cases while
> keeping the default "view" of the repository pristine (or with a different
> set of grafts/replace refs).
>
> It is possible to use a different graft file with GIT_GRAFT_FILE, but while
> replace refs are more powerful, they don't have an equivalent override.
>
> Add a GIT_REPLACE_NAMESPACE environment variable to control where git is
> going to look for replace refs.
>
> Signed-off-by: Mike Hommey <mh@glandium.org>
> ---
>
> I'm not sure if I need to care about avoiding strlen in log-tree.c, or if I
> should handle the lack of a / at the end of GIT_REPLACE_NAMESPACE.

First, let me agree with you that being able to say "I usually use refs/replace/ hierarchy as my object replacement database, but for this particular invocation of Git (or 'all Git invocations from this subprocess' for that matter), I want to use refs/replace-2/ hierarchy instead" is a good thing.

I however doubt that it is a good idea to use the word "namespace" anywhere in the name for that mechanism. Let me explain, and please listen with skepticism, as I do not use the ref namespace mechanism myself---it is entirely possible that my understanding of how the ref namespace mechanism is meant to be used is faulty, and if that is the case please correct me.

The ref namespace mechanism is to be used when you want to serve one or more "virtual repositories" via upload-pack/receive-pack server side programs from a single repository. By having two hierarchies, each of which is similar to the usual HEAD, refs/heads/, refs/tags/, etc., under refs/namespaces/a and refs/namespaces/b, you can allow two instances of upload-pack to serve two "virtual repositories".

What is in refs/namespaces/a/{HEAD,refs/heads/*,refs/tags/*,...} is exposed by one instance of upload-pack to its clients as if they are the entire world (i.e. HEAD,refs/heads/*,refs/tags/*,...), the other one does the same to its clients from refs/namespaces/b/*. And they do share the same object store (thereby allowing you to implement a cheap "forks" without having to worry about object borrowing).

The usual server side housekeeping such as "gc" can and must be arranged to happen without limiting them to either namespace, so that anything reachable by any ref from either "virtual repository" will be retained.

Now, does the "For this invocation, please use refs/replace-2/ as the object replacement database" feature have anything common to the ref namespace mechanism? I do not see any commonality, and that is why I do not think it is a good idea to use that word. It will confuse the users and the developers alike.

To me, this mechanism looks very similar to the way you specify a non-default notes tree is to be used with the --notes=<ref> parameter, core.notesRef configuration and GIT_NOTES_REF environment variable. Modeling after that, perhaps using core.replaceRef and GIT_REPLACE_REF would be more appropriate, I think.

Thanks.
Mike Hommey· Jun 11, 2015, 05:13 UTC · re: Junio C Hamano · lore

Re: [PATCH] Allow to control the namespace for replace refs

On Wed, Jun 10, 2015 at 09:55:30PM -0700, Junio C Hamano wrote:
Show 50 quoted lines
> Mike Hommey <mh@glandium.org> writes:
> 
> > It can be useful to have grafts or replace refs for specific
> > use-cases while keeping the default "view" of the repository
> > pristine (or with a different set of grafts/replace refs).
> >
> > It is possible to use a different graft file with GIT_GRAFT_FILE,
> > but while replace refs are more powerful, they don't have an
> > equivalent override.
> >
> > Add a GIT_REPLACE_NAMESPACE environment variable to control where
> > git is going to look for replace refs.
> >
> > Signed-off-by: Mike Hommey <mh@glandium.org> ---
> >
> > I'm not sure if I need to care about avoiding strlen in log-tree.c,
> > or if I should handle the lack of a / at the end of
> > GIT_REPLACE_NAMESPACE.
> 
> First, let me agree with you that being able to say "I usually use
> refs/replace/ hierarchy as my object replacement database, but for
> this particular invocation of Git (or 'all Git invocations from this
> subprocess' for that matter), I want to use refs/replace-2/ hierarchy
> instead" is a good thing.
> 
> I however doubt that it is a good idea to use the word "namespace"
> anywhere in the name for that mechanism.  Let me explain, and please
> listen with skepticism, as I do not use the ref namespace mechanism
> myself---it is entirely possible that my understanding of how the ref
> namespace mechanism is meant to be used is faulty, and if that is the
> case please correct me.
> 
> The ref namespace mechanism is to be used when you want to serve one
> or more "virtual repositories" via upload-pack/receive-pack server
> side programs from a single repository.  By having two hierarchies,
> each of which is similar to the usual HEAD, refs/heads/, refs/tags/,
> etc., under refs/namespaces/a and refs/namespaces/b, you can allow two
> instances of upload-pack to serve two "virtual repositories".
> 
> What is in refs/namespaces/a/{HEAD,refs/heads/*,refs/tags/*,...} is
> exposed by one instance of upload-pack to its clients as if they are
> the entire world (i.e. HEAD,refs/heads/*,refs/tags/*,...), the other
> one does the same to its clients from refs/namespaces/b/*.  And they
> do share the same object store (thereby allowing you to implement a
> cheap "forks" without having to worry about object borrowing).
> 
> The usual server side housekeeping such as "gc" can and must be
> arranged to happen without limiting them to either namespace, so that
> anything reachable by any ref from either "virtual repository" will be
> retained.

I do agree that this is all confusing, but allow me to point out that it's already plenty confusing: "namespace" is a term that has been used to designate a generic kind of namespace *and* refs/namespaces. See for example:

https://github.com/git/git/blob/master/Documentation/git-describe.txt#L39 https://github.com/git/git/blob/master/Documentation/git-fetch.txt#L113 https://github.com/git/git/blob/master/Documentation/git-filter-branch.txt#L36 (note how this one is specifically about refs/replace/) there are many more.

Show 11 quoted lines
> Now, does the "For this invocation, please use refs/replace-2/ as the
> object replacement database" feature have anything common to the ref
> namespace mechanism?  I do not see any commonality, and that is why I
> do not think it is a good idea to use that word.  It will confuse the
> users and the developers alike.
> 
> To me, this mechanism looks very similar to the way you specify a
> non-default notes tree is to be used with the --notes=<ref> parameter,
> core.notesRef configuration and GIT_NOTES_REF environment variable.
> Modeling after that, perhaps using core.replaceRef and GIT_REPLACE_REF
> would be more appropriate, I think.

_REF kind of implies _one_ specific ref. I originally wrote the patch with _BASE but went with _NAMESPACE instead because it made it somehow clearer to me that it was about a ref namespace (not refs/namespaces), not a base directory. I'm not particularly attached to _NAMESPACE, but I don't find _BASE or _REF particularly compelling. I'm open to better suggestions.

As for exposing a pref, I'm not entirely sure it makes sense to. In any case, if we add a pref for it, we should, for consistency, add one for grafts, except maybe if they are planned to be phased out in favor of replace refs.

Cheers,
Mike
Junio C Hamano· Jun 11, 2015, 15:16 UTC · re: Mike Hommey · lore

Re: [PATCH] Allow to control the namespace for replace refs

Mike Hommey <mh@glandium.org> writes:
Show 10 quoted lines
> I do agree that this is all confusing, but allow me to point out that
> it's already plenty confusing: "namespace" is a term that has been used to
> designate a generic kind of namespace *and* refs/namespaces. See for
> example:
>
> https://github.com/git/git/blob/master/Documentation/git-describe.txt#L39
> https://github.com/git/git/blob/master/Documentation/git-fetch.txt#L113
> https://github.com/git/git/blob/master/Documentation/git-filter-branch.txt#L36
> (note how this one is specifically about refs/replace/)
> there are many more.
"One more breakage does not hurt" is not something we want to see.
> _REF kind of implies _one_ specific ref....

I thought about suggesting GIT_REPLACE_REFS for that exact reason, but decided against it, because (1) if you are using replace, then you know you are not using a single ref but a group of refs in a single hierarchy already, and (2) if you do not know what replace and notes are, GIT_REPLACE_REFS and GIT_NOTES_REF look just being inconsistent (even though the intention of the difference is to be more logical). s/S/_BASE/ would make that better, though.

> As for exposing a pref, I'm not entirely sure it makes sense to.

I don't see an immediate need for it, and it is easy to add later, so let's limit the scope of the initial adoption of the feature.

Thanks.
Mike Hommey· Jun 11, 2015, 20:46 UTC · re: Junio C Hamano · lore

Re: [PATCH] Allow to control the namespace for replace refs

On Thu, Jun 11, 2015 at 08:16:02AM -0700, Junio C Hamano wrote:
Show 14 quoted lines
> Mike Hommey <mh@glandium.org> writes:
> 
> > I do agree that this is all confusing, but allow me to point out that
> > it's already plenty confusing: "namespace" is a term that has been used to
> > designate a generic kind of namespace *and* refs/namespaces. See for
> > example:
> >
> > https://github.com/git/git/blob/master/Documentation/git-describe.txt#L39
> > https://github.com/git/git/blob/master/Documentation/git-fetch.txt#L113
> > https://github.com/git/git/blob/master/Documentation/git-filter-branch.txt#L36
> > (note how this one is specifically about refs/replace/)
> > there are many more.
> 
> "One more breakage does not hurt" is not something we want to see.

I won't disagree here, but we are in desperate need for a word for those namespaces that aren't refs/namespaces, and stick to it (independently of the replace patch), but I've never seen one.

Mike
Junio C Hamano· Jun 11, 2015, 20:55 UTC · re: Mike Hommey · lore

Re: [PATCH] Allow to control the namespace for replace refs

Mike Hommey <mh@glandium.org> writes:
Show 19 quoted lines
> On Thu, Jun 11, 2015 at 08:16:02AM -0700, Junio C Hamano wrote:
>> Mike Hommey <mh@glandium.org> writes:
>> 
>> > I do agree that this is all confusing, but allow me to point out that
>> > it's already plenty confusing: "namespace" is a term that has been used to
>> > designate a generic kind of namespace *and* refs/namespaces. See for
>> > example:
>> >
>> > https://github.com/git/git/blob/master/Documentation/git-describe.txt#L39
>> > https://github.com/git/git/blob/master/Documentation/git-fetch.txt#L113
>> > https://github.com/git/git/blob/master/Documentation/git-filter-branch.txt#L36
>> > (note how this one is specifically about refs/replace/)
>> > there are many more.
>> 
>> "One more breakage does not hurt" is not something we want to see.
>
> I won't disagree here, but we are in desperate need for a word for those
> namespaces that aren't refs/namespaces, and stick to it (independently
> of the replace patch), but I've never seen one.
I actually don't agree with you ;-)

All these examples you cited above are merely talking about hierarchy and they do not have any desperate need for a new word.

They do not even need a technical term; they needed a way of saying "subdirectory" without limiting their reference to loose refs. If there weren't packed-refs, they would have said ".git/refs/heads and its subdirectories" and that would have been perfectly fine.

The "ref namespace" I mentioned in my first response is the only special one, I would think, so if we reword everybody else to say hierarchy instead of namespace, we are perfectly fine, I think.

Mike Hommey· Jun 11, 2015, 21:34 UTC · re: Junio C Hamano · lore

[PATCH v2] Allow to control where the replace refs are looked for

It can be useful to have grafts or replace refs for specific use-cases while keeping the default "view" of the repository pristine (or with a different set of grafts/replace refs).

It is possible to use a different graft file with GIT_GRAFT_FILE, but while replace refs are more powerful, they don't have an equivalent override.

Add a GIT_REPLACE_REF_BASE environment variable to control where git is going to look for replace refs.

Signed-off-by: Mike Hommey <mh@glandium.org>
---
 builtin/replace.c | 6 +++---
 cache.h           | 2 ++
 environment.c     | 6 ++++++
 log-tree.c        | 5 +++--
 refs.c            | 3 ++-
 5 files changed, 16 insertions(+), 6 deletions(-)
Show changes to 5 files +16 −6

builtin/replace.c, cache.h, environment.c, log-tree.c, refs.c

diff --git a/builtin/replace.c b/builtin/replace.c
index 54bf01a..b5b7139 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -104,9 +104,9 @@ static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
 			continue;
 		}
 		full_hex = sha1_to_hex(sha1);
-		snprintf(ref, sizeof(ref), "refs/replace/%s", full_hex);
+		snprintf(ref, sizeof(ref), "%s%s", git_replace_ref_base, full_hex);
 		/* read_ref() may reuse the buffer */
-		full_hex = ref + strlen("refs/replace/");
+		full_hex = ref + strlen(git_replace_ref_base);
 		if (read_ref(ref, sha1)) {
 			error("replace ref '%s' not found.", full_hex);
 			had_error = 1;
@@ -134,7 +134,7 @@ static void check_ref_valid(unsigned char object[20],
 			    int force)
 {
 	if (snprintf(ref, ref_size,
-		     "refs/replace/%s",
+		     "%s%s", git_replace_ref_base,
 		     sha1_to_hex(object)) > ref_size - 1)
 		die("replace ref name too long: %.*s...", 50, ref);
 	if (check_refname_format(ref, 0))
diff --git a/cache.h b/cache.h
index badf3da..06296da 100644
--- a/cache.h
+++ b/cache.h
@@ -384,6 +384,7 @@ static inline enum object_type object_type(unsigned int mode)
 #define EXEC_PATH_ENVIRONMENT "GIT_EXEC_PATH"
 #define CEILING_DIRECTORIES_ENVIRONMENT "GIT_CEILING_DIRECTORIES"
 #define NO_REPLACE_OBJECTS_ENVIRONMENT "GIT_NO_REPLACE_OBJECTS"
+#define GIT_REPLACE_REF_BASE_ENVIRONMENT "GIT_REPLACE_REF_BASE"
 #define GITATTRIBUTES_FILE ".gitattributes"
 #define INFOATTRIBUTES_FILE "info/attributes"
 #define ATTRIBUTE_MACRO_PREFIX "[attr]"
@@ -605,6 +606,7 @@ extern unsigned long pack_size_limit_cfg;
  * been sought but there were none.
  */
 extern int check_replace_refs;
+extern char *git_replace_ref_base;
 
 extern int fsync_object_files;
 extern int core_preload_index;
diff --git a/environment.c b/environment.c
index a40044c..435b3ea 100644
--- a/environment.c
+++ b/environment.c
@@ -47,6 +47,7 @@ const char *askpass_program;
 const char *excludes_file;
 enum auto_crlf auto_crlf = AUTO_CRLF_FALSE;
 int check_replace_refs = 1;
+char *git_replace_ref_base;
 enum eol core_eol = EOL_UNSET;
 enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
 unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
@@ -109,6 +110,7 @@ const char * const local_repo_env[] = {
 	GRAFT_ENVIRONMENT,
 	INDEX_ENVIRONMENT,
 	NO_REPLACE_OBJECTS_ENVIRONMENT,
+	GIT_REPLACE_REF_BASE_ENVIRONMENT,
 	GIT_PREFIX_ENVIRONMENT,
 	GIT_SHALLOW_FILE_ENVIRONMENT,
 	NULL
@@ -145,6 +147,7 @@ static void setup_git_env(void)
 {
 	const char *gitfile;
 	const char *shallow_file;
+	const char *replace_ref_base;
 
 	git_dir = getenv(GIT_DIR_ENVIRONMENT);
 	if (!git_dir)
@@ -156,6 +159,9 @@ static void setup_git_env(void)
 	git_graft_file = git_path_from_env(GRAFT_ENVIRONMENT, "info/grafts");
 	if (getenv(NO_REPLACE_OBJECTS_ENVIRONMENT))
 		check_replace_refs = 0;
+	replace_ref_base = getenv(GIT_REPLACE_REF_BASE_ENVIRONMENT);
+	git_replace_ref_base = xstrdup(replace_ref_base ? replace_ref_base
+							  : "refs/replace/");
 	namespace = expand_namespace(getenv(GIT_NAMESPACE_ENVIRONMENT));
 	namespace_len = strlen(namespace);
 	shallow_file = getenv(GIT_SHALLOW_FILE_ENVIRONMENT);
diff --git a/log-tree.c b/log-tree.c
index c931615..ea90a9b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -96,11 +96,12 @@ static int add_ref_decoration(const char *refname, const unsigned char *sha1, in
 
 	assert(cb_data == NULL);
 
-	if (starts_with(refname, "refs/replace/")) {
+	if (starts_with(refname, git_replace_ref_base)) {
 		unsigned char original_sha1[20];
 		if (!check_replace_refs)
 			return 0;
-		if (get_sha1_hex(refname + 13, original_sha1)) {
+		if (get_sha1_hex(refname + strlen(git_replace_ref_base),
+				 original_sha1)) {
 			warning("invalid replace ref %s", refname);
 			return 0;
 		}
diff --git a/refs.c b/refs.c
index 67d6745..70eb87b 100644
--- a/refs.c
+++ b/refs.c
@@ -2089,7 +2089,8 @@ int for_each_remote_ref_submodule(const char *submodule, each_ref_fn fn, void *c
 
 int for_each_replace_ref(each_ref_fn fn, void *cb_data)
 {
-	return do_for_each_ref(&ref_cache, "refs/replace/", fn, 13, 0, cb_data);
+	return do_for_each_ref(&ref_cache, git_replace_ref_base, fn,
+			       strlen(git_replace_ref_base), 0, cb_data);
 }
 
 int head_ref_namespaced(each_ref_fn fn, void *cb_data)
-- 
2.4.3.2.g7b75046.dirty
Junio C Hamano· Jun 12, 2015, 22:29 UTC · re: Mike Hommey · lore

Re: [PATCH v2] Allow to control where the replace refs are looked for

Mike Hommey <mh@glandium.org> writes:
Show 18 quoted lines
> It can be useful to have grafts or replace refs for specific use-cases while
> keeping the default "view" of the repository pristine (or with a different
> set of grafts/replace refs).
>
> It is possible to use a different graft file with GIT_GRAFT_FILE, but while
> replace refs are more powerful, they don't have an equivalent override.
>
> Add a GIT_REPLACE_REF_BASE environment variable to control where git is
> going to look for replace refs.
>
> Signed-off-by: Mike Hommey <mh@glandium.org>
> ---
>  builtin/replace.c | 6 +++---
>  cache.h           | 2 ++
>  environment.c     | 6 ++++++
>  log-tree.c        | 5 +++--
>  refs.c            | 3 ++-
>  5 files changed, 16 insertions(+), 6 deletions(-)
Thanks.

"git am" seems to be seeing a patch based on a stale base. What branch did you base this on?

Junio C Hamano· Jun 12, 2015, 22:36 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] Allow to control where the replace refs are looked for

Junio C Hamano <gitster@pobox.com> writes:
Show 25 quoted lines
> Mike Hommey <mh@glandium.org> writes:
>
>> It can be useful to have grafts or replace refs for specific use-cases while
>> keeping the default "view" of the repository pristine (or with a different
>> set of grafts/replace refs).
>>
>> It is possible to use a different graft file with GIT_GRAFT_FILE, but while
>> replace refs are more powerful, they don't have an equivalent override.
>>
>> Add a GIT_REPLACE_REF_BASE environment variable to control where git is
>> going to look for replace refs.
>>
>> Signed-off-by: Mike Hommey <mh@glandium.org>
>> ---
>>  builtin/replace.c | 6 +++---
>>  cache.h           | 2 ++
>>  environment.c     | 6 ++++++
>>  log-tree.c        | 5 +++--
>>  refs.c            | 3 ++-
>>  5 files changed, 16 insertions(+), 6 deletions(-)
>
> Thanks.
>
> "git am" seems to be seeing a patch based on a stale base.  What
> branch did you base this on?

Ah, no need to resend; the conflict is with recently merged bc/object-id.

Thanks.

← back to recent threads