Allow following file renames in commit history activity

[maniac103]

Fixes #1419

[maniac103]

@Fs00 Please review

[Fs00]

This is an interesting feature, although I have a few doubts:

• why would we need an option to enable/disable it? I think it's very easy to miss the existence of the feature if it's disabled by default, and I don't see why a user would want to deliberately ignore older history entries
• I'm not really knowledgeable about RxJava, but what happens if the user rotates the screen while entries belonging to an "older filename" are being displayed? As far as I can see, the RenameFollowData will be lost upon fragment recreation.

Have you considered implementing this functionality with an action at the end of the list that opens the history of the previous filename (if there is one), similarly to what the GitHub web UI does? I think it could spare us dealing with paged lists and their known issues.

[maniac103]

why would we need an option to enable/disable it? I think it's very easy to miss the existence of the feature if it's disabled by default, and I don't see why a user would want to deliberately ignore older history entries

It's not the default behavior for git log either, but needs to be explicitly enabled (git log --follow) there as well.

I'm not really knowledgeable about RxJava, but what happens if the user rotates the screen while entries belonging to an "older filename" are being displayed? As far as I can see, the RenameFollowData will be lost upon fragment recreation.

That's probably right, need to check this. Could likely put it into the saved state.

Have you considered implementing this functionality with an action at the end of the list that opens the history of the previous filename (if there is one), similarly to what the GitHub web UI does?

No, but I consider the current solution more suited because

• it's in line with git log
• the GH UI solution will get 'interesting' with both the fragment and adapter setup (we'd need to insert a dummy item into the list, but how to do that with the paging setup?)

[maniac103]

That's probably right, need to check this. Could likely put it into the saved state.

Tested this now, added saving of members to saved state, should be fine now.

[Fs00]

Great, I'll play with it and take a closer look at the implementation in the next few days 👀

[Fs00]

I've done some tests and in the end I think that the functionality is fine as-is (opt-in without persisting the option in a preference). If it were enabled by default, it would be harder for the user to realize that the file was renamed at some point in the history.
Having a visual indicator on those commits in which the file is renamed (like a "Renamed to X" chip) would address this inconvenience, but I don't feel it's necessary at the moment (could be a future improvement).

While testing I've only found two minor issues (except the known bug #1243):

• after enabling the option and rotating the screen, the "Follow renames" checkbox turns back to being disabled. I guess it's because the state is saved in the fragment but the menu is created in the activity.
  Wouldn't it be better to have the options menu being inflated in the CommitListFragment only when a filePath is provided? That way we wouldn't even need to touch the CommitHistoryActivity.
• following renames for directories does not work, but I believe it's a Git limitation because it doesn't work on the GitHub web UI either. Would it be possible to hide the "Follow renames" option on folders?

I have a few naming suggestions below.

[Fs00]

Renames look good to me, let me know when the two issues are addressed

[maniac103]

let me know when the two issues are addressed

What issues do you mean here?

[Fs00]

I mean the two bullet points in my review above

[maniac103]

I mean the two bullet points in #1443 (review)

Oops, sorry, completely missed those. Fixed both of them.

[Fs00]

Great job! 🎉
If you are going to tag a release soon, please remember to change and rotate the APK signing key otherwise the app cannot be included in the IzzyOnDroid repo.

[maniac103]

please remember to change and rotate the APK signing key

I am aware, but I'm procastinating there because I don't fully understand the details of the process yet and am not sure of the implications, e.g. for how long is this double signing needed - only once?
Do you have experience on that process?

[Fs00]

No, I don't have any experience.

how long is this double signing needed - only once?

That's a good question - my understanding is that it's needed as long as you want to be able to upgrade from an APK signed with an old key, but I couldn't find it explicitly stated anywhere.
However, after a bit of research I've found out that things have become more complicated since Google introduced the APK signature scheme v3.1 in Android 13 to address rotation handling issues in the OS. In short, the default apksigner behavior now involves signing an APK with both the old key (used for Android <= 12L) and the rotated one (for Android 13+), which is quite messy to be honest.

I'm not too sure if rotating the key is worth at this point, considering that many people have likely downloaded the app from F-Droid. The only potentially frustrating thing when reinstalling the app from scratch would be to re-add previous bookmarks...

[xabolcs]

The only potentially frustrating thing when reinstalling the app from scratch would be to re-add previous bookmarks...

How about implementing a nice "export/import OctoDroid settings" feature?

[ShareASmile]

How about implementing a nice "export/import OctoDroid settings" feature?

It needs a dedicated feature request, would you please open one!

..as It would be good for smooth transition of app, specially useful when a user have a large no. of bookmarks. Also handy to users
switching to a different device carrying over bookmarks nicely with them.

[ponthamaya]

Please release the apk

[Fs00]

I see that there is already #948 for requesting the import/export bookmarks functionality, I think that one is enough. Imho I don't see much value in a settings backup feature considering the limited number of options the app has.

Btw @maniac103 if the signing key rotation ends up being too complex to handle, feel free to release without changing the key.

[ShareASmile]

I see that there is already #948 for requesting the import/export bookmarks functionality, I think that one is enough.

Fair point, but then #948 issue should be edited to reflect import in its title as well as in its body. OP didn't clarified the putpose, it vaguely requests for export to be saved somewhere.

I don't see much value in a settings backup feature considering the limited number of options the app has.

Agree with it.

How about implementing a nice "export/import OctoDroid settings" feature?

Sorry i somehow did miss the "settings" word 🫣 while replying as importing "bookmarks" were all over my head 😄. I do have more than hundred of them in old device, waiting to be imported into new one.

It would be awesome if import export feature is considred to be included in the upcoming release, but if it takes time then it should not be a blocker for next release. After all it is an open source project, so no pressure, I know developers do it for free from their precious time for the community, so kudos to them. Happy Coding.