Cherry Pick

[LovesAsuna]

Version

0.12.25

Operating System

Mac OS X

Distribution Method

dmg (Apple Silicon)

Describe the issue

I want to cherry pick a commit from a virtual branch to another. Because my changes are based on part of one of the virtual branches. This virtual branch has not yet been integrated into the target branch, so I'd like to do a cherry pick first (not a full commit, but maybe just a part of a commit or a file).

How to reproduce

No response

Expected behavior

No response

Relevant log output

No response

[Byron]

It should be possible to drag entire commits from one lane to another, or hunks from one lane to another as well. Is this something you tried, or is there an issue I am missing?

If so, maybe upload a video so it's clear what is attempted.
Thanks in advance for your help.

[LovesAsuna]

[Byron]

Invalid args: branchfor commandcreate_virtual_branch: ownership ranges cannot be empty is the error message displayed, when trying to move a single file out of a commit into the New branch (empty) lane.

It's easily reproducible now, thank you!

On stderr, one will see this right after (but no 'typical' error):

[2024-09-21][07:22:32][ERROR][Rt@tauri://localhost/_app/immutable/entry/app.CN3g50-3.js:2:3027] 9d9abf00c0a3451684adb9a104d21eb4: lifecycle_outside_component

xn@tauri://localhost/_app/immutable/chunks/index.BRFB7DrO.js:1:7216
g@tauri://localhost/_app/immutable/chunks/index-client.DHPHoFon.js:1:521
@tauri://localhost/_app/immutable/chunks/CommitCard.Dvwviucn.js:287:6357




2024-09-21 09:22:40.042 GitButler[98579:4957218] _TIPropertyValueIsValid called with 16 on nil context!
2024-09-21 09:22:40.042 GitButler[98579:4957218] imkxpc_getApplicationProperty:reply: called with incorrect property value 16, bailing.
2024-09-21 09:22:40.042 GitButler[98579:4957218] Text input context does not respond to _valueForTIProperty:
[2024-09-21][07:22:41][ERROR][Rt@tauri://localhost/_app/immutable/entry/app.CN3g50-3.js:2:3027] 1f76d1f4220444eb8190005661803647: lifecycle_outside_component

xn@tauri://localhost/_app/immutable/chunks/index.BRFB7DrO.js:1:7216
g@tauri://localhost/_app/immutable/chunks/index-client.DHPHoFon.js:1:521
@tauri://localhost/_app/immutable/chunks/CommitCard.Dvwviucn.js:287:6357

CC @Caleb-T-Owens, who told me he loves fixing stuff :).

[LovesAsuna]

I may not be able to reproduce my problem with a simple demo, but I'll take a problem that I encountered in an actual project.

@Byron This may be another issue, in fact the main thing I'm wondering is why I can't drag a file to a virtual branch that already exists

[LovesAsuna]

For the above reasons, this resulted in me having to only create a new virtual branch, thus realizing the problem in the beginning

[Byron]

@Byron This may be another issue, in fact the main thing I'm wondering is why I can't drag a file to a virtual branch that already exists

It's true that it's also not possible to add a file to an existing virtual branch when dragged from a commit. The UI indicates that a new branch can be created from it though, even though it doesn't currently claim that it can be dragged to an existing branch.

Since this is probably something with the drag-logic, let me CC @ndom91 as well.

[Caleb-T-Owens]

Hi @Byron, thanks for tagging me!

We've noticed that our frontend isn't updating selected ownership state correctly.

(Easy repro is having two branches, one with for hunks in a file. Drag two of the hunks to the other lane. Then try drag the other hunks by dragging and dropping the entire file into the second branch).

I suspect that this is likely related.

[Caleb-T-Owens]

Related issue: #4934

[LovesAsuna]

Can this issue be fixed in the next release? It feels like it affects the experience quite a bit

[Caleb-T-Owens]

Hi! I’m currently working on a fix so this should be resolved in the next release. Sorry for any trouble that its causing you. As a temporary workaround, if you find that files aren’t dragging correctly, you can press “Cmd+R” to reload the application state which should make them correctly draggable again.

…

On 23 Sep 2024, at 13:05, 梦曦·花已落 ***@***.***> wrote: Can this issue be fixed in the next release? It feels like it affects the experience quite a bit — Reply to this email directly, view it on GitHub <#4951 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADF4JKZNO6GWFQURP2NN2KDZX7YZJAVCNFSM6AAAAABOO53YNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRXHA4TGMJYGI>. You are receiving this because you were mentioned.

[LovesAsuna]

I've seen the latest release mention that there is a fix, but it seems that neither issue has been addressed. @Caleb-T-Owens

[LovesAsuna]

Is this still a concern? @Byron

[Byron]

There have been a lot of changes and I am definitely not caught up :/, but would think that @Caleb-T-Owens has all the answers (especially since two weeks are a lot of time).

[estib-vega]

@LovesAsuna Sorry for the long wait and back and forward

It seems like this is a FE issue. The UI shouldn't highlight the possibility of creating a new branch from a file that's already been committed.

I'll fix that

[LovesAsuna]

@LovesAsuna Sorry for the long wait and back and forward

It seems like this is a FE issue. The UI shouldn't highlight the possibility of creating a new branch from a file that's already been committed.

I'll fix that

Is "Invalid args branch for command create_virtual_branch: ownership ranges cannot be empty" a FE issue?

[estib-vega]

@LovesAsuna Sorry for the long wait and back and forward

It seems like this is a FE issue. The UI shouldn't highlight the possibility of creating a new branch from a file that's already been committed.

I'll fix that

Is "Invalid args branch for command create_virtual_branch: ownership ranges cannot be empty" a FE issue?

@LovesAsuna it is in the sense that we should consider it an invalid operation. In order to move files, they should first be uncommitted and then drag-and-dropped.

The UI should stop you ortherwise

[LovesAsuna]

@LovesAsuna it is in the sense that we should consider it an invalid operation. In order to move files, they should first be uncommitted and then drag-and-dropped.

The UI should stop you ortherwise

But how do I copy a commit to another virtual branch?

[estib-vega]

But how do I copy a commit to another virtual branch?

You can drag the whole commit.

If the files in the commit are not "locked" to that branch, you should be able to drag it to another branch.

"Locked" here just means that it has changes that overlap with changes in other files in the origin branch

[LovesAsuna]

If the files in the commit are not "locked" to that branch, you should be able to drag it to another branch.

Dragging a commit directly changes the original virtual branch (even if it's not locked), not the cherry pick logic.
I'd like to add an optional copy commit logic.

[estib-vega]

Dragging a commit directly changes the original virtual branch (even if it's not locked), not the cherry pick logic.

I'd like to add an optional copy commit logic.

Oh sorry, I had misunderstood.

That is not possible right now.
The virtual branches can't have duplicated changes.
I'm sorry about that.

I want to understand fully your workflow, though:
You have a "main" virtual branch.
You start a second one that now partially depends on the main one.

What you wanted to do is to be able to duplicate just enough changes and move them into the second one. Have it integrated and then at some point rebase the main branch on top of the latest version or what's on origin

Did I understand that correctly?

[LovesAsuna]

Yes, this usually happens when there are two parallel pieces of work, but there is partially coupled code in them that leads to having to do this

[estib-vega]

@LovesAsuna I see. I definitely have been in that situation. In some cases, stacking changes (see #3031) should enable you to get around this kind of issues.

I think your specific one wouldn't be fully supported still, because (if I understood correctly) you don't want to submit the main branch.

I'll bring it up with the team, though. It would be nice to have a way to achieve that in GitButler

[estib-vega]

Thanks for reporting this and the subsequent clarifications!