[Feature request] Support upstream/pushRemote workflow

[rynoV]

Thanks for making this! I really like it, especially for when I need to work on Windows.

One of the features I like about Magit is its support for easily differentiating a branch's upstream/merge and pushRemote. I first saw the feature+workflow described here, and now I find other git UIs without this feature like vscode's to be lacking. It's very convenient to be able to quickly see both the difference between the upstream merge target (e.g. master) and the remote branch being tracked (usually a "feature" branch with the same name as the local branch). For example, with Magit when I run a fetch:

• I can immediately see if some other feature has been merged to master and my feature branch has fallen behind
• I can immediately see if someone else, working on the same feature as me, has pushed to my feature branch and it has fallen behind
• I can quickly pull either master or the remote tracked branch into my local branch

The main features from Magit that I'd like to see in this project:

• Support for the separate push/fetch/pull keybinds described here for pushRemote vs upstream/merge
• Support for the two sections in the main status screen showing the diff between the local branch and pushRemote, and the local branch and upstream/merge
• Support for automatically setting branch.<name>.pushRemote (if it's not already set) when using the "push to pushRemote" keybind, in the same way as Magit

I'm not sure how big of an ask this is, I haven't looked at the codebase yet, but I like the project and I like rust so I might try implementing this at some point.

[altsem]

Sounds great! In case you want to start on this, I'm happy to help!

Places I'd start at are:

• For the status page, you'll find everything in src/screen/status.rs It produces a Vec<Item>, each Item being a visual line seen in Gitu, as well as some metadata.
• push/pull/fetch are incredibly simple at the moment. Been trying to modularize these to make them easier to read, found e.g. here: src/ops/push.rs. Register the new actions. e.g. PullUpstream(push::PullUpstream) at this place: https://github.com/altsem/gitu/blob/7c0f628df95e776a7e0d894bac950d2f18e18c2f/src/ops/mod.rs#L52 Then a keybind can be added in here, like: https://github.com/altsem/gitu/blob/7c0f628df95e776a7e0d894bac950d2f18e18c2f/src/keybinds.rs#L148

Could focus on one of these to start! :)

[rynoV]

I started looking into this today, I'm currently trying to figure out a good way to start experimenting with git2, planning to start setting up some tests using the tests/helpers.rs file. Glad to see there's already some good testing infrastructure set up!

[rynoV]

@altsem What do you think about moving some of the test helper code into the src folder? In particular the parts of the helpers that set up a temporary repo. It seems you've stuck with end-to-end UI tests so far, but I wanted to set up some tests for my git helper functions (stuff like changing repo config), but the src/git module isn't exposed for the tests folder to use. Exposing it also seems okay to me, lmk what you think

[altsem]

@rynoV I'm thinking all tests could be moved back. They used to be in src/

Especially now that I moved things into modules (ops::*)

Perhaps if you want to start small, just move the helpers 👍

[rynoV]

@altsem I ended up moving them all into src because I ran into the issue of how to import the test utils from src into tests while still excluding them via cfg(test), so this seemed easier

The commit here for cherrypicking: https://github.com/rynoV/gitu/commit/ab4ccb4dfba42161e200e4a658ce732fdeaa1338

[altsem]

@rynoV looks good. It is now in master!

[altsem]

I had a peek at just trying to understand all the bits and pieces we'd need to do in order to support this. Here's what a summary of it:

Currently Push/Pull will just equate to git push and git pull. These two commands depend on the user's configuration of git: push.default.

The remotes are configured in a repo's .git/config, in it, entries are stored like:

[branch "deleteme"]
    remote = origin
    merge = refs/heads/master
    pushRemote = other

and can be read via git/(libgit2):

❯ git config branch.deleteme.pushRemote
origin
...

How Magit looks like:

TODO

• [ ] Send upstream/pushRemote as arg to:
  • [ ] Rebase:
  • [ ] upstream -> git rebase origin/master
  • [ ] pushRemote -> git rebase other/deleteme
  • [ ] Push:
  • [ ] upstream -> git … push origin deleteme\:refs/heads/master
  • [ ] pushRemote -> git … push other refs/heads/deleteme\:refs/heads/deleteme
  • [ ] Pull:
  • [ ] upstream -> git … pull origin refs/heads/master
  • [ ] pushRemote -> git … pull other deleteme
  • [ ] Fetch:
  • [ ] upstream -> git fetch origin
  • [ ] pushRemote -> git fetch other
• [ ] Branch configuration menu (You can reach this in various ways in Magit: PC, bC, FC and more?)
• [ ] Prompt to set upstream/pushRemote if attempting to use one that is not set. How does this work in detail in Magit? Is it based on a user's push.default?

Future work

• Display upstream + rebase/merge commits on status page:

[rynoV]

Thanks for looking into this that's helpful!

I merged my branch with the latest changes today. Currently I have code to set the upstream of a branch like magit does it, next will be to set the push remote and expose these functions from the branch config menu