Re: Re* [PATCH 8/9] fast-export: respect the possibly-overridden default branch name

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> But because the old solution would not work in the new world order
> this topic created, a new solution needs to be found when you move
> the world to the new order.
>
> An easy solution would be to reserve "ref0" for the primary branch
> in the repository and anonymize other refs "ref1", "ref2", ...
>
> That can be done as a preparatory step regardless of the "'master'
> may not be in the name of the primary branch in this repository"
> topic.
> ...
> diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> index 85868162ee..a306a60d25 100644
> --- a/builtin/fast-export.c
> +++ b/builtin/fast-export.c
> @@ -497,7 +497,7 @@ static void *anonymize_ref_component(const void *old, size_t *len)
>  {
>  	static int counter;
>  	struct strbuf out = STRBUF_INIT;
> -	strbuf_addf(&out, "ref%d", counter++);
> +	strbuf_addf(&out, "ref%d", ++counter);
>  	return strbuf_detach(&out, len);
>  }
>  
> @@ -522,7 +522,7 @@ static const char *anonymize_refname(const char *refname)
>  	 * anything interesting.
>  	 */
>  	if (!strcmp(refname, "refs/heads/master"))
> -		return refname;
> +		return "ref0";

This is obviously wrong.  It should return "refs/heads/ref0".

But another thing we could do, which is probably more backward
compatible, is to return "refs/heads/master" from here.  That way,
consumers of "fast-export" stream that expect 'master' to be the
primary branch would not get upset when the data source runs a newer
version of Git that allows the primary branch name to be customized.

Which means that, before such a change to allow the primary branch
name to be customized happens, there is no need for such a
preparatory patch, because the status quo is just fine.  So, I'm OK
with retracting the above.  "ref0" is not special, so there is no
need to have the first hunk above, either.

However, when the customization being discussed is implemented via
the "get_default_branch_name()" and "get_primary_branch_name()"
functions, we should update these lines like so:

-	if (!strcmp(refname, "refs/heads/master"))
-		return "refs/heads/master";
+	if (!strcmp(refname, get_primary_branch_name(DO_NOT_ABBREV)))
+		return get_default_branch_name(DO_NOT_ABBREV);

That is, the name of the "primary" branch used at the data source is
replaced by the more generic "this is the default" branch name used
in a random "git init" repository.

Imagine that there is a project that has an integration branch per
each device type, named after the confidential device name, owned by
a company.  An employee of the company works on one device type in
his own clone of the repository, and the primary branch in the
repository is set to that confidential device's name.

The employee can create an anonymized output, replacing the
confidential name with a generic "default" name that is not
confidential, like 'main' in the new world order or 'master' in the
backward compatible world order, with such an updated code.

After having thought about it a bit longer, I actually do prefer to
use the "ref0" approach, as it is possible for the employee in the
above example to have the "default" branch name tied to the primary
branch for the hardware type the emploee works on in the ~/.gitconfig
so the "alternative" I suggested in this message will reveal the
confidential name.

So, I guess we should just fix the patch I am responding to to
return "refs/heads/ref0" instead of "ref0", and queue it as one of
the preparatory steps.