feat: support blame annotation for contents / worktree

[Havunen]

Summary 💡

AI ANALYSIS OF MY ISSUE ( sorry I'm writing this in hurry )

Root cause (confirmed): This isn't a rendering glitch — the annotation panel is intentionally suppressed for working-tree diffs. In
crates/gitcomet-ui-gpui/src/view/panes/main/core_impl.rs:704, blame_path_rev_for_target() returns None for DiffTarget::WorkingTree, which makes
both annotation_active() (panel visibility, line 2853) and request_blame_for_current_target() (data load, line 2899) short-circuit. A documented
comment explains why: the annotation column maps blame lines onto new-side line numbers 1:1 (blame_for_new_line, blame.rs:30), but for
working-tree diffs the new side is uncommitted content, so indexing committed (HEAD) blame by those line numbers misattributes every line below
an uncommitted edit.

The real constraint: gix 0.84's blame_file can only blame committed content (suspect:) — there's no --contents/worktree-blame support. I
confirmed the diff bases too: unstaged = index → worktree, staged = HEAD → index. So in both cases the new side is uncommitted, which is the
crux.

This means simply deleting the guard would produce visibly wrong attributions. There are a few genuinely different ways to do this correctly,
with real tradeoffs — so I need your input before writing the plan.

Motivation 🔦

We are building GitComet and would like to show annotation / blame data when users are viewing unstaged / untracked / staged files.

[Havunen]

possibly related #1619

[cruessler]

You’re right! This is a known implementation in the current implementation of gix-blame. It has not been very high on my todo list so far (I haven’t even added it to the tracking issue you linked to). That is not to say, though, that I won’t try my best to help you implement it in case that’s something you’d like to try. I would also consider tackling it eventually myself in case you’re not interested. At this point, though, there’s already one fairly large PR to gix-blame open (#2457) that touches quite a few areas of the implementation, and I wanted to wait for this PR to be merged before starting to work on other changes. I hope that makes sense!

[Havunen]

Christoph Rüßler (@cruessler) Thanks for the reply.

I'm more than happy if you can implement it. Thanks 🥇

[Byron]

The way I think this can be implemented is to create a new virtual commit as a descendant of the commit that would otherwise be the blame entrypoint. One could probably give it a special hash, like all zeros, to make it easily identifiable.
What makes it virtual is that all objects related to it are stored in memory only (gix::Repository) can do that, and that they will be thrown away afterwards to not accidentally soak up all changed (or even untracked) files during virtual tree creation.

[Havunen]

If I understand correctly that would make following renames easier. However I would like to be able to follow renames for any git repository.

Currently our work around is to fallback to native git client.

 The workaround is blame_worktree_file_impl (line 384 in blame.rs), which falls back to calling    
 the native git CLI:                                                                               
                                                                                                   
 - Unstaged: git -c core.quotePath=false blame --line-porcelain -- <path> — blames the working-    
   tree file directly.                                                                             
 - Staged: git -c core.quotePath=false blame --line-porcelain --contents - -- <path> — feeds the   
   index blob via stdin.                                                                           

[cruessler]

For context: this is the implementation of gix diff file which is already capable of showing staged/unstaged changes. https://github.com/GitoxideLabs/gitoxide/blob/c8fbf295d960fc61b0bd112a6dc2c6a256024ae2/gitoxide-core/src/repository/diff.rs My idea was to try and get some inspiration from there.

[Byron]

Replying to #2666 (comment), Just as a note: This issue isn't about rename tracking in blame, which I don't think it supports just yet. This issue is about being able to show worktree changes in the blame output.

[cruessler]

Two things:

• Rename tracking is supported already (at least, gix-blame accepts rewrites: Option<Rewrites> since 0.3.0). 😀
• A PR for this issue is almost ready, likely to be opened tomorrow.