Re: [PATCH 6/9] gitk: add keyboard bind for create and remove branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> IMO a selection dialog is the second-best solution. The best one is to
> make the branch labels selectable somehow via keyboard navigation. I am
> not a fan of the here implement behavior, because it is only a
> half-solution.

I added a branch selection dialog to the remove command, triggered when there is more than one branch on the selected commit. It works fine and is convenient to use. However, the implementation is more complicated and the patch is much larger.

Since the patch is larger I felt that it was warranted to clarify some variable names.

The checkout command also has got a branch selection dialog.

Create and remove commands have been put in separate commits.

/Jens


On 2023-06-28 22:30, Johannes Sixt wrote:
> Am 28.06.23 um 09:12 schrieb Jens Lideström:
>> My intention is to always remove the first branch head that is displayed
>> for a single commit in the GUI. This caters to the common use case, with
>> only one branch for a single commit. If there are multiple branch heads
>> on a commit and the users don't want to remove the first one then they
>> need to use the mouse context menu to choose which one to delete.
>>
>> I could change the implementation to display a dialog that lets the user
>> choose in case of multiple branch heads.
> 
> IMO a selection dialog is the second-best solution. The best one is to
> make the branch labels selectable somehow via keyboard navigation. I am
> not a fan of the here implement behavior, because it is only a
> half-solution.
> 
> Also, the order of branch labels on a line is not 100% deterministic:
> when you create a branch, it goes last, but when you refresh the view,
> branch labels are sorted alphabetically (I think). This means you can't
> create a branch and delete it right away if there is already a branch on
> the commit.
> 
>> In that case, should I do that as part of this PR, or as a follow up? I
>> would prefer to finish this one first.
> 
> My preference would be to not implement this behavior until it is clear
> what it should be.
> 
> -- Hannes
> 






[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux