Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

handlerug
Copy link
Contributor

Match git's behavior. This improves compatibility with alternative Git client programs such as Sublime Merge.

Match git's behavior. This improves compatibility with alternative Git
client programs such as Sublime Merge.
@handlerug
Copy link
Contributor Author

The "cargo-deny-advisories" failure doesn't seem to be related to my changes.

@EliahKagan
Copy link
Member

The "cargo-deny-advisories" failure doesn't seem to be related to my changes.

Yes, it is unrelated. That failure is due to RUSTSEC-2025-0047. It has since been fixed in #2112 by updating the affected dependency.

Copy link
Member

@Byron Byron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot! What an oversight on my part as well.

I did validate that, as suspected, Git does write newlines into its files just as it's Linux/Unix standard.

Merging despite failure as the advisory is already fixed.

@Byron Byron merged commit edcfdc2 into GitoxideLabs:main Aug 13, 2025
22 of 23 checks passed
@Byron Byron mentioned this pull request Aug 13, 2025
2 tasks
@Byron
Copy link
Member

Byron commented Aug 13, 2025

A patch-release of gix-ref has just been created.

EliahKagan added a commit to EliahKagan/gitoxide that referenced this pull request Aug 13, 2025
This adds regression testing for the fix in 6c0cc71 (GitoxideLabs#2111).

The `packed_refs_are_looked_up_when_checking_existing_values` test
case had already asserted that the updated ref is loose and parses
as the correct OID. This extends that case with another assertion
that the stored file's exact contents are the hex OID followed by
a newline.

The added assertion checks the OID, and not just that the file
ends with a newline character, partly so that if it somehow opened
the wrong file then this would be caught, but more importantly so
that it verifies that no extra data beyond this are added. For
example, a loose ref should end with a Unix-style LF line ending
on all systems; by checking its whole content, this verifies that
no CR (`\r`) byte is written even on Windows.

The new assertion was validated by applying it locally at fb78f1e,
where it fails in the expected way:

            FAIL [   0.560s] gix-ref-tests::refs file::transaction::prepare_and_commit::create_or_update::packed_refs_are_looked_up_when_checking_existing_values
      stdout ───

        running 1 test
        test file::transaction::prepare_and_commit::create_or_update::packed_refs_are_looked_up_when_checking_existing_values ... FAILED

        failures:

        failures:
            file::transaction::prepare_and_commit::create_or_update::packed_refs_are_looked_up_when_checking_existing_values

        test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 134 filtered out; finished in 0.52s

      stderr ───

        thread 'file::transaction::prepare_and_commit::create_or_update::packed_refs_are_looked_up_when_checking_existing_values' panicked at gix-ref\tests\refs\file\transaction\prepare_and_commit\create_or_update\mod.rs:758:5:
        assertion `left == right` failed: the loose ref is stored on disk as the full OID followed by a newline
          left: "0000000000000000000000000000000000000001"
         right: "0000000000000000000000000000000000000001\n"
        note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

In contrast, when applied at dc7343c, it passes, due to 6c0cc71.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants