Best practice rename master branch to main and default branch name

[L B]

Dear all,

I’m curios if there is a best practice to rename the master branch in gitolite repos to main. Is there also a way to configure gitolite to use a different name for the master branch by default for newly created repos? Thanks!

Best,

L B

[Dirk Heinrichs]

L B:

> I’m curios if there is a best practice to rename the master branch in
> gitolite repos to main.

Just do it. Branches in Git are just pointers, so all you need to do (in
a local clone) is to replace the "master" pointer with a different one:

1. git checkout master
2. git checkout -b main
3. git push -u origin main
4. git push origin :master
5. git branch -D master

[Should also be possible to combine 2 and 5 to "git branch -m master main"]

Then change push (aka write) permissions for master of that repo in your
gitolite.conf and push the gitolite admin repo. Finally, tell your users
about the change.

Did I miss something?

Bye...

    Dirk

--
Dirk Heinrichs <dirk.he...@altum.de>
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de

[Nick]

May 29, 2021 10:03 AM, "Dirk Heinrichs" <dirk.he...@altum.de> wrote:

> L B:
>
>> I’m curios if there is a best practice to rename the master branch in
>> gitolite repos to main.
>
> Just do it.

> [...]
> Did I miss something?
>

You can do this to make it global:

1. ssh root@yourserver
2. sudo -u gitolite /bin/sh
3. git config --global init.defaultBranch main

Then whenever you add a repo to gitolite-admin it will be created with 'main'.

However, if you're also using *wildrepos* you will probably run into the same glitch I did: users can use init.DefaultBranch locally too, and there's no reason they will all choose 'main'. When a new repo is pushed, the wildrepo code runs `git init --bare`, which sets the branch based on the gitolite@yourserver's init.defaultBranch.

Sitram helped me out with this, spending time figuring out a workaround: https://groups.google.com/g/gitolite/c/NwZ1-hq9-9E

-Nick

[Tony Finch]

Dirk Heinrichs <dirk.he...@altum.de> wrote:
>
> Did I miss something?

When I looked into this several months ago, the difficult part was to
update the symbolic ref for HEAD on the server: there was no way to do
that over the git protocol, so it required special access on the server.
This is why the various git hosting services have special webby UI for
renaming the default branch, but no howto for doing it via the command
line.

I have had a look at the last year or two of git release announcements and
I didn't see anything about fixing this limitation.

Tony.
--
f.anthony.n.finch <d...@dotat.at> https://dotat.at/
reject all prejudice and discrimination based upon race, colour,
religion, age, disability, gender, or sexual orientation

[Nick]

May 29, 2021 11:14 AM, "Tony Finch" <d...@dotat.at> wrote:

> Dirk Heinrichs <dirk.he...@altum.de> wrote:
>
>> Did I miss something?
>
> When I looked into this several months ago, the difficult part was to
> update the symbolic ref for HEAD on the server: there was no way to do
> that over the git protocol, so it required special access on the server.
> This is why the various git hosting services have special webby UI for
> renaming the default branch, but no howto for doing it via the command
> line.

gitolite provides this access! https://groups.google.com/g/gitolite/c/NwZ1-hq9-9E:

```
ssh gitolite@yourserver symbolic-ref my/repo HEAD refs/heads/trunk
```

[Sitaram Chamarty]

On Sat, May 29, 2021 at 04:14:24PM +0100, Tony Finch wrote:
> Dirk Heinrichs <dirk.he...@altum.de> wrote:
> >
> > Did I miss something?
>
> When I looked into this several months ago, the difficult part was to
> update the symbolic ref for HEAD on the server: there was no way to do

Assuming this is about doing on the server repo what "git
symbolic-ref" does on a local repo...

> that over the git protocol, so it required special access on the server.
> This is why the various git hosting services have special webby UI for
> renaming the default branch, but no howto for doing it via the command
> line.
>
> I have had a look at the last year or two of git release announcements and
> I didn't see anything about fixing this limitation.

...then that would be because it has existed since 2012 :)

In fact it existed in gitolite v2 also!

You just have to enable it in the RC file, then you can:

$ ssh git@server symbolic-ref -h
Usage: ssh git@host symbolic-ref <repo> <arguments to git-symbolic-ref>

allow 'git symbolic-ref' over a gitolite connection

if you meant something else maybe I need to take a look.

[Tony Finch]

Sitaram Chamarty <sita...@gmail.com> wrote:
> On Sat, May 29, 2021 at 04:14:24PM +0100, Tony Finch wrote:
> >
> > I have had a look at the last year or two of git release announcements and
> > I didn't see anything about fixing this limitation.
>
> ...then that would be because it has existed since 2012 :)

Really nice planning ahead there :-)

> if you meant something else maybe I need to take a look.

I was talking more about pure-git ways to change symbolic refs on the
server (and HEAD is basically the only symbolic ref on a normal server) as
Dirk Heinrichs was suggesting.

(My personal repos are in a trad shell account, not behind gitolite, and I
was disappointed to find that I had to log in and run git symbolic-ref,
which explained why gitolite and everything else have their own ways to
do this.)

Tony.
--
f.anthony.n.finch <d...@dotat.at> https://dotat.at/

a fair, free and open society

[Sitaram Chamarty]

On 5/31/21 2:24 AM, Tony Finch wrote:
> Sitaram Chamarty <sita...@gmail.com> wrote:
>> On Sat, May 29, 2021 at 04:14:24PM +0100, Tony Finch wrote:
>>>
>>> I have had a look at the last year or two of git release announcements and
>>> I didn't see anything about fixing this limitation.
>>
>> ...then that would be because it has existed since 2012 :)
>
> Really nice planning ahead there :-)
>
>> if you meant something else maybe I need to take a look.
>
> I was talking more about pure-git ways to change symbolic refs on the

oops; I *now* notice you said *git* release announcements.

In my mind I had read it as *gitolite* release announcements !

[Mathieu Arnold]

FreeBSD switched to Git a few months back, and we use Gitolite,
obviously, and, we are in need of having more than one symbolic
reference on one repository.

I had a look at the symbolic-ref sub-command, but it seems its
access-control is quite naive, from what I understand, anyone with write
access can use the command to create a symbolic-ref.

I was wondering how one would go to restrict usage to this command.
(Without having to write our own command, of course.)

--
Mathieu Arnold

[L B]

Thank you all! The steps of dirk worked for renaming an existing master branch. However I had to connect to the git server manually and edit the "HEAD"
file in the specific repo and exchange master with main. After this I was able to delete the master branch and main was the new main branch for every clone. So this will be our go to solution for older repos.

[L B]

Thank you Nick, but this however didn't work. I executed that command as the user who managed the repos, but still a freshly set up repo only let me push to the master branch. Any ideas? Or do I have to execute this as sudo?

[L B]

Sorry for spamming a little. I saw that it is not recommended to edit the HEAD file directly to make the new branch default. However I wasn't able to delete the old master branch if I didn't do this. I don't want to allow this: ssh git@host symbolic-ref <repo> <arguments to git-symbolic-ref>  over gitolite. But can I just execute "git-symbolic-ref" while connected to the server via SSH? How would be the syntax for the command if I'm connect either with root or the the git user managing the repos on the git server directly?

[Sitaram Chamarty]

Hi

On Mon, May 31, 2021 at 09:04:06AM +0200, Mathieu Arnold wrote:

> FreeBSD switched to Git a few months back, and we use Gitolite,
> obviously, and, we are in need of having more than one symbolic
> reference on one repository.
>
> I had a look at the symbolic-ref sub-command, but it seems its
> access-control is quite naive, from what I understand, anyone with write
> access can use the command to create a symbolic-ref.
>
> I was wondering how one would go to restrict usage to this command.
> (Without having to write our own command, of course.)

First, gitolite "core" consists of a relatively small set of
programs and modules; everything else, including most "commands"
are considered outside of "core".

I also want to mention something that sometimes comes up:
gitolite is more of a tool-enabler that just happens to ship
with a lot of default tools, than a definitive set of tools. As
such, it may not *ship* with the precise behaviour someone may
want, but it's easy enough to add it on their own site.

So, site admins do add their own commands, triggers, hooks, etc.
In rare cases, they may even override built-in commands. Both
of these can be done using the same mechanism, described in
https://gitolite.com/gitolite/cookbook.html#adding-your-own-commands

In the current command, as you noted, it only checks if you have
"W" permission on the repo. There are several other types of
checks we could do:

- check if they have "+" (force-push, rewind, etc) rights
instead of just "W"; maybe you have a smaller group of
people who have that

- check if they have "W" rights on a special ref, let's say
"SYMBOLIC-REF". You'll never actually push anything with
that name, but you'll have a rule like:

RW SYMBOLIC-REF = alice bob

in each repo (with different people perhaps), and the
"gitolite access" check in the symbolic-ref command would
replace "any" with "SYMBOLIC-REF".

- check if the user has "W" to "gitolite-admin" instead of
"$repo", to restrict it to admins

- add people to a special group (say "@headmasters") and check
if the user is a member of that group. You'd replace the
"gitolie access" check with:

gitolite list-memberships -u $GL_USER | grep -x @headmasters

I'm sure you'll find a better name than "headmasters" :)

So there's any number of ways this could be done. I admit I did
not think of all these when I originally wrote that (in 2011, it
turns out, since this existed in v2 also), but changing it now
would be a problem in terms of backward compatibility.

Sorry about that!

sitaram

[Mathieu Arnold]

Thank you for the detailled answer, having a custom command is perfectly
fine. I admit I had forgotten adding one was as easy as stuffing new
commands in the LOCAL_CODE/commands directory.

--
Mathieu Arnold

[Sitaram Chamarty]

On Thu, Jun 03, 2021 at 06:19:09PM +0200, Mathieu Arnold wrote:
> On Tue, Jun 01, 2021 at 07:38:23PM +0530, Sitaram Chamarty wrote:

> Thank you for the detailled answer [...]

well, it's not everyday you learn that that biggest of the BSDs
is also using your code for access control :)