allow to type a branch name

[parkouss]

Hi, first, thanks for this package!

I have a request - I am sometimes working on a local branch (not pushed to a remote location) and in this case using git-link generate a wrong url. Would it be possible to allow to chose the branch in some cases? I am thinking of something simple, e.g:

M-x git-link => do not prompt, generate link
C-u M-x git-link => ask for the remote name first
C-u C-u M-x git-link => ask for the remote and the branch name

Note that the first two options are already working this way, so it should not break the workflow for other users.

What do you think? I could work on a simple PR to implement this if you like the idea.

[sshaw]

Hi!

I am sometimes working on a local branch (not pushed to a remote location) and in this case using git-link generate a wrong url

Do you know about these options?

Would it be possible to allow to chose the branch in some cases?

Certainly seems reasonable.

I am thinking of something simple, e.g:
M-x git-link => do not prompt, generate link
C-u M-x git-link => ask for the remote name first
C-u C-u M-x git-link => ask for the remote and the branch n

Also seems reasonable, though could this be done another way? Just curious.

What do you think? I could work on a simple PR to implement this if you like the idea.

Pull request it up!

[sshaw]

C-u M-x git-link => ask for the remote name first
C-u C-u M-x git-link => ask for the remote and the branch name

But... what if someone only wants to specify the branch name? May get complicated.

At some point I wanted to remove git-link-commit and incorporate it into git-link. That's a lot of prefix options. So I guess my question of "could this be done another way" may be somewhat more relevant.

Maybe it's sign that adding git-link-commit to git-link is a bad idea. Or, that prompting for branch is 😈.

[ibizaman]

What about functions like these?

(defun git-link-master-branch ()
  (interactive)
  (let ((git-link-default-branch "master"))
    (call-interactively 'git-link)))
(defun git-link-at-commit ()
  (interactive)
  (let ((git-link-use-commit t))
    (call-interactively 'git-link)))

[dotemacs]

Hello o/

I really like git-link & have been using it for ages. Thank you for the work put in.

Oftentimes I have the same requirement that this thread is describing, where I'd like to link to a branch on GitHub (or some forge), that isn't the branch that I'm currently working on. I had some hacks in place to handle it. But revisited this repo to see if there's been some work on it.

Since git-link, the function, already handles a few current-prefix-arg options, I'm not sure what is the most elegant way to add the option for linking to a remote branch on a forge, while passing the prefix arg to git-link.

So I extended the function @ibizaman came up with, above:

(defun git-link-diffrent-branch (branch)
  "Invoke `git-link', but with the `branch' name set to a different
branch than the one you're currently working on."
  (interactive "P")
  (let* ((default-remote-branch-name "main")
         (git-link-current-branch-setting git-link-default-branch)
         (git-link-default-branch (if branch
                                      (completing-read
                                       (format "Instead of '%s' branch replace with branch: " (git-link--branch))
                                       (magit-list-branch-names))
                                    default-remote-branch-name)))
    (setq current-prefix-arg nil)
    (call-interactively 'git-link)
    (setq git-link-default-branch git-link-current-branch-setting)))

Ideally, I'd like git-link to just accept a prefix arg and then prompt you to provide:

• a remote (like it currently does)
• a branch
• a remote & a branch

Yes, this is all a PR away, but is it worth pursuing?

Thanks

[sshaw]

Yes, this is all a PR away, but is it worth pursuing?

@dotemacs yes I think so, the demand is there!

[dmitrym0]

Brilliant, I came here looking for this exact functionality. As a side effect, I finally learned what (interactive "P") means.

If all that needs to be done is to open up a PR for this, I'm happy to do so, with credit going to @dotemacs of course.

[dotemacs]

Sure, go for it & thanksOn 1 Nov 2024, at 4:59 PM, Dmitry ***@***.***> wrote: Brilliant, I came here looking for this exact functionality. As a side effect, I finally learned what (interactive "P") means. If all that needs to be done is to open up a PR for this, I'm happy to do so, with credit going to @dotemacs of course. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[dmitrym0]

Created #130, copy/pasting the code above. Though re-reading this thread now it may make sense to collapse this functionality into git-link? C-u git-link to select origin; C-u C-u git-link to select branch and origin. Thoughts?

[dotemacs]

Created #130, copy/pasting the code above.

Thanks.

Though re-reading this thread now it may make sense to collapse this functionality into git-link? C-u git-link to select origin; C-u C-u git-link to select branch and origin. Thoughts?

See what I wrote previously:

Since git-link, the function, already handles a few current-prefix-arg options, I'm not sure what is the most elegant way to add the option for linking to a remote branch on a forge, while passing the prefix arg to git-link.

This was the main reason I didn't create a PR, since I'm not sure if git-link function should be given one more prefix option.

I don't know what is the most elegant way to handle this. This is why I just create a new function instead.

[dmitrym0]

I don't know what is the most elegant way to handle this. This is why I just create a new function instead.

Upon reflection, does it even make sense to use C-u for git-link-different-branch? Keep git-link and git-link-different-branch separate. Eliminate the universal argument. Makes the functionality more discoverable imo.

[sshaw]

Upon reflection, does it even make sense to use C-u for git-link-different-branch? Keep git-link and git-link-different-branch separate. Eliminate the universal argument. Makes the functionality more discoverable imo.

The assumption made in the current design is that using a single interactive function with prefix arguments is "typical emacs interactive usage" in that one will call the git-link function via a key binding: e.g., (global-set-key (kbd "C-c g l") 'git-link) and that key bindings are finite.

If it was a different function, what that have a keybinding too?

Maybe keybindings are not so finite as there's plenty of space under the "C-c g" key namespace suggested in the docs, and git-link-different-branch could easily be bound there?

Besides that, "different branch" does feel more like an option to git-link. If we have a git-link-different-branch function shouldn't we also have git-link-different-remote and git-link-no-line-number functions? Public function namespace could continue to grow as more options are added.

I think prefix is better option, does is it not?