Skip to content

Safely handle pulling squashed PRs #28

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
2 tasks
epage opened this issue Aug 19, 2021 · 0 comments
Open
2 tasks

Safely handle pulling squashed PRs #28

epage opened this issue Aug 19, 2021 · 0 comments
Labels
enhancement Improve the expected

Comments

@epage
Copy link
Collaborator

epage commented Aug 19, 2021

  • I have searched the discussions
  • I have searched the existing issues

Version

0.1.0

Use Case

  1. My PR was squashed-merged
  2. I perform git stack --pull
  3. I want my local branch automatically deleted, instead it skips rebase because of conflicts

Requirements

  • No data loss
  • Squash-merged branch is deleted
  • All dependent branches rebase safely on master

Possible Solutions

Because of that, git rebase-update will attempt to squash your conflicted branch to see if the squashed version applies cleanly to its upstream.

https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-rebase-update.html

#4 is about a way to unsafely handle pulling squashed PRs

@epage epage added the enhancement Improve the expected label Aug 19, 2021
epage added a commit that referenced this issue Oct 8, 2021
Before, when doing a `git-stack --pull`, we'd rebase the merged branch
onto master.  `git` would the automatically detect the commit is merged
and drop it.  We'd then associate the branch name with the same commit
master points to and have to delete it manually.

This tries to detect that case so we can automatically delete the stale
branch on behalf of users.

This does not help if your branch is behind master because those extra
commits will impact how we are detecting this case (tree id).

This is a spiritual revert of 80f5158,
re-implementing 892117b to handle all
of our changes and with a little more experience and context.

This is a part of #28.
epage added a commit that referenced this issue Oct 8, 2021
Before, when doing a `git-stack --pull`, we'd rebase the merged branch
onto master.  `git` would the automatically detect the commit is merged
and drop it.  We'd then associate the branch name with the same commit
master points to and have to delete it manually.

This tries to detect that case so we can automatically delete the stale
branch on behalf of users.

This does not help if your branch is behind master because those extra
commits will impact how we are detecting this case (tree id).

This is a spiritual revert of 80f5158,
re-implementing 892117b to handle all
of our changes and with a little more experience and context.

This is a part of #28.
epage added a commit that referenced this issue Oct 8, 2021
Before, when doing a `git-stack --pull`, we'd rebase the merged branch
onto master.  `git` would the automatically detect the commit is merged
and drop it.  We'd then associate the branch name with the same commit
master points to and have to delete it manually.

This tries to detect that case so we can automatically delete the stale
branch on behalf of users.

This does not help if your branch is behind master because those extra
commits will impact how we are detecting this case (tree id).

This is a spiritual revert of 80f5158,
re-implementing 892117b to handle all
of our changes and with a little more experience and context.

This is a part of #28.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improve the expected
Projects
None yet
Development

No branches or pull requests

1 participant