Graphite Community

image.png

Hmm that's so weird, sorry you're running into that! <@U02DGG322G5> do we need to update anything with respect to PAT permissions in the docs?

Hey Eric, are you still running into this? We'll look into it! And also want to create more detailed documentation about PAT and Auth process as well

We just deployed a fix for this issue, let me know if it's working for you now!

cc <@U02E95J4648> and <@U03Q89DJPL4>! We are actually in the process of developing our own merge queue…stay tuned :slightly_smiling_face:

ok, cool! does that mean that graphite will not be compatible with github's merge queue?

is “my_branch” someone else’s branch on the remote that was created via `gt branch create` or is it a local branch you created and have not pushed yet?

`my_branch`  is the tip of a three branch stack created on my laptop and pushed to GH.

The first two branches of the stack have been merged.

hope that helps!

you're doing `downstack get` from another workspace i'm presuming?

So I would try a `gt repo sync -fr`  first so that your local stack is up to date with main

yep, what <@U02NG168KD1> said - could be since the merged branches aren't being detected here

maybe be careful with the `-f` and `-r` options if you’re not used to them

they’ll `-f` force delete closed branches and `-r` restack without prompting

i am not used to them, but i dont have many stacks right now

```$ gt repo sync -fr

🌲 Pulling master from remote...
master is up to date.
🧹 Checking if any branches have been merged/closed and can be deleted...
master does not need to be restacked.```
```$ gt downstack get my_branch
Pulling master from remote...
master is up to date.

ERROR: Received invalid dependency response```

seems to be crashing on

```    if (topReturnedBranch !== args.branchName ||
        bottomReturnedBranch !== args.trunkName) {
        throw new errors_1.ExitFailedError(`Received invalid dependency response ${response.downstackBranchNames}`);
    }```

if i log right before it errors:

```console.log({ 'bottomReturnedBranch': bottomReturnedBranch, 'topReturnedBranch': topReturnedBranch, 'args.trunkName': args.trunkName });

{
  bottomReturnedBranch: undefined,
  topReturnedBranch: undefined,
  'args.trunkName': 'master'
}```

```<https://api.graphite.dev/v1> {
  method: 'GET',
  url: '/graphite/downstack-dependencies',
  queryParams: {
    authToken: "OMITTED",
    org: "Lumen5",
    repo: "lumen5-170819-flux",
    trunkName: "master",
    branchName: "OMITTED"
  },
}```
yields the following response
```{
  "downstackBranchNames": [],
  "_response": {
    "size": 0,
    "timeout": 0
  }
}```

OMG! I figured it out!

A while ago, we renamed the repo `lumen5-170819-flux` to `lumen5-flux` on Github.

The original name still works as an alias for (mostly) everything, but apparently not for `/graphite/downstack-dependencies`

:sweat_smile:

oh very interesting, that makes sense :)) happy you were able to get this solved!

but yeah, submitting stacks, etc - all seems to work in this case, except for this feature.

So i guess still a bug report?

yeah thanks for the report!
(silent cc <@U02RREE9GKH> for future CLI changes)

Just read through this thread out of curiosity after I submitted my own bug report. Seems like there’s some cleanup/updates that need to happen in the case of a repo rename.

Screen Shot 2023-03-09 at 4.22.41 PM.png

we have some inconsistent behavior around renaming repositories and continuing to update them - we've created a ticket to work on it!

I’ve run into the same issue — is there something I can follow for updates?

I don’t mind doing some hacky stuff if it means that stacks will actually show up properly — colleagues can’t review properly (on GitHub) because the Graphite stack comment only ever has the current branch

Ah man sorry you're running into this too - let me poke the team for a fix! I'll message this thread with updates :slightly_smiling_face:

Hey, we're planning a longer term fix for this issue, but for now I can fix the data manually in our DB to unblock you folks. Can both of you DM me the old and new repo names in `org/repo` form? Thanks!

Screenshot 2023-03-10 at 11.21.49.png

Screenshot 2023-03-10 at 11.22.33.png

we've seen this flagged a few times - we're working on it! sorry about this :') will let you know when it's fixed

ooh, thanks <@U04K5N14V9B>. I should have scrolled up. Keen to get this resolved as it means I can’t do any graphite stacked PRs currently :smiling_face_with_tear:

Hey Daniel — we just deployed a fix for this! Let me know if it is working for you now.

The two ones above looked just fine until I added the third.

agh this is so weird, thanks for reporting! we'll look into it

Thanks! The PRs are still open but may be merged tomorrow - let me know if there is some state you want me to capture before that…

Doing `gt stack submit` fixed up the comments.

They did fail again during various stages of development - so there’s something fishy for sure. 

Thanks for flagging - we'll look into this!

Hey! Sorry this is happening.  Do you have an example PR # that this happened with recently?

I don't have a public one to share, unfortunately.

It'll still help to debug — you can DM me the owner/repo/number of one where it happened to you and I can look through our logs to see where we may have dropped the data

Isn’t this from a Github setting? You can set what the default commit message of squash &amp; merge ends up being. We change it to default to PR title/description on our repos.

That's right, but we also allow you to set a commit message from the merge UI, and it seems like we currently have a bug where that isn't being used

That's odd - is there a chance that the changes you've pulled down have been merged/closed? Did you do a `gt rs` after doing the `downstack get`?

Yeah we did `gt rs` . it is weird that `gt l` doesn't show PR info after `downstack get`

no that's not expected - when you downstack get the branch it should show you that PR and all its PRs downstack when you do `gt l`

when you do `downstack get`, does the output say `synced &lt;branch&gt; from remote`?

Waiting for coworker to try again. Will report back

I was thinking potential plan is untrack the stack using `gt branch untrack &lt;bottom branch&gt;` and then retry `gt downstack get &lt;top branch&gt;`. Does that seem reasonable?

that sounds reasonable! let me know how it goes

i'm sure you've seen <https://graphite.dev/docs/collaborating-on-a-stack|this>, but just in case you haven't :slightly_smiling_face:

&gt; does the output say `synced &lt;branch&gt; from remote`?
Yes

Is there a way to start over completely? After branch untrack and downstack get, still wasn't getting PR info. Then we tried `gt dev cache --clear` and then again branch untrack, downstack get, still no PR info, but this time it wasn't getting the entire stack either

Will try again after `gt repo init --reset`

Ah sorry about that! Roping in <@U02RREE9GKH> for visibility

After `gt repo init --reset` and `gt dev cache --clear` , then `gt downstack get &lt;top branch&gt;` , `gt l` now showing PR info. Yay!

Huh weird. Glad a reset was able to fix it!

We added a branch using `gt branch track` selected a parent (top branch). Confirmed `gt l` still showing PR info for parent branches.. but the new branch we just tracked doesn't show PR info. Maybe expected? There is a PR already for the new branch though. Do you recommend `gt ss` or `gt downstack get &lt;the-new-branch&gt;` next?

Tried again and got the same thing. After `gt branch track` then `gt l` doesn't show PR info initially. Then did `gt ls` and then `gt l` again, and 2nd time showed PR info

the GH sync happens in the background to keep commands snappy— perhaps we should fetch data synchronously for track though...

`track` just starts tracking the branch locally :slightly_smiling_face:

stacklinks.png

Screen Recording 2023-03-16 at 3.36.58 PM.mov

hey! were these comments on collapsed files? if so i’m actively looking into fixing this issue!

ahhh that does seem to be the case -- on an uncollapsed file it works fine!

ah fwiw also files that are collapsed because they are "too large to render" (odd that that message appears even when the changed lines are very few, though the file is large, but the default is just to show the changed lines)

Thanks for this feedback! cc <@U02DCQ1C0G6> /<@U04AP0M9AES>

Noted, I’ll take a task to improve this

We're going to work on some improvements to collaboration in the CLI! cc <@U02RREE9GKH> for viz

what are the issues you're running into? are the conflicts you're seeing not expected?

