Graphite Community

dpi144.png

Retina screenshot (in Preview &gt; Cmd+I, Image DPI is 144)

dpi72.png

If you upload these to GitHub's editor, you can see dpi144 results in a `&lt;img width="128"` scaled "down", but the dpi72 is inserted as `![dpi72](url)`

Hi there! Thanks for flagging - I'll make a note and bring it up with the team

I just wrote something about this internally - we’re going to fix!

Thanks for flagging! We'll look into this and follow up

<@U047KHH8JH3> is working on this! We'll update when there's a fix

Hi Mark - this is supposed to be fixed now but we know there might be rough edges, so please let us know if you see any more bugs like this!

That's awesome news, thank you <@U047KHH8JH3>! I'll keep an eye out.

is this happening when dragging to attach an image? if so you should be able to drop it onto a precise location in the description by hovering over a spot in the editor

Yeah, it actually ends up putting it in a random spot not the highlighted spot

oof, thanks for the flag! if you have a video of the behavior or repro steps that would be really helpful so we can investigate further (cc <@U05597DUYDD>)

&gt; highlighted spot
you mean you're highlighting text and attempting to replace it <@U05K9UTHB19>?

(please definitely record a video, on mac open QuickTime Player and hit `cmd ctrl n` to start a new screen capture, draw the box around the area, and hit record)

without a video i'm unlikely to be able to dig into this

filed a Linear ticket, and we'll triage asap

upload-while-scrolled.mov

<@U05K9UTHB19> i have a fix, it'll go out after review, deploy, pipeline

Screenshot 2023-08-04 at 1.24.04 PM.png

started working again actually; seems to be some transient issue

Usually this is fixed with a hard refresh (cmd shift r)

Yeah tried hard refreshing, but didn't work until couple minutes later

Screenshot 2023-08-07 at 2.43.07 PM.png

I have a main &lt;- 1-n &lt;- 2-n stack and `gt stack restack` runs just fine but `test restack` fails

I tried with `--debug` and it didn't give any helpful messages. When I tried looking at `Output files: /var/folders/gg/xctw127s4hs8gzlcdtghgzdr0000gn/T/tmp-31480-L1GLB4ngiQkT/` that file didn't actually exist

What are you expecting `gt stack test restack` to do?  There might be some confusion about what this command does — `stack test` is a command meant for running e.g. a test command on everything in your stack — something like `gt stack test 'cargo test'` for a rust project will run `cargo test` on each branch in the stack?

As for the output file not existing, that seems like a bug

Ahh I see I was expecting it to be a "dry run" feature where I can see what happens with `restack`  (e.g. if there will be merge conflicts) without it actually trying to restack

I saw the `--dry-run` flag but saw that it was only applicable to the `submit` sub command

Ah, we don't have a dry-run flag for restack right now — but I like the idea! Aligns with some other work we have planned for restack

Thanks for pointing this out. It looks like this error message is referencing the wrong PR. It looks like there is a case, when some PR in the stack were merged, but others hit a failure where we reference the incorrect PR as causing the failure. We will look into fixing this.

Ah, strange. If it's any help, I just merged the PRs individually from Graphite CLI (went to bottom-most PR, merged, went to next PR, merged, etc.) and they all worked fine.

Said PR _did_ have an error (CI failure) I believe, so it was an initially correct error, but it seemed to persist.

rerequest all.mov

Hi there! Still running into this, or was it transient?

haven't had the opportunity to repro but will let u know if it recurs!

I ran `rm .git/.graphite_*`
Then the cache clear and init reset, and I am saved.

Edit: disregard, all good now! For some reason <http://app.graphite.dev|app.graphite.dev> was redirecting me to staging but that's stopped and the normal User account pages work as expected.

:wave: ~I am getting auth errors trying to `gt stack submit`,~

```ERROR: Your Graphite auth token is invalid/expired.

Please obtain a new auth token by visiting <https://app.graphite.dev/activate>.```
~The Github PAT I was using expired this morning, and I mistakenly ran `gt auth --token &lt;new-pat&gt;` instead of uploading it at <https://app.stg.graphite.dev/settings>. No problem, fixed that and went to go issue myself a new Graphite token at <https://app.stg.graphite.dev/settings/cli>, but when I create a new token and `gt auth` with that, the follow-up `gt stack submit` still says its invalid. Also when I refresh the page, it shows I have no active tokens.~

Screenshot 2023-08-08 at 12.53.53 PM.png

Screenshot 2023-08-08 at 12.54.13 PM.png

Hi! Was this transient, or are things still not loading for you?

Screenshot 2023-08-08 at 11.08.54 AM.png

Hi there! Might be related to above - investigating

CleanShot 2023-08-08 at 12.33.58@2x.png

For context this is within an Arc Peek view

CleanShot 2023-08-08 at 12.35.04@2x.png

image.png

eventually I got this. Would be better if Ctrl C worked

worked on retry. I really don’t mind brief availability snags like this as long as ctrl-C + up + enter works.

<@U02RREE9GKH> i wonder if sub-shells are swallowing ctrl c?

hmm, we should be handling signals from spawned processes correctly

it might be the fetch that's causing this

CleanShot 2023-08-08 at 19.10.00@2x.png

That shouldn't affect your Graphite usage though. Try hard refreshing

took a few refreshes and then data populated

this is a confusing UI -- the branch listed here is the branch the pr will eventually merge into, and then the hover shows the github dependency

I think we can do a better job making this clear

(the thinking here is that the stack view should already show you the parent PR)

at a quick glance, especially in a stack of 2 or more i forget the order :joy: it would be helpful to know which its going into via the arrow

you could make a setting for which youd like to see, i guess. the parent branch or fully merged parent

what are those 2 screenshots? is one github and one graphite?

they seem identical to me? can you call out explicitly what you're finding weird because i'm not getting a good sense from the screenshots alone

yes! Look at the text where it says "we are committed to limiting t&lt;RANDOM LINE BREAK&gt;" on the left (Graphite), versus looking normal on the right

cool, do you mind sending me an exact copy paste of:
• that line, on `main`
• that line, on your feature branch
here, so we can repro at least?

<@U04AP0M9AES> i think/hope this is just a word-break css thing that we can tweak

we probably want to break on words/whitespace vs. chars

(we can also just see what css github uses for breaks and try to use that)

there are no actual breaks there... I think it's breaking after a number of characters

I'll try and get to it, but it might be a bit before I can

sure - just feel free to copy the line from the left side and paste it here
```inside triple ticks```

oh, I don't think the change in the string actually matters for it

but maybe? Are you having trouble reproing?

the easier the repro the faster i'll get to it :slightly_smiling_face:

but i can try a random string, i just thought it would be better to use the string that was causing you weirdness

and/or to capture it in a ticket for someone else

Totally. My covid brain can’t find the pr, which is ridiculous, it should be easy. Man, covid is no joke

I’d just make a pr with a long string in some jsx. If I get another moment tomorrow I’ll try and find the pr again 

oh my default dummy test PR is this RFC, i'll just line wrap it and see what happens

<@U045W8WMUN5> just search your editor for that string, then `git blame` the line back to the PR? then you can probably get the diff/patch from there

also i can't tell if you're in split view or not from your screenshot

ok, so the edit has to be big enough–i think our character-level highlights don't wrap correctly

as they have an extra `&lt;span&gt;` wrapping them

you can only really see it when you change an entire sentence worth of material

The weird thing is I apparently haven't landed the change yet, so I can't search for it. But I also can't find which open PR it is. Do you still want me to try and find it, or is your repro enough?

This pops up for me each time we build a brand site and insert all the marketing copy. It's not the worst issue or anything... mainly it's just not confidence-inspiring when comparing Graphite/Github review UI, so I wanted to report it.

we have a fix for this which should be available soon!

Graphite - PR diffs are not loading ​*[Investigating]*​ We are currently investigating this incident.
 ​*Affected:*​
Dashboard
 View incident button

bug graphite log.png

I have a consistent repro on this issue now and should have a fix today — this is also manifesting as `submit --update-only/-u` not updating existing PRs in certain cases

Fix for this is in our merge queue now! It's server-side, as soon as it deploys everything should start working again here.  That should be some time in the next few hours.

<@U02RREE9GKH> can you ping when it's updated?

~Both of the above reports are due to what seems to be an issue with us not syncing the PR data to the CLI correctly, looking into it!~ Actually the first was due to a different issue, but the second seems to be happening to multiple users

CleanShot 2023-08-10 at 14.29.20.png

Hi! Thanks for flagging, we'll see if we can push a fix

Screenshot 2023-08-10 at 11.31.44 AM.png

Hi there! Oof, was this transient, or are you still seeing the issue?

At the time it persisted on refresh. I’m not seeing this issue at the moment though

Ah we've seen this before! Thanks for re-surfacing, we'll see what we can do!

Screen Shot 2023-08-10 at 1.30.35 PM.png

Screen Shot 2023-08-10 at 1.30.27 PM.png

I’m seeing a bug with the CI Status indicator where it’s showing me “CI Failing Required” on a PR where only a non-required check is failing. I would expect to see the orange check icon for “CI Failing Non-Required”

CleanShot 2023-08-10 at 10.46.49@2x.png

CleanShot 2023-08-10 at 10.45.56@2x.png

I think it's because you did some manual interactive rebase operations in the middle – I don't think that our `continue` command is currently built to handle that case

I only did the manual operations after `continue` failed once

The only operation missing in the screenshots is editing the file that had the conflict, right before `git add .`

I think the empty "Unmerged files" section is a bug with us not detecting a certain type of change

Thanks for reporting — I'll try to reproduce

CleanShot 2023-08-10 at 10.50.47@2x.png

I thought so too; so I tried `git status` after the failure but I didn't really understand the output. Cropped screenshot of that part here

It's my first time seeing git suggest the `--edit-todo` and `--amend` during a rebase. I vaguely remember it usually just has you `git commit` and `git rebase --continue`? though it's been a while since I rebased without graphite

CleanShot 2023-08-11 at 11.30.16@2x.png

CleanShot 2023-08-11 at 11.31.04@2x.png

here's my status before doing anything else

what was the last command you ran before reaching this state?

just to make sure i understand the full context

CleanShot 2023-08-11 at 11.40.45@2x.png

(ignore the first command, I ctrl-c'd it)

hmm, if branch2 were dependent on branch1, and branch1 is no longer tracked, then branch2 in theory should be considered untracked as well — what does `gt ls` show as branch2's current parent?

I've updated the message above to remove redactions:

`branch1` = `mark/api/schedule-expiry-pro`, the one that operation could not be performed on

`branch2` = `mark/api/expires-at-past-check`, the branch that is to be deleted

Here's `gt ls` output with some redactions

I guess `mark/api/direct-mail-commerce-sv` is the parent of `mark/api/expires-at-past-check`?

`mark/api/schedule-expiry-pro` does not appear anywhere in `gt ls`

Screenshot 2023-08-11 at 2.27.46 PM.png

Are you trying `get` a branch with an ancestor that has already been merged? I think there is a bug in that case that we haven't squashed yet.

We should add a request-id here for debugging like we did for `submit` — cc <@U05597DUYDD> /<@U05D5ADT4K1>

<@U02RREE9GKH> yep, just checked - that does seem true

<@U02RREE9GKH> happening again on a different branch - things have been merged to master since the branch was created, but it wasnt branched off of some other previously merged stack/branch - its just a handufl of commits out of date. Seems weird

I added some more logging over the weekend, let me see what might be happening

At the time you originally ran this command, had it not been submitted by someone using Graphite?

I'm seeing that we didn't have a record of the depdencies of this branch until about half an hour ago (~10PM UTC)

ah, yeah the author is not using `gt`. I used to be able to grab arbitrary PRs, regardless of creation source (`git` vs `gt`)

Hmm, I don't remember us ever supporting that via `downstack get` but I think it shouldn't be hard to add

I suspect it may never have been officially supported, but it definitely worked for a long-ish period of time

yeah, at least now you'll know why it's failed — let me know if you do see this unexpectedly again though!