-
-
Notifications
You must be signed in to change notification settings - Fork 136
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
Let's talk about nearest_branch
selection for rebase
#1166
Comments
That also doesn’t work for me most of the time. I use a setting (forget the name now, on mobile) to fix the target branch. |
Yeah, the setting is |
You could specify it in project setting https://github.com/divmain/GitSavvy/blob/master/docs/README.md#editing-settings |
Implemented and merged into dev. Works fine so far. Way better than before at least. |
The
rebase
dashboard preselects a good base candidate automatically. The implementation is imo flawed. Let's look at it.For the simple case:
A: The feature branch I just pushed here is still on top of
dev
, andnearest_branch
suggestdev
👍Let's look at this.
colorize-paths
is a PR which is already behinddev
.follow-paths-upwards
is an upcoming PR derived from the 'colorize' feat.B: If I check out 'colorize'
nearest_branch
fails 😮 and falls back to the 'upstream'fork/colorize-paths-in-graph-view
, which is a no-op because 'local' and 'remote' are synced. (Without an 'upstream' it would fallback to 'master'!)C: If I checkout
follow-paths-upwards
, it selectscolorize-paths
. 👍What are good candidates for rebasing?
First, 'dev' is always a good candidate here ('dev' would be ' master' in other repos).
For B: You have options:
'dev', the branch you originally started your feat which moved along. E.g. you need to rebase on 'master' because of merge conflicts.
the actual merge-base, t.i. the commit you forked originally. E.g. you re-arrange the PR but don't want to resolve possible merge conflicts, you want to stay in the feat branch.
the upstream if available, t.i. the commit you already pushed. If you rebase from upstream you don't have to force-push afterwards, it's safe.
Since we currently don't offer candidates to the user but just select one good candidate, should we just go cheap and take the first relative found. Are there known cases we do want to handle differently?
The main bug was imo introduced here 2dcc3aa with switching from
--no-merged
to--merged
.--merged
wasn't correct either bc it breaks C. (For C--merged
would select 'dev'.) Imo we don't want neither, just omit this arg. But then the checkgit branch --contains <common>
cannot fail so we could omit altogether. (We know that thesha
is inrelative
bc we have it from its log.)WDYT 🤷♀
The text was updated successfully, but these errors were encountered: