git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Minor Bug in Renaming Branches

From
Stefan Beller <sbeller@google.com>
Date
Jun 7, 2016, 13:09 UTC
Message-ID
<CAGZ79kaDAPAkkEWVS6pEuAxoWht5Z5GmKjs1ii9_bsTViyhnVQ@mail.gmail.com>
In-Reply-To
<20160607074051.GT22583@mail.eric.deplagne.name>
On Tue, Jun 7, 2016 at 12:40 AM, Eric Deplagne <Eric@deplagne.name> wrote:
Show 30 quoted lines
> On Tue, 07 Jun 2016 06:13:14 +0200, Torsten Bögershausen wrote:
>> On 06/06/2016 09:35 PM, Stefan Beller wrote:
>>> On Mon, Jun 6, 2016 at 12:17 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>>>
>>>> A limitation is introduced by Mac OS and Windows:
>>>> BRANCH/NAME and branch/name refer to the same object in the file
>>>> system.
>>>> As a workaround, you can pack the branch names:
>>>> git pack-refs --all
>>>
>>> Once you packed a branch into the packed refs file, you can
>>> create another loose branch of different capitalization,
>>> which then 'hides' the packed ref?
>>>
>>> That sounds error prone to me, as a seemingly unrelated branch
>>> changed its value:
>>>
>>>      git branch BRANCH 012345
>>>      git pack-refs --all
>>>      git branch branch BRANCH^
>>>      git rev-parse BRANCH
>>>      (I'd expect BRANCH^ as return)
>>>
>>> (I don't have a windows machine for testing here, so that
>>> is pure speculation)
>>>
>> Yes, another reason not to use branch and BRANCH in the same repo.
>> (You can test under Linux & vfat)
>
>   Or to have git just refuse it altogether...

Maybe we could refuse creation of case different branch names on case insensitive file systems, but you could have created them on a case sensitive file system, so you still have to work with that.

This topic was discussed at the Git Merge this year (again), and IIRC the outcome was to not restrict outselves to the lowest common denominator, but rather ¯\_(ツ)_/¯. People who use case insensitive file systems are aware of their limitations and would not ever want to do such branch tricks, right? ;)

>
>   But let me guess, it's against some sort of policy...

I rather think nobody stepped up to present a solution that doesn't suck. As by the title of this thread, it's rather minor.

>
>   There could be some hook out there, then ?
The hook to tell the user if that branch name is allowed?

My gut reaction to that is, that such a hook would violate the principles of the DVCS thinking. A user ought to do anything they want locally including having naming rights for their local branches, so we'd not want to restrict them?

Show 12 quoted lines
>
> --
>   Eric Deplagne
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD4DBQFXVnqDej7DisjVpq4RAqxoAJ0eufoN3OXWKGiHrAPolS4SmOHGIwCWJHNl
> jI/aVh12/NM8YZX5oEl4Ww==
> =rwxP
> -----END PGP SIGNATURE-----
>
Previous: Eric Deplagne
Message 7 of 7 in “Minor Bug in Renaming Branches”
  1. Samuel LijinJun 6, 2016
  2. Stefan BellerJun 6, 2016
  3. Torsten BögershausenJun 6, 2016
  4. Stefan BellerJun 6, 2016
  5. Torsten BögershausenJun 7, 2016
  6. Eric DeplagneJun 7, 2016
  7. Stefan BellerJun 7, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.