archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <>
To: Jeff King <>
Cc: Taylor Blau <>,
	Tommaso Ercole <>,
	"git\" <>
Subject: Re: Creation of a branch named that has a directory prefix equal to the name of another branch fail.
Date: Fri, 24 Jul 2020 13:43:43 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Jeff King's message of "Fri, 24 Jul 2020 16:00:42 -0400")

Jeff King <> writes:

> Note that even though packed-refs does not have this limitation, we
> still enforce it in order to avoid headaches when moving between loose
> and packed refs.
> Likewise, we'll probably[1] continue to enforce it with reftables, at
> least for a while, to make things less confusing when pushing and
> pulling between repositories with different storage.

Yup, that coincides with my understanding.

The files backend could also learn encoding/decoding refnames and
that could be used to transition, if/when we decide to discard the
"refs are organized in a directory-tree like fashion" design we have
been using, to a new world order where a branch M and branches M/A,
M/B, and M/C can co-exist.  Encoding/decoding refname to map to the
filename would also help those on case insensitive filesystems.

Thanks to the recent preparation work for reftable, we are ensuring
that we do not leave direct accesses to $GIT_DIR/refs/* in our
codebase outside the files backend implementation, such a transition
hopefully is getting much easier to do than before.

  reply	other threads:[~2020-07-24 20:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2020-07-24 10:26 ` Creation of a branch named that has a directory prefix equal to the name of another branch fail Tommaso Ercole
2020-07-24 16:00   ` Taylor Blau
2020-07-24 20:00     ` Jeff King
2020-07-24 20:43       ` Junio C Hamano [this message]
2020-07-27  8:21         ` Tommaso Ercole
2020-07-27  9:30           ` Bryan Turner
2020-07-27  8:51       ` Han-Wen Nienhuys
2020-07-24 20:36   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).