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

Feature: add a git push command / mapping #24

Open
jreybert opened this issue Oct 26, 2015 · 5 comments
Open

Feature: add a git push command / mapping #24

jreybert opened this issue Oct 26, 2015 · 5 comments
Labels
backlog This issue will be done later enhancement

Comments

@jreybert
Copy link
Owner

jreybert commented Oct 26, 2015

This feature must handle correctly git behavior of default remote branch. When user push without defining the remote repo and/or branch, vimagit will need to choose between:

  • @{upstream} if it is set
  • current default push url + current branch
  • current default url + current branch
  • origin if exists + current branch

This list may is certainly wrong, and must be corrected.

When none of the above default behavior is found, user is invited to choose the repo and the remote branch.

When the user choose the repo and/or the remote branch:

  • repo can completed with a list of existing repo
  • remote branch can be completed with current local branch and remote branches
@jreybert
Copy link
Owner Author

Hi @addcninblue
if you don't mind, I would prefer to continue the discussion here.

If I can help in any way, please let me know! I'd be happy to see git push added to this.

Excellent! PR are very welcomed. I don't have much time this year to add new features in vimagit. Anyway, this is quite a big feature, and maybe not the easiest way for a first PR. This feature will require good skills in both git and vimscript. I updated the feature description. It'll need to be detailed.

Other open tickets:

  • Stage multiple hunks or file by visually selecting them #83 : this one is not an easy one, but the it some has advantages: the requirement is clear, and it only require vimscript skills.
  • fix the display of stash: you'll need to understand how git handle stash internally (a stash can be a bunch of 3 or 4 commits, depending if you stash untracked files), and get inspired by current commit display. There is a development branch for this feature if you mind.

I would like to highlight that such new feature will need to be fully tested before being merged in next and/or master (see test/ repository).

As of right now, I'm guessing (based on my limited knowledge of Vimscript) that something like this: execute "nnoremap " . g:magit_push_mapping . " :call magit#push_command('cp')"needs to be added along with the respective 'git push' code.

That's a good start. Check out the updated feature description.

@jreybert
Copy link
Owner Author

jreybert commented Aug 3, 2017

See https://stackoverflow.com/questions/34099451/get-default-remote-push-and-default-remote-branch

From a script, I would like to get the default push remote and the default push branch.

For the recall, git will choose the remote between these settings, in this order:

  • branch..pushRemote
  • remote.pushDefault
  • branch..remote
  • very last default
    • origin if config push.default current
    • NULL if config push.default upstream

I can't find any reference how git is choosing this last default origin, but it seems static.

Default remote branch can be:

  • branch..merge if config push.default upstream
  • current branch name otherwise

Now, I would like a safe way to get both default push remote and default push branch.

  1. I could use git config --get, but I'll have to resolve myself the behoavior according to config push.default, and it seems a bit risky.
  2. I would prefer to use one of these:
    • git for-each-ref --format='%(push:short)' refs/heads/mybranch
    • git rev-parse --abbrev-ref=loose mybranch@{push}

Finally, I have two questions:

  • git for-each and git rev-parse returns a path like origin/mybranch. How can I split between the remote name and the branch name (a remote name can contains /'s).
  • Is there a safer function between the both? (in all my tests, they always return the same output).

@jreybert
Copy link
Owner Author

jreybert commented Aug 7, 2017

Current state of thought. Thanks to comment on:

  • default mappings
  • behaviors
  • missing commands

There may be several commands:

  • CPP: push current HEAD to default repo and remote branch. If no remote
  • CPPF: push force current HEAD to default repo and remote branch
  • CP: prompt the user to ask the remote and prompt again for the remote branch (with completion), and push
  • CPF: prompt the user to ask the remote and prompt again for the remote branch (with completion), and push force

There nothing especially magic around here. The main challenge is the user prompt with completion.

@fpnick
Copy link

fpnick commented Aug 8, 2017

I would cut CPPF from the list of commands: IMHO it's way too dangerous to have a shortcut for that. But this might be personal preference.

Secondly, for my personal use case it would be nice to have
CPR: ask the user for a remote name (with completion) and push to the upstream branch for that remote. I.e. like CP but without having to type the remote branch name.

@balzss
Copy link

balzss commented Jun 18, 2018

Hi,

First of all, thanks for the great plugin! I'm not a fan of Git GUIs but typing every command separately is not only tiresome but a bit limiting (e.g. I'd never stage separate hunks via CLI) so this is the perfect tool for me. The only thing I'm missing is the aforementioned push support and I understand that for a rich experience all these completion features and options are really important but a temporary git push addition would be really helpful. The only thing it should do is to call git push and close the vimagit window/pane. Do you think this is possible and/or worth implementing? I'm not familiar enough with vimscript to submit a PR but maybe I'll have a go with it. Thanks!

@jreybert jreybert added the backlog This issue will be done later label Oct 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog This issue will be done later enhancement
Projects
None yet
Development

No branches or pull requests

3 participants