git merge?
Hey there, I'm loving gitu so far! Just wanted to ask if git merge could be implemented. Maybe keybind 'm' could work?
Thanks and best wishes!
It should be! And relatively easy.
Could be a good first task for anyone interested in implementing :) A lot of code would be similar to the rebase module I imagine.
Actually, could I try implementing it myself this weekend? This project is really cool and I want to try contributing to it, and I can learn Rust at the same time :)
Feel free to give it a go and open a PR/draft. I'd try help out if you get stuck!
Thanks for the reassurance! I'm trying to workout the file structure so far, but I don't really understand how things are organised. Is there anywhere I can read on this? Or maybe you could help briefly explain the structure?
I think I got way too ahead of myself when I decided to take on this challenge, but that's where the learning happens!
Seems like the bulk of it is in /src/ops! I'll create a merge.rs file there and get to work on it :desktop_computer:
That seems about right! You could add a keybind in the default config and see where it breaks from there. There's a bunch of tests being ran if you do 'cargo test' too.
Current plan:
- if uncommitted/unstashed changes, warn user and abort
- assume current branch to be target branch. make this known to user (next bullet)
- ask user for branch to be merged. The prompt will be something like "Branch to merge into
: " - if any conflicts, let user know, User can choose to
- resolve conflicts (opens
git mergetool?) - abort and go back to pre-merge state (hence why committing/stashing is req) (
git merge --abort) - (i have no idea what
git merge --continuedoes but i think it's useless?)
- resolve conflicts (opens
- merge changes and open commit msg panel (latter is alr in gitu)
- commit!
Should an option to run merge without committing (git merge --no-commit) be added? Or maybe instead of forcing a commit msg panel, user can simply be notified that merge is ready to be committed and manual commit wld be req.
EDIT: Was trying out the rebase cmd and it's seems much better to follow for merge too. So I might not do the above, will see
That seems about right! You could add a keybind in the default config and see where it breaks from there. There's a bunch of tests being ran if you do 'cargo test' too.
Sure! I'll try that out. On the topic of tests, may I know what tests are exactly and how they are supposed to be used? I see test folders in diff repos but don't really know how they help in 'testing'.
I'm a bit busy this weekend but, I'd try sit down and see how Magit behaves, and try replicate as much as it makes sense :) The tests try simulate real usage to try keep bugs away. I can cook some tests for you at the end, don't have to worry about it if you don't want.
Ah, that explanation about tests makes sense.
Don't worry about me, I'll try my best!
Hey there, been working on and off on this. I realise that I should have asked this earlier, but how am I to test out what I have done so far? Even better if I can do so without overriding the existing gitu version. Will make test do the trick? I'm getting 422 errors with it currently 😅
Edit: cargo run --release seems to do the trick
Hey @arcxne.
It's a bit hard without more specifics, but I suspect some of the test snapshots may need updating if you add a new entry in the menu. Have a look at "cargo insta": https://insta.rs/docs/cli/
I would copy the existing test, and start from there: https://github.com/altsem/gitu/blob/master/src/tests/rebase.rs
Can we close this after the next release is cut?