Bug: Q ignores the branch cut for the Github issue

[wedgemartin]

Describe the bug

When I /q dev (would be cool fi I could pass in a string to add helpful hints like.. branch or other instructions) ... after I have created an issue and cut a branch so that it knows what code to look at, it still seems to be looking at the main branch where the code does not exist.

Expected Behavior

I would expect that Q would look at the branch cut for the issue, or accept some other method of indicating which branch it should be looking at.

Current Behavior

Ignores any indicator for which branch to examine / cut a PR from

Reproduction Steps

Cut a branch in your repo. Add some code to it that doesn't exist in main. Try to cut an issue and do a /q dev and have it analyze the code.

Possible Solution

Have Q examine the subject and comments for a branch designation, or have it use the branch cut specifically for the issue/PR.

Additional Information/Context

Former 6 year AWS amazonian here (us-west TAM). Really love Q, working great for the most part.

[dougclauson]

Thanks for the feedback. You're correct that today Q will branch on it's own off of the default branch. I understand the use case of providing a branch name for it to work in, are there other things you'd be interested in passing in? What kind of hints were you talking about?

[wedgemartin]

Yeah I wasn't able to figure out a way to get it to work on the development branch, so I just resorted to using the command line version. Hints would be like 'in file src/components/SignupForm.js' update it so that it prevents any possible scenario where the call to the /register endpoint may happen more than once at a time but I suppose that can be derived from the Github Issue itself, description, title, or comments.

[dougclauson]

That's the approach today. The agent would get the info from the issue itself, which is then stored for future use as well.

[wedgemartin]

Another idea for hints might be to reference another repo that Q is enabled in so that it can tie in front and back. A lot of teams like to separate their front end repo from their back end repo, and in working with Q yesterday it did an INCREDIBLE job of updating my API to handle what I had asked it for in my React code, but it currently would only work because my React app is in the same repo as my API (unless I'm just not aware of some other mechanism for it)