https://linen.dev logo
Join Slack
Powered by
This message was deleted.
# report-bugs
s
This message was deleted.
j
Any rebase will result in this branch protection rule triggering - we recommend disabling it
And GitHub only displays the "force-pushed" messaging when a force-push was necessary, otherwise it shows up as "commits added"
Any push where the old commit is not reachable from the new commit requires a force push — hence all rebases require force pushes.
t
I see, thank you. So if my company is required to keep this setting enabled, is there a way to work around this manually?
j
I'm not sure what the latest on this is, but last I heard, there were no plans to support this 😕
👍 1
b
It would be neat if Graphite provided an alternative here. Maybe a Github action that checked for stale approvals by diffing between revisions in a stack-aware way.
❤️ 1
j
We are starting to use 
git range-diff
on the CLI to handle cases like this for 
repo sync
and 
downstack get
, I think it would be pretty easy to write your own GH action to do this using this command!
👍 1
t
Even after temporarily disabling the setting, GitHub still auto-dismissed the approvals when the first diff in the stack was merged. How do I work around this?
j
hmm, might be a recurrence of this github bug?
😱 1
t
Does this affect everyone who uses the squash merge strategy with stacks in Graphite? Can I resolve it by using 
amend
instead of 
commit
for updates, thereby limiting every PR to a single commit?
j
we use squash merge, and we haven’t been running into this issue.
the amend vs. commit choice shouldn’t matter here
i’m not sure what the delta is — there might be something more subtle going on here.,,
t
My team is getting mad at me for using Graphite because they keep having to reapprove
These are my branch protection settings
j
ah - this is the new “most recent reviewable push” rule
t
Ooh, that makes sense, thanks!
j
we definitely don’t support it, and it’s new so i didn’t even know about it until i just asked my teammate
t
Ah wait - I didn’t think that rule would dismiss an approval
AFAIK, it just doesn’t allow the merge if the person who approved is also the author of the most recent commit
I’ve had situations where the PR is approved but GH doesn’t auto-merge
It doesn’t dismiss the review in that case
Are you saying Graphite is dismissing in that case?
j
interesting, might be related to stacking though
no, we never dismiss on push like this, definitely coming from github or some other integration
👍 1
t
I’ll try turning it off anyway and see if it helps things
j
cool, let me know
another feature that GH recently added is "rulesets" — is there anything there that seems relevant?
t
No, we didn’t know about those so we haven’t added any rulesets yet, although now I want to play around with them!
j
(we don't currently support them, just making sure)
👍 1
Open in Slack
PreviousNext
Powered by