Open rynoV opened 6 months ago
Sounds great! In case you want to start on this, I'm happy to help!
Places I'd start at are:
Vec<Item>
, each Item being a visual line seen in Gitu, as well as some metadata.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#L148Could focus on one of these to start! :)
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!
@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
@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 👍
@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
@rynoV looks good. It is now in master!
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
...
git rebase origin/master
git rebase other/deleteme
git … push origin deleteme\:refs/heads/master
git … push other refs/heads/deleteme\:refs/heads/deleteme
git … pull origin refs/heads/master
git … pull other deleteme
git fetch origin
git fetch other
PC
, bC
, FC
and more?)push.default
?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
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:master
and my feature branch has fallen behindmaster
or the remote tracked branch into my local branchThe main features from Magit that I'd like to see in this project:
branch.<name>.pushRemote
(if it's not already set) when using the "push to pushRemote" keybind, in the same way as MagitI'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.