Ignore other people's branches pulled for code review

gitext-rs / git-stack

Stacked branch management for Git

Apache License 2.0

508 stars 19 forks source link

Ignore other people's branches pulled for code review #112

Closed epage closed 2 years ago

epage commented 2 years ago

[X] I have searched the discussions
[X] I have searched the existing issues

Version

No response

Use Case

@Bouke when dealing with overwhelming output from git-stack

When reviewing other's PRs I typically create a local tracking branch. These typically shouldn't be altered by git-stack, as they are externally owned. I don't fancy having to mark each branch as protected, as that's something that will be overlooked. So maybe we should try and determine un-owned branches by committer name, ignoring those that don't have the last commit from us.

Split from #107

Requirements

Gracefully handle multiple identities for the same person (different computers, direct or through Github web UI)
Gracefully handle taking over a branch from another developer
Gracefully handle a maintainer modifying a contributors branch

Possible Solutions

No response

epage commented 2 years ago

I have considered the idea of auto-detecting protected branches. The case I was thinking of was if someone had not marked a branch as protected, we should avoid showing the 500 commits on it. This would help with #90.

The challenge is getting the heuristic right

I know I've had an inconsistent git signature, depending on what computer I'm on (work vs personal email)
Someone might be taking over a branch from someone else
A maintainer might be modifying someone else's PR
- Probably shouldn't rebase it on their behalf anyways
- Any additions the maintainer makes would probably make it so it'd go unprotected anyways

arxanas commented 2 years ago

This might not be useful for your use-case, but git-branchless considers a commit to have been authored by you if it was observed by a post-commit or post-rewrite hook. This means:

Commits which you created in this repository on disk always appear.
Development branches that you got from somewhere else only appear consistently once you make or rewrite one of their commits.
- Of course, you might have gotten a development branch which you authored somewhere else. The idea is that if you've checked it out, but haven't made any changes to it, then it's fine to hide it again later, because it should be easy to check out again later.

See also the criteria for surfacing a commit in the smartlog: https://github.com/arxanas/git-branchless/wiki/Command:-git-smartlog#which-commits-are-visible

epage commented 2 years ago

We're intentionally not relying on hooks but this makes me realize I should call out that any detection we do should be based on the Committer rather than the Author (or both?) so changes in history cause us to re-evaluate.

auscompgeek commented 2 years ago

You'd probably want to consider both the Author and Committer - consider that the GitHub web UI has its own committer identity.