fix: parse multi-hunk diffs in Gitea provider

[nnhattruong30]

User description

Gitea Problem: pr-agent only scanned from the last @@ hunk to the end of the file, missing earlier hunks in multi-hunk diffs.

---

PR Type

Bug fix

---

Description

• Fix multi-hunk diff parsing in Gitea provider

• Only initialize patch on first @@ hunk marker

• Prevents overwriting earlier hunks in diffs

---

Diagram Walkthrough

flowchart LR
  A["Parse diff lines"] --> B["Encounter @@ marker"]
  B --> C{"current_patch empty?"}
  C -->|Yes| D["Initialize current_patch"]
  C -->|No| E["Append to current_patch"]
  D --> F["Collect all hunks"]
  E --> F

Loading

File Walkthrough

	Relevant files
Bug fix	gitea_provider.py Add empty check to hunk initialization logic                          pr_agent/git_providers/gitea_provider.py Modified condition for @@ hunk marker detection Added check to only initialize current_patch when empty Prevents resetting patch on subsequent @@ markers Ensures all hunks in multi-hunk diffs are captured +1/-1

---

[qodo-free-for-open-source-projects]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Consistent Naming Conventions Objective: All new variables, functions, and classes must follow the project's established naming standards Status: Passed
	No Dead or Commented-Out Code Objective: Keep the codebase clean by ensuring all submitted code is active and necessary Status: Passed
	Robust Error Handling Objective: Ensure potential errors and edge cases are anticipated and handled gracefully throughout the code Status: Passed
	Single Responsibility for Functions Objective: Each function should have a single, well-defined responsibility Status: Passed
	When relevant, utilize early return Objective: In a code snippet containing multiple logic conditions (such as 'if-else'), prefer an early return on edge cases than deep nesting Status: Passed

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-free-for-open-source-projects]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Learned best practice	Preserve exception chain for debugging The exception is already properly captured with 'as e' syntax and used in the error logging. However, consider using 'raise ... from e' to preserve the exception chain for better debugging context. pr_agent/git_providers/gitea_provider.py [150-151] except Exception as e: self.logger.error(f"Error getting diff content: {str(e)}") + raise [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 6 __ Why: Relevant best practice - When catching exceptions in try-except blocks, always capture the exception object using 'as e' syntax to enable proper error logging and debugging. This prevents NameError when trying to reference the exception in the except block.	Low
More

• Author self-review: I have reviewed the PR code suggestions, and addressed the relevant ones.