Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add last checkouts to tabcompletion #641

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

mpawelski
Copy link

Hi, thanks for this great project!
I think this small feature will make it even better ;-)

I really like git @{-N} syntax to checkout last used branches. I thought that if posh-git could suggest this last used branches first we would have nice user experience. You could just Tab and Shift+Tab and quickly choose the recent branch you need to work on again.

It would be very useful when you work on a lot of branches that have long names and you don't remember the name correctly (for example because it has Jira key at beginning, and who remembers that ;-)).

It looks that git source code does something very similar to what I have done here to get last checkout commits.

This adds functionality to suggest last used branches (and commits) when
tab completing "git checkout" command. This is inspired by "@{-N}" syntax that
you can use use now in git (for example "git checkout @{-1}" switch to last used
branch.
Copy link
Owner

@dahlbyk dahlbyk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this a lot! My only concern is performance, so I left a few suggestions toward that end.

Thanks for the contribution!

@@ -101,6 +101,13 @@ function script:gitCommands($filter, $includeAliases) {
$cmdList | Sort-Object
}

function script:lastCheckouts($filter){
git reflog |
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two suggestions here:

  1. Specify an explicit --format=%gs (I think?) to get only the log output you need. There might be other flags you can also specify to optimize the operation (e.g. --no-decorate).
  2. reflog can get quite long under active development, so I would add a --max-count=<number> to avoid scanning thousands of references.

Copy link
Author

@mpawelski mpawelski Nov 14, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I came up with two options and I'm not sure which will be better 🤔

  1. git log --walk-reflogs --max-count=100 --format=%gs
    get more number of reflogs and then search for "'checkout: moving from (.) to (.)'" pattern from result.
  2. git log --walk-reflogs --max-count=10 --grep-reflog='checkout: moving from ' --fixed-strings --format=%gs
    get less number of reflogs but already filtered to one with data that we need (containing "checkout: moving from" in reflog subject).

For me option 2) seems more tempting because you get less data from git command. However the performance can depend on how big is you reflog and how many entries it has that are not what we are looking for (we want only reflogs with "checkout: moving from" subject). In other words you don't know how many reflogs git will traverse to get you list of 10 reflogs you want.

I think 2) is fine. How many crazy operations (like rebases of huge number of commits) you would have to do between switching branch 10 times to have huge reflog that can affect performance?

What do you think? Which option would you like to have?

We got this message from git when we ran git log command:
"fatal: ambiguous argument 'moving': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'"

This change in quoting fixes it.
@mpawelski
Copy link
Author

I ended up with implementing seconds options as it seams "good enough" for me (for example for my repo I work on now I have reflog with over 600 entries and without --max-count=10 I get more that 130 entries back, so having --max-count and --grep-reflog seems like good approach).

BTW. I broke and fixed unit test that I wrote before, but I actually don't know why previous quoting broke unit test... When I executed both quote variants in terminal they run fine... 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants