4 ms·

Git doesn't have the concept of "main is special", but at least tools like Gitlab have protected branches to stop you screwing up too much. Some concept of "pa

Git doesn't have the concept of "main is special", but at least tools like Gitlab have protected branches to stop you screwing up too much. Some concept of "parent" and "child" branches would actually be pretty interesting. You do have to support multiple "parent" branches though for long term support branches.

samus 3y ago
Protecting branches is indeed very important. I make errors all the time when screwing around. It helps enormously being restricted to just messing up one's feature branches. Many other changes can be done via the GUI with PRs and the various kind of controlled merge and rebase strategies they support, like Merge, Rebase + Merge, FF-only Merge, Squash merge, etc.
- cedws 3y ago
  It's also a security feature. If you have a repo with a lot of developers working on it, you need to be sure they absolutely cannot slip in code with nobody noticing, or trigger CI/CD and compromise build secrets or even production.
andrybak 3y ago
> Git doesn't have the concept of "main is special" Technically, there is special handling for both "master" and "main" in Git in fairly obvious, but I'd argue in a not very important way. When you merge two regular branches, the commit message is `Merge branch 'source' into destination`. But not if destination is `master` or `main` – the `into ...` part is omitted for those merge commits. But this is just for backward compatibility. Git is very conservative in changing such user facing behavior as generated merge commit messages. To get Git to treat `master` and `main` truly without special handling, set empty value to config option `merge.suppressDest` [1]: $ git config merge.suppressDest "" `master` is also used as the default name for the default branch in newly created repositories. See option `--initial-branch` of `git init` and config variable `init.defaultBranch` [2] to override. Git for Windows, for example, allows setting the config option in its installer. Source code: For merge commit formatting: https://github.com/git/git/blob/2108fe4a1976f95821e13503fd331f075da398c6/fmt-merge-msg.c#L646-L649 https://github.com/git/git/blob/2108fe4a1976f95821e13503fd33... For default branch naming: https://github.com/git/git/blob/91e2ab1587d8ee18e3d2978f2b7bc250faf5df8f/refs.c#L662-L686 https://github.com/git/git/blob/91e2ab1587d8ee18e3d2978f2b7b... Git for Windows installer suggesting setting `init.defaultBranch`: - https://github.com/git-for-windows/build-extra/blob/586c46eca4c47dc9d596d0465c1f06451f2ea8c8/installer/install.iss#L2026-L2053 https://github.com/git-for-windows/build-extra/blob/586c46ec... - https://github.com/git-for-windows/build-extra/blob/586c46eca4c47dc9d596d0465c1f06451f2ea8c8/installer/install.iss#L3219-L3224 https://github.com/git-for-windows/build-extra/blob/586c46ec... Footnotes: [1] https://git-scm.com/docs/git-merge#Documentation/git-merge.txt-mergesuppressDest https://git-scm.com/docs/git-merge#Documentation/git-merge.t... [2] https://git-scm.com/docs/git-init#Documentation/git-init.txt--bltbranch-namegt https://git-scm.com/docs/git-init#Documentation/git-init.txt...
- chrnola 3y ago
  There’s some special handling for FETCH_HEAD too (i.e. which branch on a remote is considered the default).
  - andrybak 3y ago
    > which branch on a remote is considered the default You probably mean this place in code: [1]. It uses function git_default_branch_name from refs.c [2], which uses config variable `init.defaultBranch` I've mentioned above. But if it and other look-ups fail, it does fall back to a hard-coded "refs/heads/master". [1] https://github.com/git/git/blob/v2.43.0/remote.c#L2380-L2394 https://github.com/git/git/blob/v2.43.0/remote.c#L2380-L2394 [2] https://github.com/git/git/blob/v2.43.0/refs.c#L671-L705 https://github.com/git/git/blob/v2.43.0/refs.c#L671-L705 Edit: removed mention of a deprecated Git feature to avoid confusion.
CuriousCosmic 3y ago
It actually does but it's very much in alpha/active development (under the umbrella of OpenSSF with the intent of being integrated into mainline git eventually). https://github.com/gittuf/gittuf https://github.com/gittuf/gittuf
- ndriscoll 3y ago
  Git itself doesn't run a persistent process and I don't see how it'd make sense to prevent a user from making arbitrary changes to their local repo, so this sounds like just another server like GitHub, Gerrit, Gitlab, etc. that already have those features.
  - CuriousCosmic 3y ago
    This provides a mechanism for any client to identify and reject changes from any given remote that are non-compliant with the policy committed to the repo. So this is something that servers would certainly be able to use but it is also something that operates at the client level. And you could use it in environments where nobody uses the big hosted git platforms (github, gitlab, gitea, etc). So you could still use this in environments where you fetch changes to a project over ssh from a friend or cocontributor's dev machine. Or via basic, barebones read only https or ssh hosting. i.e. this is access control that works independent of centralized servers.

samus 3y ago

Protecting branches is indeed very important. I make errors all the time when screwing around. It helps enormously being restricted to just messing up one's feature branches. Many other changes can be done via the GUI with PRs and the various kind of controlled merge and rebase strategies they support, like Merge, Rebase + Merge, FF-only Merge, Squash merge, etc.

cedws 3y ago
It's also a security feature. If you have a repo with a lot of developers working on it, you need to be sure they absolutely cannot slip in code with nobody noticing, or trigger CI/CD and compromise build secrets or even production.

andrybak 3y ago

> Git doesn't have the concept of "main is special" Technically, there is special handling for both "master" and "main" in Git in fairly obvious, but I'd argue in a not very important way. When you merge two regular branches, the commit message is `Merge branch 'source' into destination`. But not if destination is `master` or `main` – the `into ...` part is omitted for those merge commits. But this is just for backward compatibility. Git is very conservative in changing such user facing behavior as generated merge commit messages. To get Git to treat `master` and `main` truly without special handling, set empty value to config option `merge.suppressDest` [1]: $ git config merge.suppressDest "" `master` is also used as the default name for the default branch in newly created repositories. See option `--initial-branch` of `git init` and config variable `init.defaultBranch` [2] to override. Git for Windows, for example, allows setting the config option in its installer. Source code: For merge commit formatting: https://github.com/git/git/blob/2108fe4a1976f95821e13503fd331f075da398c6/fmt-merge-msg.c#L646-L649 https://github.com/git/git/blob/2108fe4a1976f95821e13503fd33... For default branch naming: https://github.com/git/git/blob/91e2ab1587d8ee18e3d2978f2b7bc250faf5df8f/refs.c#L662-L686 https://github.com/git/git/blob/91e2ab1587d8ee18e3d2978f2b7b... Git for Windows installer suggesting setting `init.defaultBranch`: - https://github.com/git-for-windows/build-extra/blob/586c46eca4c47dc9d596d0465c1f06451f2ea8c8/installer/install.iss#L2026-L2053 https://github.com/git-for-windows/build-extra/blob/586c46ec... - https://github.com/git-for-windows/build-extra/blob/586c46eca4c47dc9d596d0465c1f06451f2ea8c8/installer/install.iss#L3219-L3224 https://github.com/git-for-windows/build-extra/blob/586c46ec... Footnotes: [1] https://git-scm.com/docs/git-merge#Documentation/git-merge.txt-mergesuppressDest https://git-scm.com/docs/git-merge#Documentation/git-merge.t... [2] https://git-scm.com/docs/git-init#Documentation/git-init.txt--bltbranch-namegt https://git-scm.com/docs/git-init#Documentation/git-init.txt...

chrnola 3y ago
There’s some special handling for FETCH_HEAD too (i.e. which branch on a remote is considered the default).
- andrybak 3y ago
  > which branch on a remote is considered the default You probably mean this place in code: [1]. It uses function git_default_branch_name from refs.c [2], which uses config variable `init.defaultBranch` I've mentioned above. But if it and other look-ups fail, it does fall back to a hard-coded "refs/heads/master". [1] https://github.com/git/git/blob/v2.43.0/remote.c#L2380-L2394 https://github.com/git/git/blob/v2.43.0/remote.c#L2380-L2394 [2] https://github.com/git/git/blob/v2.43.0/refs.c#L671-L705 https://github.com/git/git/blob/v2.43.0/refs.c#L671-L705 Edit: removed mention of a deprecated Git feature to avoid confusion.

CuriousCosmic 3y ago

It actually does but it's very much in alpha/active development (under the umbrella of OpenSSF with the intent of being integrated into mainline git eventually). https://github.com/gittuf/gittuf https://github.com/gittuf/gittuf

ndriscoll 3y ago
Git itself doesn't run a persistent process and I don't see how it'd make sense to prevent a user from making arbitrary changes to their local repo, so this sounds like just another server like GitHub, Gerrit, Gitlab, etc. that already have those features.
- CuriousCosmic 3y ago
  This provides a mechanism for any client to identify and reject changes from any given remote that are non-compliant with the policy committed to the repo. So this is something that servers would certainly be able to use but it is also something that operates at the client level. And you could use it in environments where nobody uses the big hosted git platforms (github, gitlab, gitea, etc). So you could still use this in environments where you fetch changes to a project over ssh from a friend or cocontributor's dev machine. Or via basic, barebones read only https or ssh hosting. i.e. this is access control that works independent of centralized servers.