git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* Feature suggestion: Features Sets and Feature Dependencies Sets
@ 2020-09-23 12:34 The Sharp Ninja
  2020-09-25  1:58 ` brian m. carlson
  0 siblings, 1 reply; 3+ messages in thread
From: The Sharp Ninja @ 2020-09-23 12:34 UTC (permalink / raw)
  To: git

# Proposal for Feature Sets and Feature Dependency Sets

I believe a very useful feature for Git would be the addition of Feature Sets and Feature Dependency Sets.  

## Feature and Feature Set

A Feature is a defined domain of functionality, such as a specific service of an API.  Features can be managed as a subset of the repository, allowing for segmenting a repository into working groups that have their own set of permissions for the pool of users with access to the repository.  As an example, User A may not have permissions to merge within the repository, but within Feature A he is allowed to do so.  This would streamline integrating new users into large repositories and teams.

A collection of related artifacts that together form the basis of a Feature is a Feature Set.  All artifacts within the feature set are managed equally by a merging of permissions for the Feature and the Repository with most permissive permission being chosen.  

## Changes to Workflow

Once a user has cloned a repository, he may chose to scope his work to the Feature Set.  All Fetch/Pull/Push operations are limited to the Feature Set.

Checking out a Feature Set automatically creates a new branch for tracking the changes by the user.

## Feature Dependency Sets

Artifacts that are not part of a Feature, but directly affect the Feature can be added to a Feature Dependencies Set.  When scoping actions to the Feature, artifacts related to the Feature by way of inclusion in a Feature Dependency Set are also included in the activities.  If a commit includes changes to items in the Feature Dependency Set then creating a pull request will generate two PRs, the first a normal PR with normal permissions that includes only the changes in the Features Dependency Set, to be adjudicated via the normal workflow, and the second PR scoped to both the changes in the Feature Set and Feature Dependency Set in the Feature's user-level branch.

## Finalizing a Feature Set 

Ultimately the Feature Set work will become a PR to master/main and be adjudicated via the normal workflow.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Feature suggestion: Features Sets and Feature Dependencies Sets
  2020-09-23 12:34 Feature suggestion: Features Sets and Feature Dependencies Sets The Sharp Ninja
@ 2020-09-25  1:58 ` brian m. carlson
  2020-09-28  9:45   ` The Sharp Ninja
  0 siblings, 1 reply; 3+ messages in thread
From: brian m. carlson @ 2020-09-25  1:58 UTC (permalink / raw)
  To: The Sharp Ninja; +Cc: git

[-- Attachment #1: Type: text/plain, Size: 3962 bytes --]

On 2020-09-23 at 12:34:24, The Sharp Ninja wrote:
> # Proposal for Feature Sets and Feature Dependency Sets
> 
> I believe a very useful feature for Git would be the addition of
> Feature Sets and Feature Dependency Sets.
> 
> ## Feature and Feature Set
> 
> A Feature is a defined domain of functionality, such as a specific
> service of an API.  Features can be managed as a subset of the
> repository, allowing for segmenting a repository into working groups
> that have their own set of permissions for the pool of users with
> access to the repository.  As an example, User A may not have
> permissions to merge within the repository, but within Feature A he is
> allowed to do so.  This would streamline integrating new users into
> large repositories and teams.

Git doesn't natively provide any functionality for restricting access to
a repository more than by read-only or read-write permissions.  This is
intentional.

Restricting merging to a set of files or even a directory causes
problems detecting what files those are in the context of renames and
copies.  Plus, should Git consider the paths as they were in the merge
base, or one of the heads?  If one of the heads, which one?  Currently,
merges are symmetric except for the order of parents in the commit
object, and this would break that property.

This does seems like functionality you could add on using your CI
system, a pre-receive hook, or features of your hosting platform.  For
example, your CI system could run a check that the user is operating
only within their domain, and reject the operation otherwise.

At $DAYJOB, we do this by requiring reviews by certain teams for certain
files.  If I want to merge code with approval only from my team, I must
restrict myself to files my team owns.  If I touch other teams' files, I
must seek their approval.  Without the relevant approvals, I cannot
merge or deploy any code.  All of this is built on top of Git and Git
knows nothing about it.

In addition, your proposal is very specific to your workflow where teams
must touch only their code.  In other organizations, such as mine, teams
may touch any code with approval.  There's no reason to think that one
or the other approach is better or should be more privileged in Git
itself, especially when both approaches can be effectively built on top.

> ## Changes to Workflow
> 
> Once a user has cloned a repository, he may chose to scope his work to
> the Feature Set.  All Fetch/Pull/Push operations are limited to the
> Feature Set.

Because a blob can be shared across paths and is only stored once, it's
not possible to determine efficiently whether a blob is accessible only
under a certain path.  As outlined in gitnamespaces(7), trying to
restrict access to only a subset of a repository can't be done securely,
because attackers can make deltas against other objects.

So this approach would be both inefficient and insecure.

> ## Feature Dependency Sets
> 
> Artifacts that are not part of a Feature, but directly affect the
> Feature can be added to a Feature Dependencies Set.  When scoping
> actions to the Feature, artifacts related to the Feature by way of
> inclusion in a Feature Dependency Set are also included in the
> activities.  If a commit includes changes to items in the Feature
> Dependency Set then creating a pull request will generate two PRs, the
> first a normal PR with normal permissions that includes only the
> changes in the Features Dependency Set, to be adjudicated via the
> normal workflow, and the second PR scoped to both the changes in the
> Feature Set and Feature Dependency Set in the Feature's user-level
> branch.

Git has no concept of pull requests.  Those are a feature typically
built on top of hosting platforms like GitHub, GitLab, or Bitbucket.
Some projects, such as Linux, don't use pull requests at all.
-- 
brian m. carlson: Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: Feature suggestion: Features Sets and Feature Dependencies Sets
  2020-09-25  1:58 ` brian m. carlson
@ 2020-09-28  9:45   ` The Sharp Ninja
  0 siblings, 0 replies; 3+ messages in thread
From: The Sharp Ninja @ 2020-09-28  9:45 UTC (permalink / raw)
  To: brian m. carlson; +Cc: git

@brian m. carlson - Thank you for the clarification of how such a feature could/should be implemented.  I will look deeper at what GitHub and Azure DevOps offer in this area and seek a feature addition if necessary.

-----Original Message-----
From: brian m. carlson <sandals@crustytoothpaste.net> 
Sent: Thursday, September 24, 2020 8:59 PM
To: The Sharp Ninja <ninja@thesharp.ninja>
Cc: git@vger.kernel.org
Subject: Re: Feature suggestion: Features Sets and Feature Dependencies Sets

On 2020-09-23 at 12:34:24, The Sharp Ninja wrote:
> # Proposal for Feature Sets and Feature Dependency Sets
> 
> I believe a very useful feature for Git would be the addition of 
> Feature Sets and Feature Dependency Sets.
> 
> ## Feature and Feature Set
> 
> A Feature is a defined domain of functionality, such as a specific 
> service of an API.  Features can be managed as a subset of the 
> repository, allowing for segmenting a repository into working groups 
> that have their own set of permissions for the pool of users with 
> access to the repository.  As an example, User A may not have 
> permissions to merge within the repository, but within Feature A he is 
> allowed to do so.  This would streamline integrating new users into 
> large repositories and teams.

Git doesn't natively provide any functionality for restricting access to a repository more than by read-only or read-write permissions.  This is intentional.

Restricting merging to a set of files or even a directory causes problems detecting what files those are in the context of renames and copies.  Plus, should Git consider the paths as they were in the merge base, or one of the heads?  If one of the heads, which one?  Currently, merges are symmetric except for the order of parents in the commit object, and this would break that property.

This does seems like functionality you could add on using your CI system, a pre-receive hook, or features of your hosting platform.  For example, your CI system could run a check that the user is operating only within their domain, and reject the operation otherwise.

At $DAYJOB, we do this by requiring reviews by certain teams for certain files.  If I want to merge code with approval only from my team, I must restrict myself to files my team owns.  If I touch other teams' files, I must seek their approval.  Without the relevant approvals, I cannot merge or deploy any code.  All of this is built on top of Git and Git knows nothing about it.

In addition, your proposal is very specific to your workflow where teams must touch only their code.  In other organizations, such as mine, teams may touch any code with approval.  There's no reason to think that one or the other approach is better or should be more privileged in Git itself, especially when both approaches can be effectively built on top.

> ## Changes to Workflow
> 
> Once a user has cloned a repository, he may chose to scope his work to 
> the Feature Set.  All Fetch/Pull/Push operations are limited to the 
> Feature Set.

Because a blob can be shared across paths and is only stored once, it's not possible to determine efficiently whether a blob is accessible only under a certain path.  As outlined in gitnamespaces(7), trying to restrict access to only a subset of a repository can't be done securely, because attackers can make deltas against other objects.

So this approach would be both inefficient and insecure.

> ## Feature Dependency Sets
> 
> Artifacts that are not part of a Feature, but directly affect the 
> Feature can be added to a Feature Dependencies Set.  When scoping 
> actions to the Feature, artifacts related to the Feature by way of 
> inclusion in a Feature Dependency Set are also included in the 
> activities.  If a commit includes changes to items in the Feature 
> Dependency Set then creating a pull request will generate two PRs, the 
> first a normal PR with normal permissions that includes only the 
> changes in the Features Dependency Set, to be adjudicated via the 
> normal workflow, and the second PR scoped to both the changes in the 
> Feature Set and Feature Dependency Set in the Feature's user-level 
> branch.

Git has no concept of pull requests.  Those are a feature typically built on top of hosting platforms like GitHub, GitLab, or Bitbucket.
Some projects, such as Linux, don't use pull requests at all.
--
brian m. carlson: Houston, Texas, US

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-09-28  9:49 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-23 12:34 Feature suggestion: Features Sets and Feature Dependencies Sets The Sharp Ninja
2020-09-25  1:58 ` brian m. carlson
2020-09-28  9:45   ` The Sharp Ninja

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git