ref-based-insertions #7474
ref-based-insertions #7474
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
github-actions
bot
added
rust
| // Try to find parent based on branch position in stack | ||
| if (branches?.length) { | ||
| const currentBranchIndex = branches.findIndex((b) => b.name === branchName); | ||
|
|
||
| // If this branch has a "parent" branch in the stack | ||
| if (currentBranchIndex >= 0 && currentBranchIndex < branches.length - 1) { | ||
| const parentBranch = branches[currentBranchIndex + 1]; | ||
| if (parentBranch?.name) { | ||
| const parentCommit = stackService.commitAt(projectId, stackId, parentBranch.name, 0) | ||
| .current.data; | ||
|
|
||
| if (parentCommit?.id) return parentCommit.id; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Not sure if I'm reading correctly, but would this work if there are two empty branches, and you want to commit to the top one?
There was a problem hiding this comment.
No you're right, it wouldn't. First thing that comes to mind, we could while loop down the branches until we find the first branch with a commit that will act as parent.
Alternatively, it might be easier to have an API that returns something like StackBranch with an array of commits with basic metadata on it already, what do you think @mtsgrd @krlvi ?
There was a problem hiding this comment.
In theory we could have any number of empty branches in between the one you're committing to and a previous commit (or base), so I'd prefer to avoid the looping altogether by making the API capable of committing directly to a branch without specifying the parent commit. Let's chat in person during once Kiril is in the office.
There was a problem hiding this comment.
I think the API already takes a branch name that is currently used to insert into the correct 'bucket'. From there the parent commit could trivially be extracted.
A branch name will always be known, but it won't have to necessarily be pointing to a commit within the stack that the user sees. The V3 workspace information can represent such cases, but for now it should be sufficient if the UI passes the name it knows, or the parent commit, or both, the backend should be able to deal with it.
| /// | ||
| /// If there is ambiguity, this is what makes it ambiguous. | ||
| #[clap(long, short = 's')] | ||
| stack_segment_ref: Option<String>, |
There was a problem hiding this comment.
@krlvi I'm wondering if stack_segment is a term we want to introduce? To me it would feel more natural to talk about branches.
There was a problem hiding this comment.
For the UI we are gonna have to keep user-friendly language.
On the backend, the term stack segment describes a range between two references (which is distinct from branches, which will technically include each other)
ndom91
force-pushed
the
ref-based-insertions
branch
from
2bf3059 to
4cd0dcf
Compare
ndom91
force-pushed
the
ref-based-insertions
branch
from
4cd0dcf to
180f43c
Compare
🧢 Changes
☕️ Reasoning