Hi <@U02RREE9GKH> thanks for your help. Sorry for delay getting back. I was initially doing some backend work and using Graphite, and coworker wasn't using graphite, and had some frontend work in a branch that contained my work. Our workflow involved periodically merging my updates from my stack's top branch into coworker's working branch. Now we'd like to try using Graphite to collaborate on a stack, so coworker did `gt dsg my-top-branch` and then `gt branch track` on her branch, then `gt upstack onto my-top-branch` and was able to do `gt stack submit` successfully. (That was the topic of my previous thread <https://graphite-community.slack.com/archives/C02DRNRA9RA/p1678923784979459>)

Now I'm not sure why, maybe due to the fact that we weren't initially using Graphite to collaborate, but every time I make a change in one of my lower branches, and then do `gt stack restack` I get a conflict when trying to rebase my coworker's branch (which is the new top branch). I tried to resolve the conflicts but maybe due how rebase works, more conflicts keep coming up over and over.. so instead of resolving the conflicts, I found that after doing `git merge -X theirs my-top-branch` into my coworker's branch, I'm able to do `gt stack restack` without conflicts. But every time I make a commit to a lower branch and do stack restack this conflict happens again.. Wondering if there is some way to stop this from happening? I think we are trying to build a new branch using Graphite rather than using the old branch... but wondering if that seems like a good idea, and also hoping to understand what might be happening and if there would be a simple way to stop the conflicts from happening over and over. Would `git rerere` be a good idea here? Or is there a way to merge or squash the commits somehow to prevent the rebase conflicts from recurring?

Update - we tried creating a new branch on top of my stack and then copying the changes over and so far we're not running into issues with the new branch. I'm able to commit a change in a lower branch and then `gt stack restack` works without rebase conflicts. We'll probably continue moving the work to the new branch.. but just curious if there is anything we could try with the old branch to avoid the recurring rebase conflicts

Screenshot 2023-03-21 at 9.05.54 AM.png

clicking on the thread should scroll you to it in the code though… does this only happen on comments on stale versions?

Yeah, clicking on threads on the most recent version will scroll you to it, but not threads from stale versions

hm so im having trouble reproing this for some reason~ clicking on a stale, resolved thread in the sidepanel does seem to expand and scroll to that thread in the left

can you confirm that the thread that you’re trying to scroll to exists somewhere in the code view?

Ah, it will jump to the thread if the code is unfolded; but if you click on “viewed” and the file is collapsed, then it doesn’t?

ahh got it~ let me see if i can fix that!

we’ve got this working locally! should be resolved for you by tomorrow :slightly_smiling_face:

My inline commetns show up in github but aren’t in graphite

Did you save the comment as draft, or were you in the middle of typing?

Also, if you can DM me PR repo/org/number I can take a look at logs

Hi <@U03EN73V2DP>! We’re currently experience a prod regression regarding commenting

Rolling out a fix ASAP! Sorry about this — <https://graphite-community.slack.com/archives/C02DRNRA9RA/p1679425454171599?thread_ts=1679425126.454369&amp;cid=C02DRNRA9RA>

hi <@U04UL878KCP>! Sorry you’re running into these issues

Can you share a little more info on these two issues so that we can dig in?

Sure. For the first issue, the 'repos' drop down shows nothing (but reports 3 repos available). For the second issue, I click 'log out' and Graphite does some gear animation and then returns me back to my logged in page.

I don't really care about the second issue personally but I'm happy to help report it.

We're rolling out a fix for this ASAP! Sorry about that

Thanks for bearing with us — we accidentally released a broken version of the site to production due to a mistaken action in our deployment pipeline

Hi all! We have a known regression on prod right now that’s leading to website 500's. A fix is being deployed now, hoping to have things working again in ~10 min

Fix deployed and verified 15 minutes ago, everything should be back to normal

cc <@U047KHH8JH3> who can take a look :slightly_smiling_face:

Screenshot 2023-03-23 at 10-02-42 Graphite.png

this stopped for a while yesterday afternoon, but is now happening again.

CleanShot 2023-03-23 at 13.40.32.mp4

Weird - sorry about that! We'll look into it

Hey, I am still running into this issue (have been since yesterday). As others noted, nothing strange in network tab/console. Are there any action items I need to take on my end to resolve?

We’ll investigate.

As a workaround for now: in the modal to “proceed to GitHub” you can right-click and choose “Open in new tab” to proceed

<@U04MBBA1AA2> <@U03CW1KTA1L> <@U0500F9K98S> You might need to hard refresh the page but the issue should be resolved now. Let us know if you still see it on your end.

thanks for flagging! we are currently looking into resolving this

we have just made the fix &amp; validated on our end - are you still unable to view the code on your PR page?

sorry about that - we're making some pretty big cache/usage improvements (cc <@U02DGG36CSH> <@U02DGG322G5>) which might be causing some intermittent failures, but the goal is that it will make the overall experience more enjoyable/fast in the future!

thanks for bearing with us though :heart_hands:

Yeah I totally get it, is this fairly expected right now? Just want to know if it's worth reporting when it happens consistently or if it's something that's generally known.

There shouldn't have been any big issues prior to 9 PM EST yesterday, and then one breakage on Tuesday for a few hours. The UI shouldn't be consistently loading slowly. Is this still an issue for you?

<@U04RXRV9K35> keep reporting - we appreciate the flags!

Thanks for this! Some of my coworkers received this message and we were freaking out :fearful:

Since Github did this, and I followed their instructions in this blog post, I have been unable to use any pull related commands through the Graphite cli. If I do `git pull --ff-only origin main` it works fine, but when I try to do `gt repo sync` or even `gt pull --ff-only origin main` I get this error:
```🌲 Pulling main from remote...
ERROR: Command failed with error exit code 1:
git pull --ff-only origin main

ssh: Could not resolve hostname <http://github.com|github.com>: Temporary failure in name resolution
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.```

hello! are you still having this issue <@U03GB27NS3A>?

I'm not at my computer right now, but I've been having this problem since Saturday, so I have to assume it's not suddenly fixed itself.

You can fix by running
```ssh-keygen -R <http://github.com|github.com>```
