Graphite Community

Screenshot_20230128-073150.png

I'm probably more curious than going to be helpful

But do you know where the enable automerge is coming from? (Attached image)

When my team enables automerge on our prs they close when merged.
Or maybe that's what you were asking why automerge happens.

Ah yes, we use auto-merge, which we manually enable when the PR is almost ready to go.

It's unrelated to the question above, though.

Screenshot 2023-01-29 at 8.21.00 am.png

Another example from last night: <https://github.com/shapeshift/web/pull/3707>

Currently, we only rebase B onto A in this case if needed (i.e. if B changes the same files as A) to save time on CI (as a rebase will trigger a new CI run).  This means that in the case where B does not need to be rebased, it will include both commit messages, because GitHub's merge strategy is not smart enough to realize A is already in main.  We are looking at ways to improve this by either taking more control over the merge, or by allowing users to specify that they would always want each PR rebased before merging.

Given this context, do you have any preference on how you'd want this to work?

&gt; Given this context, do you have any preference on how you'd want this to work?
My preference would be for the behavior to be consistent regardless of potential merge conflicts. That's both surprising and difficult to predict. Beyond consistency, I cant think of an instance where I'd want A's commit message in B (it doesn't introduce that behavior!).

I'll probably go back to manually merging one-by-one via GitHub until this is improved, honestly. Having the messages end up like this makes reading the commit logs in our main branch pretty difficult.

Thank you again for the context, and understood that you're balancing this work against a million other things that all need attention. We're loving Graphite at <https://camus.energy/> and are always looking forward to new features and improvements as they appear in our world.

We're aware of an ongoing issue with GitHub actions which could result in slow CI runs.  This could make Merge when Ready or Merge All jobs slower. <https://www.githubstatus.com/incidents/d1l8lxw26y8k>

Hi! This is an ongoing site issue that our team is fixing right now - sorry about that! :saluting_face:

hi <@U04BX08MCBV>! I accidentally introduced this regression this morning when tightening S3 bucket security this morning. I’ve just fixed the bucket policy, you should be good to go

image.png

The first stack id: rYlYcnCWvXi0vDlzxRaR Not sure where to find the new one since it didn’t post to github

Would it be bad if I manually merged these from github or do you want it in this state for investigation?

I believe that there is an ongoing issue with our lambdas that we are currently debugging — cc <@U02DGG36CSH> /<@U047KHH8JH3> who can provide more details

just want to bump this in case it was lost above the fold

FWIW I like the gt behaviour better, as it means that I have a clean working directory

that’s fair. this was a problem for my teammates newer to the tool expecting it to behave the same as git for git commands like commit. they have a workflow that depends on the behavior of `git -a`.  the `-A` flag in git does what you and i have gotten used to, and bc gt has a convention of mimicking git in most commands and as a passthrough directly to git otherwise, this seems to be an issue regardless of my personal preference, especially when there’s an alternative that does what I’ve gotten used to :sweat_smile: 

This is the expected behavior currently, it's similar to the way e.g. mercurial worked at fb and (although the decision was made before my time here) seems to align with our goal of being a simpler mental model for source control by treating all changes to the working tree equally... I think a configuration here is likely the correct long term option (we'd happily accept an OSS contribution to get it in sooner :slightly_smiling_face: ) , or you can add a shell alias to solve it for yourself in the meantime

I think comparing `gt` , self-described as <https://docs.graphite.dev/guides/graphite-cli/mixing-gt-and-git|replacing> `git` , to mercurial is somewhat flawed. If this tool were replacing `hg` then this wouldn't be any issue. I dont argue that treating all changes to the working tree the same is simpler, it definitely is, but I would argue that this is expected behavior. This did cause churn for more than 1 teammate. Thanks for taking a look, just wanted to make sure y'all were aware. :+1:

<https://docs.graphite.dev/guides/graphite-cli/faq#why-are-my-actions-running-twice|https://docs.graphite.dev/guides/graphite-cli/faq#why-are-my-actions-running-twice>

I'm trying out:
```    concurrency:
      group: ${{ github.workflow }}-${{ github.ref }}
      cancel-in-progress: true```
but it seems like this can (by chance) still cancel the check that  is shown in the PR. Any suggestions?

I believe we've seen the same thing occasionally (although not often)— we don't have an answer from GitHub yet on this but i would recommend reaching out to their support team to see if it helps speed up their response process.

Yeah that is a known issue on GitHub’s side - they will sometimes trigger spurious double CI runs and cancel one of them at random, without taking into consideration their mergeability calculation logic. We are working on finding a way around that now and I’ll let you know of any updates!

the culprit may have been that I had some new untracked files, but this is still not the behavior i'd expect

What is the output of git status? We might be missing some files in the "unmerged files" section

I unfortunately can't produce the exact output because my file system is no longer in that state, but there were a few untracked files in the output (some temporary CSV/TXT files output by scripts I was working with)

hmm, <@U04DUH5U0CS>  this may be interesting given your current steam of work.  what’s the pr org/repo/number, <@U03ME5PSD88> ?

<@U02RREE9GKH> basekit/basekit/5263 thanks!

Thanks, Rob &amp; Jacob! I'll take a look

probably unrelated, but I ran across this recently, <https://docs.github.com/en/graphql/overview/resource-limitations>
and that `500` mentioned above tripped a recollection with my reading of
&gt; Individual calls cannot request more than 500,000 total <https://docs.github.com/en/graphql/guides/introduction-to-graphql#node|nodes>.

looks like you're on an old node version — make sure graphite is installed on node 14+

apologies for the confusing error message!

This is interesting - after running `gt branch track &lt;branch 4&gt;` did it reappear?

Sorry this is happening! CCing <@U03Q89DJPL4> for threaded comments visibility.

Hi Nick, I'm sorry about the trouble you are having. For the timeline view, we did some updates to simplify the view, instead of showing full comment threads in that view, we are only showing the comment that was added with a review.

For the issue you mentioned around not being able to open a thread if the file is not rendered, we are looking into support when you click on a comment in the timeline, uncollapsing the file and scrolling to the thread. Would that experience meet your needs?

We are also investigating how we can improve the UX of the experience overall and will hopefully have some more improvements coming soon.

Screen Shot 2023-02-03 at 2.54.59 PM.png

PS: its only happening on my newest PR - I can still view the old ones in the graphite web ui

please let us know if you see anything else strange!

Not sure if this is a bug, but when I make `gt stack submit` calls and graphite puts together updates to existing PRs, sometimes it pulls in more branches than are relevant.
For example if I have a stack off `dev` and someone else also has a stack off `dev` on my team, their entire stack gets referenced in my auto-generated commit messages, even though I’m not tracking their branches with my local `gt` CLI

Is that a configurable behavior?

status on 2nd PR shows as "Queued to merge..."

oh wait, does it wait for checks to pass on trunk before merging next one? because i see the checks actually haven't finished yet

thanks! my bad, looks like it just moved on to the 2nd PR so that was it

<@U02DGG36CSH> is looking into this for you!

I had a similar issue where a stack of 8 PRs failed on like the 2nd one and from then on I had to restack and merge each one one by one (WR5hqW2Vk1uU8WclFxn6)

And then I added 2 more PRs to the end of the stack and tried merging both. It said failed but then still merged both the PRs, without restacking the second one, so as a result the diff for the PR includes both commits (ZUhKy968kVDnerXax1cf)

Seems like this is still an issue. Simpler repro here: <https://graphite-community.slack.com/archives/C02DRNRA9RA/p1676332391466109>

Slightly different cause, same phenotype.  Burning down as many merge issues as possible over the coming week!

<https://app.graphite.dev/macros/token-transit>

Hi <@U02PTRYSHPW>, sorry about that! Looks like we messed up a migration over the weekend (GitHub is changing their primary key for resources) — I’ll dig into the fix here

Screenshot 2023-02-06 at 5.37.17 PM.png

cc <@U03Q89DJPL4> this might be a repro of the overwrite bug I saw last week?

Hi Leslie, I'm sorry you hit this. When comments lose focus, we attempt to save them in the background. My guess is that for some reason that save hit an error and lead to the state that you see. I'll try to dig in a little more and see if I can find more details. We are actively working on making the part of our code more robust to avoid issues like this.

It’s no problem :slightly_smiling_face: Hopefully this gives you guys a lead. If I figure out a way to repro it consistently I’ll update y’all

thanks for bearing with us :pray: I’ll update the status page now

Hi <@U03099DCKRV>, apologies for that — let me look into that for you! What’s your GitHub handle?

