[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:
  

  gitu/src/ops/mod.rs

  Line 52 in 7c0f628

  Pull(pull::Pull),

  
  Then a keybind can be added in here, like:
  

  gitu/src/keybinds.rs

  Line 148 in 7c0f628

  Keybind::nomod(SubmenuOp::Pull, Char('p'), Op::Pull(Pull)),

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: rynoV@ab4ccb4

[altsem]

@rynoV looks good. It is now in master!