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

Support "GitLab-specific references" passed via CLI? #822

Open
claytonrcarter opened this issue Apr 7, 2022 · 4 comments
Open

Support "GitLab-specific references" passed via CLI? #822

claytonrcarter opened this issue Apr 7, 2022 · 4 comments

Comments

@claytonrcarter
Copy link
Collaborator

GL supports many different special "references" in markdown. These are the shortcuts like #number to refer to an issue or !number to refer to an MR. Although it doesn't come up super often, there are semi-regular cases where I want to paste something into the cli like lab mr b <paste> but my clipboard includes the !. As we've already documented, I'm lazy and I think it would be really great of lab was able to deal w/ something like lab mr show !123.

Although there are many different shorthand references, I suspect that supporting issues and MRs would cover most of the use-cases.

This could be as simple as an update to

lab/cmd/util.go

Lines 290 to 306 in 73bada2

func parseArgsStringAndID(args []string) (string, int64, error) {
if len(args) == 2 {
n, err := strconv.ParseInt(args[1], 0, 64)
if err != nil {
return args[0], 0, err
}
return args[0], n, nil
}
if len(args) == 1 {
n, err := strconv.ParseInt(args[0], 0, 64)
if err != nil {
return args[0], 0, nil
}
return "", n, nil
}
return "", 0, nil
}
that strips the first char of an arg if it happens to be [#!], or it could be more robust where an error is thrown if, eg, we try call lab mr b #123 (ie I try to browse to an MR but give an issue ref).

If there's interest in this, I can take a whack at it. If the add'l "you're trying to browse to a mr but you passed an issue" is desired, that might extend beyond the scope of my abilities, though.

@fmuellner
Copy link
Contributor

I want to paste something into the cli like lab mr b <paste>

A simple paste won't work, because without escaping, both # and ! are interpreted by the shell before the argument reaches lab.

I'm not sure how much of a showstopper that is - on the one hand, adding quotes or \ still seems easier than stripping the prefix, on the other hand it can be a bit confusing if you aren't aware of the issue:

$ lab issue show #123
2022/04/08 01:01:48 ERROR: issue_show.go:35: Specify <id> of issue to be show

@claytonrcarter
Copy link
Collaborator Author

Oh, of course. I hadn't thought of that! Good call.

This sent me down a bit of a rabbit hole, though. It looks like different shells handle these differently: bash won't natively pass #100 or !100, zsh will pass #100 but not !100, and fish (my shell, fwiw) will not pass #100 but will pass !100. (I tried these out w/ echo #100 and echo !100; maybe there's something else I'm missing, though.)

In general, double-click on macOS will select just the digits w/o the prefix, so I can easily copy/paste a single MR/issue id w/o the prefix. The specific use case that spurred me to open the issue was copying a preexisting list of MRs in !123 !456 !789 format and I wanted to grep some info out of mr show for each of them. I used for mr in <paste>; mr show $mr | grep ... ; end but had to manually strip the ! for each. (Oh, the chore!) Something like pbpaste | xargs -n 1 lab mr b {} comes to mind as well to be able to open a new tab for each MR in a list; I think that xargs would skip the shell interpretation.

Anyway, just more fodder for discussion. Thanks for considering!

@claytonrcarter
Copy link
Collaborator Author

Tinkering tinkering ... I played w/ this and it seems like strings.TrimLeft(args[1], "#!") was enough to make it work. So even if it's not useful for the project ... it's easy enough for me to keep it patched locally. 😄

@fmuellner
Copy link
Contributor

Thanks for considering!

Oh, it's not up to me to consider the issue, I was only commenting from the sidelines 😂 (while being sympathetic to the suggestion)

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

No branches or pull requests

2 participants