feat: overwrite git attrs with dirty status by tisonkun · Pull Request #199 · korandoru/hawkeye

tisonkun · 2026-01-09T15:16:19Z

This closes #197.

Then you should be able to use:

@@ -1 +1 @@
- inlineHeader = """Copyright © {{attrs.git_file_created_year if attrs.git_file_created_year else attrs.disk_file_created_year}}-{{attrs.git_file_modified_year if attrs.git_file_modified_year else attrs.disk_file_created_year}}."""
+ inlineHeader = """Copyright © {{attrs.git_file_created_year if attrs.git_file_created_year else attrs.disk_file_created_year}}-{{attrs.git_file_modified_year if attrs.git_file_modified_year else attrs.disk_file_modified_year}}."""

Signed-off-by: tison <wander4096@gmail.com>

Lorilatschki · 2026-01-09T15:37:17Z

The question is, in the mentioned usecase, where the file is locally changed, the attrs.git_file_modified_year exist, so the attrs.disk_file_modified_year will not be used, right?

tisonkun · 2026-01-09T15:39:10Z

That's correct. Do you logically want a max(attrs.git_file_modified_year, attrs.disk_file_modified_year)?

I think we can implement it with minijinja, whether it's an upstream function or we can register one.

Signed-off-by: tison <wander4096@gmail.com>

tisonkun · 2026-01-09T16:01:07Z

@@ -1 +1,2 @@
-Copyright {{attrs.git_file_created_year if attrs.git_file_created_year else attrs.disk_file_created_year }}
+Copyright {{attrs.git_file_created_year if attrs.git_file_created_year else attrs.disk_file_created_year }}
+Modified {{[attrs.git_modified_year, attrs.disk_file_modified_year] | max}}


If max is what you need, you can try out this example.

Ref - https://docs.rs/minijinja/latest/minijinja/filters/fn.max.html

Sounds as it could work. Will try it later and give you feedback.

Emm .. I think it may not work because all mtime locally would be the very late time after you clone the files.

So for a new cloned local copy, it would be then all "this year".

Let me think of it. The requirement is to track all modified files by VCS, but use the mtime from the local FS.

I need some time to consider what is the proper filter and extract way.

Perhaps patching git::resolve_file_attrs to add an attrs.git_dirty_file_modified_year, and then:

{{ attrs.git_dirty_file_modified_year if attrs.git_dirty_file_modified_year else attrs.git_file_modified_year }}

I think that would fit. So in case the file is not changed locally, attrs.git_dirty_file_modified_year will not be set. In case it is changed locally, it will get the current year.

Signed-off-by: tison <wander4096@gmail.com>

tisonkun · 2026-01-09T17:31:29Z

@Lorilatschki updated.

I finally chose a different approach - just override the attrs.git_file_created_year and attrs.git_file_modified_year attributes as if the dirty file were committed. This should always be what users want.

Signed-off-by: tison <wander4096@gmail.com>

tisonkun · 2026-01-09T17:35:56Z

+    // process dirty working tree
+    let status_platform = repo.status(gix::progress::Discard)?;
+    let status_iter = status_platform.into_index_worktree_iter(None)?;
+    let now = gix::date::Time::now_local_or_utc();
+    for item in status_iter {
+        let item = item.context("failed to check git status item")?;
+        let rel_path = item.rela_path();
+        update_attrs(rel_path, now, current_username.as_str());
    }


TIL for implementing #199 (comment).

cc @Byron in case this is not the best practice.

There also is status_platform.into_iter() (or something more general) to get the changes that were added to .git/index as well. The current version doesn't get all changes git status would show.

Otherwise this would be the way the paths of changed items.

Thanks for your explaination!

I can see the alternative method returns an extra TreeIndex result. But I'm always using linear commit history, so I'm not quite familiar with the difference. Is there some reference I can use to understand what those extra indices are?

I don't follow, but think that something like this would do the trick: https://github.com/GitoxideLabs/gitoxide/blob/657dec4f10bc6babbfa71a4506b1ff1439c06eaf/gix/tests/gix/status.rs#L213-L241

Thanks! IIUC it means into_iter would properly include those file changed after git add . while into_index_worktree_iter only includes those files changed but yet to be added (in the working tree, not in the index).

Yes, that's it.

tisonkun · 2026-01-09T17:36:33Z

+    let current_username = match repo.committer() {
+        Some(Ok(username)) => username.name.to_string(),
+        _ => "<unknown>".to_string(),
+    };


cc @Byron ditto preparing the "default author" for dirty changes.

You can do it like this and it's probably easiest as well, as long as you don't find yourself duplicating the logic to deal with an unset committer. In that case, fallbacks for missing committers can be set upon opening the Gix repository.

Lorilatschki · 2026-01-09T19:12:26Z

So if I understand it correctly, this will fix the behavior without any adaption on our site except the new version which contains this change, right?

tisonkun · 2026-01-09T19:15:48Z

So if I understand it correctly, this will fix the behavior without any adaption on our site except the new version which contains this change, right?

Yes. You can test it with cargo install --path path-to-hawkeye for testing locally.

Lorilatschki · 2026-01-09T19:49:37Z

So if I understand it correctly, this will fix the behavior without any adaption on our site except the new version which contains this change, right?

Yes. You can test it with cargo install --path path-to-hawkeye for testing locally.

Will test it locally and give you feedback if it works. In any case, we should add a test to verify that the 2 attributes behave as expected in case the are change locally.

Lorilatschki · 2026-01-09T21:53:37Z

Have tested both scenarios with the local installation of your branch support-disk_file_modified_year.

Adding a new file and running hawkeye format creates 2026-2026 as expected
Changing an existing file with the header 2024-2025 and running hawkeye format creates 2024-2026 as expected.

tisonkun · 2026-01-09T23:47:18Z

Thank you. I tested it locally as well.

I'm going to refactor the integration tests with trycmd instead of Python script then add more test cases.

tisonkun added 3 commits January 9, 2026 23:03

feat: support attrs.disk_file_modified_year

7785a2a

Signed-off-by: tison <wander4096@gmail.com>

better docs

1427cf1

Signed-off-by: tison <wander4096@gmail.com>

tidy

5425f10

Signed-off-by: tison <wander4096@gmail.com>

fixup

ad4e7a2

Signed-off-by: tison <wander4096@gmail.com>

tisonkun commented Jan 9, 2026

View reviewed changes

tisonkun added 3 commits January 10, 2026 00:53

reduce native call

dccbf2d

Signed-off-by: tison <wander4096@gmail.com>

use dirty time

8df3d8d

Signed-off-by: tison <wander4096@gmail.com>

reimpl gix logics

60174d7

Signed-off-by: tison <wander4096@gmail.com>

docs

a53930a

Signed-off-by: tison <wander4096@gmail.com>

tisonkun commented Jan 9, 2026

View reviewed changes

tisonkun merged commit fc27a4a into main Jan 9, 2026
17 checks passed

tisonkun deleted the support-disk_file_modified_year branch January 9, 2026 23:48

tisonkun changed the title ~~feat: support attrs.disk_file_modified_year~~ feat: overwrite git attrs with dirty status Jan 9, 2026

tisonkun mentioned this pull request Jan 12, 2026

chore: properly handle files after git add #201

Merged

Uh oh!

Uh oh!

Conversation

tisonkun commented Jan 9, 2026

Uh oh!

Lorilatschki commented Jan 9, 2026

Uh oh!

tisonkun commented Jan 9, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tisonkun commented Jan 9, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Lorilatschki commented Jan 9, 2026

Uh oh!

tisonkun commented Jan 9, 2026

Uh oh!

Lorilatschki commented Jan 9, 2026

Uh oh!

Lorilatschki commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tisonkun commented Jan 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Lorilatschki commented Jan 9, 2026 •

edited

Loading