View log/history of a file

[jarod]

Is your feature request related to a problem? Please describe.
As what gitk <filename> do. You can view commit logs of the file specified. Then select one of the logs to view changes made to the file in that commit.

Describe the solution you'd like
not serious thoughts:

• on launch: gitui <filename>
• on any file list view add a [file log] command which go to log tab view logs filtered by the selected file

any file list view above include but not limit to:

• tab [Status] -> Unstaged Changes and Staged Changes window
• tab [Log] -> Files window when view a commit log
• tab [Stashing]
• tab [Stashes]

Additional context
gitk Cargo.toml on ripgrep repo:

[extrawurst]

file history is a feature I definitely want to support down the line!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tpo]

I'd like to add that it'd be nice if gitui had a file browser view/tab which would tell me which files/dirs are committed, staged, dirty (there's a diff), (... have merge conflicts), where I can press a key and see the diff, the history, blame, etc.

Ah, it's not hard to be wanting things ... :-)

Thanks for gitui!

[extrawurst]

@tpo I am not sure how the current Status-tab is not providing you a way to see what is staged or dirty? the rest is not covered yet, that's true.

[tpo]

Hi @extrawurst

I am not sure how the current Status-tab is not providing you a way to see what is staged or dirty?

Yes it is. However what I am missing is a view that is first and foremost file based. Not based in the first place on whether something is dirty or staged.

That said - this is my first impression: my first reaction when starting gitui was "uuuhm, where are my files?" and I instantly started searching whether there's a tab or keystroke that would bring the respective view up.

[extrawurst]

@tpo I agree such a tab would have some use, but considering my most used git GUIs none of them focuses on such a view as a primary one. almost all (lazygit, tig, fork) focus on either uncommitte changes or revlog. dunno about tig/lazygit but in fork a file-tree is only accessible via a specific commit.

long story short, such a file tree has no super high priority for me personally right now.

[laktak]

While I agree that it's not the most important feature it would be nice to select a path and do a git log on it.

[extrawurst]

While I agree that it's not the most important feature it would be nice to select a path and do a git log on it.

Getting a file history as requested by @jarod is on the 1.0 roadmap. PRs welcomed :)

gitui will not call the git cli though. so this has to be done using libgit2 like everything else here is

[cruessler]

@extrawurst Can you tell me how this relates to #429 and #449? Are both features supposed to be separate? If they are, I would start working on the file log.

[extrawurst]

@extrawurst Can you tell me how this relates to #429 and #449? Are both features supposed to be separate? If they are, I would start working on the file log.

I do not see any relation between those two and this one 🤔. for this I envision something similar to blame where you can always trigger a File History on a single file item and then it opens up a list of all revisions that impacted that file just like fork and co do it:

let me know if I am missing something :)

[extrawurst]

@cruessler note that the beefy task here is to build the asyncgit feature that powers the file-history gathering.

this will likely involve doing an entire revwalk down to the commit that introduced/created the file. this has to support doing this as a thread job again. please check out the newly added AsyncJob abstraction (we use it only for the SyntaxHighlighting so far) but it makes a lot of what we had to copy/paste before generic.

If we wanna do nice small manageable iterations I'd suggest these three steps:

1. add new asyncgit::sync::file_history that does the bare work using rev walk (similar to what we did for the log)
2. wrap this into the new AsyncJob abstraction
3. build the "UI" and integrate the new elements into gitui-crate itself

Bonus: If we revwalk a giant repo it would be nice to know a progress percentage while waiting for the file history to be gathered.

Let me know what you think!

[cruessler]

@extrawurst That sounds like a good idea to me! I’ll open a PR as soon as the first part is done.

[cruessler]

@extrawurst I just saw that you re-factored LogWalker and I thought, looking at the code, that this is almost exactly what I would need for a FileLogWalker. What do you think about adding a parameter to LogWalker::new, something like options: Option<LogWalkerOptions> with LogWalkerOptions { filter: … }? Or do you see other, and possibly better opportunities for code reuse?

[extrawurst]

@cruessler yeah lets extend LogWalker to apply an optional filter before pushing an id to the result. instead of adding this as a param to new I'd suggest making the filter an Option and set to None by default.
then we can add a fn filter(self, filter:...) -> Self that sets the filter, this way we can use it sort of like a Builder where needed

[extrawurst]

@cruessler if you need more inspiration for this, there is a libgit2 based implementation here: libgit2/libgit2sharp#963

[extrawurst]

@cruessler any progress on this?

[cruessler]

Yes, I’ve started working on the remaining functionality and will hopefully be able to present an update this weekend.

[cruessler]

@extrawurst It took longer than expected, but today I got a first version working. There are still a few rough edges, but I might be able to open a draft PR this weekend!

[extrawurst]

@extrawurst It took longer than expected, but today I got a first version working. There are still a few rough edges, but I might be able to open a draft PR this weekend!

that sounds great, looking forward to see it in action