Hi! Just passing by and wondering if this is lazy loading or not? If a file has a history that is too large (old repos like Linux or Firefox), it might slow down the UI.

Thanks for getting involved! Summarizing the things we went over in our call
together:

Three high level pieces of feedback:

• The design/UI side of things will need input from our designer. I'll get in
  touch with him and see what he thinks, and we can go over the design
  together once we have his feedback
• We should stream results in chunks. The -n and --skip CLI arguments to
  git log make this pretty straightforward
• We should support remote (SSH/WSL/etc.) repositories

When it comes to implementing remote, the git show command is a similar
command that already has all this plumbing:

• You've already got the protobuf definitions done
• You'll need to add code to handle the protobuf request in the remote server
  application (the headless Zed instance that runs on the remote machine).
  You can do this by creating a function in
  crates/project/src/git_store.rs, similar to GitStore::handle_show. Take
  a look at GitStore::init to see how that function is plumbed into the
  app.
• You can also remove the anyhow!() in fn file_history in the remote
  branch and again copy what git show does (create the
  proto::GitFileHistory, send it to the client, and parse the
  proto::GitFileHistoryResponse)

A few smaller tweaks:

• using a string like <<commit_end-(random UUID)>> (using an actual random
  UUID) will essentially eliminate any chance of encountering that string in
  an actual diff. Splitting it up with concat!() will also mean that we
  don't encounter that exact string in this file, which is a small
  quality-of-life feature for Zed maintainers
• We can use std::str::from_utf8 instead of String::from_utf8_lossy to
  avoid copying potentially large strings, and we can simply use ? to skip
  invalid UTF-8 strings, since git will automatically convert non-UTF-8
  strings in most cases anyways.

Thanks again for looking into this, excited to use it myself 😅. Feel free to
ping me if you have any questions!

Hi @cameron1024

I made some updates can you check it out?

Thanks!

@cameron1024 thanks for feedbacks, I learned so much from this PR 😅

@cameron1024 sorry for bothering, but I wanted to ask if there are any updates about this PR, both regarding the design approach and the code fixes?

Just got these from our designer - I think these designs should be able to reuse a bunch of the existing UI components, but let me know if you run into trouble! And I think on the lazy-loading issue, for now we can go with just a "load more" button. Don't have designs for that, but shouldn't be too hard to come up with something reasonable.

thanks a lot!!! @cameron1024

@cameron1024 for commit view code part I wanna ask maybe we can use existing Editor to show code which I guess is better for understanding code totally. What do you think? I can share a video with you if you want

@cameron1024 what do design team thinks about these

That's looking really good! I'll take a look at the code and do a quick review for any issues.

We're in a weird position right now, because there are quite a few Git UI features in progress (e.g. git graph) and I think we'd like to make sure they're consistent. We're going to be discussing how we can make this straightforward for everyone either today or tomorrow, and I'll let you know as soon as I have more info. Apologies again for the delay 😅 Excited to get this into people's hands!

@ddoemonn : Personally, I think it's best to put two lines above and below to separate the profile picture and name from the commit message.

See image below.

If there are multiple authors, is it possible to display them?

@cameron1024 : What do you think?

I think both designs are useful in different contexts.

My personal view is: the two-line view is more helpful when exploring a history you're not familiar with, but the one-line view is better when you're just trying to find a specific commit you wrote a few days ago. I'd personally love for both designs to be supported, with a way to toggle quickly between the "compact" and "expanded" views, but I'll need to see what people on the team think. There may be issues with this approach I haven't thought of yet...

Even if people like the idea, we may prefer to ship what we have, and add the toggle in a later PR 🤷 I'll hopefully have more info later today or tomorrow

@cameron1024 No worries! Take your time with the review.

Makes sense about waiting for the git graph and other features, consistency across the UI is important. Looking forward to hearing what you all decide.

I pushed the code that generates the design we discussed.

Note: for the remote handling, I implemented what I thought made the most sense, but I'm definitely open to reviews and guidance on that part if you have different ideas.

@cameron1024 the PR is ready to review!

@cameron1024 It was such a pleasure working on this! Really happy we're shipping it 🚀

This is a great feature, thank you @ddoemonn and @cameron1024. On the one hand it is nice that commits' diffs are filtered to just that file's history, but it would be great to have an easy way to switch between viewing just that file's history and the diff for the entire commit. Perhaps the commit hash could be turned into a link that shows the entire commit? Or a dedicated button for this?

Can you add a history to compare with the current one?