Change diff renamed files

[Mifom]

This Pull Request closes #1038.

It changes the following:

• Add status change on rename
• Change diff title to represent rename
• Change diff to show only rewrites on rename

I followed the checklist:

• I added and fixed current unittests.
• I ran make check without errors
• I tested the overall application
• I added an appropriate item to the changelog

[extrawurst]

@Mifom Thanks for looking into this. I played a bit around with you branch. did not check the code yet but two observations jump out:

a) we still do not detect renames against the workdir, this should be easy to add:

b) and then there is an issue staging hunks in the renamed&changed file:

b) current hunk staging code is a bit wonky, so don't worry If thats the reason, then this might be better done in a separate PR

[extrawurst]

lets add a dedicated unittest into asyncgit for the changed diff mechanic please

[Mifom]

I'll mark it ready when I deal with hunks

[Mifom]

For now hunks mostly done. But there are 2 1 issue:

1) Because destination file is untracked, diff in workdir is shown only for source file:

git currently works the same way.(fixed)

2. In changed renamed file is only one hunk - the whole file, so changes cannot be staged/unstaged without staging/unstaging full file:
   

@extrawurst is this issue need to be fixed in this PR? Currently it's not supported by git2 and libgit2.

[extrawurst]

is this issue need to be fixed in this PR? Currently it's not supported by git2 and libgit2.

i guess then not :)
But then we should just go for regular file-level stagin/upstaging when enter is used on a hunk in a renamed file I stead of creating an error

[extrawurst]

Then this is ready ?

[Mifom]

Then this is ready ?

Yes

[Mifom]

is this issue need to be fixed in this PR? Currently it's not supported by git2 and libgit2.

i guess then not :)
But then we should just go for regular file-level stagin/upstaging when enter is used on a hunk in a renamed file I stead of creating an error

If I understand correctly this is how it works now

[extrawurst]

@Mifom so functionality wise this looks awesome to me. but I am not sure what I am missing, cause I cannot reproduce the single-hunk-issue:

looks pretty good to me, with the only glitch that removing a hunk from the index removes the rename-part of the change aswell. but I guess thats a mini thing we can followup later with. especially cause its a philosophical decision of what should take precendence I guess :)

what do you think?

[extrawurst]

just a few minor things left and a proper test for the rename case

[extrawurst]

I found another issue left:

So discarding a renamed file item (now only a single entry in the status list) should discard fully, old-path and new-path. please also add a test for this case.

[extrawurst]

@Mifom let me know when I should review it again

[extrawurst]

@Mifom how can I help you get this over the finish line?

[Mifom]

@extrawurst I just need some time. I think I'll do it before the end of the week.

[extrawurst]

@Mifom thanks for your continued effort, let me know when you think its ready

[extrawurst]

@Mifom ping. feel free to join the discord if you need some feedback somewhere

[extrawurst]

here is an issue when you want to discard a hunk in a renamed file:

image

this will error-close with:

Error: `hunk not found`

if thats nothing we can easily fix before we merge we can disable hunk based commands on entries with renamed-status

[extrawurst]

here is an issue with line-staging:

image

leads to:

as with above hunk error we can workaround this (if we don't wanna fix it now) by not allowing line based staging on renamed entries.

[Mifom]

@extrawurst sorry for this long period without work on this PR.

There are no good way for discarding hunks in renamed files at the moment, so this was disabled.

About line staging: it works at least for the changes i made. Maybe there are cases where it will not work, so i'll check that.

About renamed folder staging: at the moment when user mark folder as staged it passes to staging on the side of git2, so we haven't control this. That's should be reimplemented in gitui side to accurately remove them and not only add new files.

[extrawurst]

@Mifom can you bring the branch up to date with master, so it could in theory be merged?

[Mifom]

@Mifom can you bring the branch up to date with master, so it could in theory be merged?

Now it's up to date

[Mifom]

@extrawurst the branch is now up to date
In the comment above I explain status of all issues with this PR. If you have ideas how to surpass them I can implement them or we can open new issue for them where they will be resolved.

[extrawurst]

Thanks for sticking with this! 🥳

[extrawurst]

I think I have to revert this. after the merge no return on any file in the file list works anymore to stage the whole file

[extrawurst]

ok damn I don't get the changes made to index_add_remove now that I try to debug this. you seem to sync::reset_stage anything that was just staged in the same function. sorry I did not catch this before the merge. I will revert the change. feel free to reopen the PR

[extrawurst]

@Mifom let me know if you need help figuring this out.