It seems to have recovered at this point.  I haven't gotten the timeout the rest of yesterday / today so far.

Ok weird - let us know if it happens again at any point!

I got it every time I refresh a graphite page actually :sweat_smile:
not a huge blocker as it's easy to fix and I don't lose any setup

we do try to clear indexeddb ourselves but not all browsers support the api we use to do so properly… haven’t tested arc specifically, I believe <@U04K5N14V9B> has been using it though…

I haven't used Graphite specifically with Arc too much (I unfortunately have chrome and arc open at all times) but I think there is some shaky compatibility between Graphite/Arc

I'm stopping reviews on Graphite. It became unusable. You never know if your changes were applied or not (I lost a full review with comment already). I have to try to close the window each time to check if my action was "committed" (so I get the "are you sure you want to close this tab" warning) and I have no idea what to do when not the case.
I have to clear cache almost every time I'm trying to use it.
It's really sad I really enjoy the UI
Sorry, will try again in a month or two to check if fixed!

As the team we had (and still have) the same issue with Linear that also heavily relies on IndexDb and a fully async architecture so the site is "snappy".
I prefer blocking and consistent than snappy and unreliable.

Appreciate the tough feedback here - <@U02DGG322G5> just pushed a fix which should significantly reduce memory usage

OK thanks a lot for this! I'll report back if I see improvements

Well, nothing seemed to have changed.
Can't submit a review ("nothing happens" when I submit) without "clear site data/refresh" (and then I lost a comment)

I don't know if changes were made but it seems waaaaay better lately (yesterday + today was OK)
Thank you if you did something, else I'll thank the "random/fixed by magic" gods.

It’s possible Arc did something on their end — otherwise no changes here since Tomas fixed memory usage 

Is this specifically in the review queue, on the PR page or both?

Can you send me an example PR org/repo/number?  Note that if the PR was in a stack, but its base branch was merged, and it hasn't yet had its base change to the trunk branch, then we might be basing this on GitHub's (now inaccurate) calculation

<https://app.graphite.dev/github/pr/archiveresale/archive/3449/remove-unneeded-dependency-sharp-COR-626>

that one is based on `main`, but shows as waiting for reviewers in the list, even though it’s been approved. <@U02RREE9GKH>

I can wait on merging it until tomorrow so you can dig into its current state

Checking in — if I merge this PR, will you still be able to debug this state?

Just looked and I think we got everything we need, so you're good to merge.

This class of issue is interesting as we didn't change anything here recently — github seems to have changed some logic around one of their api response fields. The good news is that we were planning on doing more of these calculations on our end, but I'm not sure quite when that change is going to roll out.

Awesome, I’ll merge then. FWIW, I’ve noticed this happening for about as long as I’ve been using Graphite, so it might be a long-standing issue that I’m hitting for some reason

It’s confusing though — since it’s not a more widely reported issue on this Slack, maybe it’s something about me or the repo.

Called it out since I'm kinda suspecting it lead to the atypical state

yep — <https://docs.graphite.dev/guides/graphite-cli/mixing-gt-and-git#on-using-git-rebase>

if you edited a commit past the beginning of branch 3 we're unable to find the parent again and that's why the branch becomes untracked

Ah, I didn't know about `gt branch edit`.
Will try that in the future :ty:

Screenshot 2023-02-07 at 2.28.18 PM.png

Screenshot 2023-02-07 at 2.32.04 PM.png

seeing this in the console (there’s a JSON dump with more info - lmk if you want it and I can send in private as it has some company data there [not much])

Screenshot 2023-02-07 at 2.31.44 PM.png

sorry if not clear. ^^ appears with this UI message when opening a a PR from the inbox

<@U03RBQVHZE1> can you try hard refresh? cmd shift r

will try. fwiw I’m also using Arc browser, jsut to make it difficult for y’all :slightly_smiling_face:

sorry about that. we need some way to communicate to users when a hard refresh is required.

Hey <@U03KQLVA7MG>, sorry this is happening, looking into it!

it seems a bit better perhaps, but there is still a lag

we're working on optimizing our PR edit section amongst a few other fixes, thanks for pointing this out!

Hi! Your edit experience should be much smoother now - turns out we were writing back to github after every edit in the description box. We've updated that to cache edits and then write back in bulk, so the experience should be a lot less sluggish :)