You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to be able to compare the current branch versus the upstream version. For this I enter the values @ against @{u} in the dialogs that open from the command "Gitlens: Compare References...". This does work and is very helpful to immediately know what has changed on one side. The problem with this is: @{u} is resolved to a concrete git hash when the dialog closes for the revision.
When I switch to another branch I have to remove this compare references and create another one where I enter the same two values as above.
I'd like to be able just hit the refresh button on the compare references item in the "search & compare" view.
Is there a reason, this is resolved so early? On the other hand, branch references are not resolved and here this behaves as desired already. There are many ways to search for commits and there are probably more interesting use cases hidden behind this approach. Can it be toggled to resolve later?
The text was updated successfully, but these errors were encountered:
Description
I'd like to be able to compare the current branch versus the upstream version. For this I enter the values
@
against@{u}
in the dialogs that open from the command "Gitlens: Compare References...". This does work and is very helpful to immediately know what has changed on one side. The problem with this is:@{u}
is resolved to a concrete git hash when the dialog closes for the revision.When I switch to another branch I have to remove this compare references and create another one where I enter the same two values as above.
I'd like to be able just hit the refresh button on the compare references item in the "search & compare" view.
Is there a reason, this is resolved so early? On the other hand, branch references are not resolved and here this behaves as desired already. There are many ways to search for commits and there are probably more interesting use cases hidden behind this approach. Can it be toggled to resolve later?
The text was updated successfully, but these errors were encountered: