Display both local and remote git SHA versions in system banner

[Copilot]

The system banner was displaying an ambiguous SHA version without clarifying whether it was the local or remote version, causing confusion for users trying to understand their system state.

Before:

=== System Information ===
Version: efa1b8e (master)
Last commit: 2025-08-18 22:43:11
Last update: 2025-08-18 22:48:08

After:

=== System Information ===
Local version: efa1b8e (master)
Remote version: efa1b8e (master)
Last commit: 2025-08-18 22:43:11
Last update: 2025-08-18 22:48:08

Changes Made

• Modified get_version_info() function in bin/common/utils.sh to fetch and display both local and remote SHA versions
• Added proper error handling to gracefully show "unknown" for remote version when git fetch fails or remote is unavailable
• Maintained backward compatibility while providing clearer version information

The implementation uses the same pattern as the existing check_for_updates() function, fetching remote information quietly and handling errors gracefully. This provides users with a clear understanding of both their local state and the available remote state.

Fixes #138.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

---

PR Type

Enhancement

---

Description

• Display both local and remote git SHA versions in system banner

• Replace ambiguous single SHA with clearly labeled local/remote versions

• Add error handling for remote version fetch failures

• Improve version information clarity for users

---

Changes walkthrough 📝

Relevant files

Enhancement

utils.sh Enhanced version display with local and remote SHA              bin/common/utils.sh Modified get_version_info() function to fetch and display both local and remote SHA versions Added git fetch operation to retrieve remote version information Implemented error handling to show "unknown" when remote fetch fails Changed output format from single "Version:" to separate "Local version:" and "Remote version:" labels +9/-2

---

Need help?

Type /help how to ... in the comments thread for any questions about PR-Agent usage.

Check out the documentation for more information.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

_{You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.}

[sparkfabrik-ai-bot]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis ✅ 138 - Fully compliant Compliant requirements: • Print both local and remote git SHA versions in the system banner • Clarify which SHA is local vs remote to avoid confusion • Replace the current ambiguous single SHA display with clearly labeled versions

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Network Dependency The function now performs a git fetch operation which introduces a network dependency and potential delay in banner display. Consider if this is acceptable for system startup or if caching/async approach would be better. if git fetch origin "${current_branch}" -q 2>/dev/null; then remote_version=$(git rev-parse --short "origin/${current_branch}" 2>/dev/null || echo "unknown") fi Error Handling The remote version fallback to "unknown" may not provide clear feedback to users about why remote information is unavailable. Consider more descriptive error messages. local remote_version="unknown" if git fetch origin "${current_branch}" -q 2>/dev/null; then remote_version=$(git rev-parse --short "origin/${current_branch}" 2>/dev/null || echo "unknown") fi

[sparkfabrik-ai-bot]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Restore original working directory The function changes directory to /opt/sparkdock but doesn't restore the original directory afterward. This could cause unexpected behavior for calling scripts. bin/common/utils.sh [68-72] # Get remote version (fetch quietly to get latest remote info) local remote_version="unknown" +local original_dir=$(pwd) if git fetch origin "${current_branch}" -q 2>/dev/null; then remote_version=$(git rev-parse --short "origin/${current_branch}" 2>/dev/null || echo "unknown") fi +cd "${original_dir}" Suggestion importance[1-10]: 7 __ Why: This addresses a legitimate issue where the function changes to /opt/sparkdock at line 63 but never restores the original directory, which could cause problems for calling scripts. However, the improved_code places the directory restoration in the wrong location within the suggested code block.	Medium
	Add remote branch validation The git fetch operation could fail silently and leave stale remote information. Consider adding error handling to distinguish between network failures and missing remote branches. bin/common/utils.sh [70-72] -if git fetch origin "${current_branch}" -q 2>/dev/null; then +if git ls-remote --exit-code origin "${current_branch}" >/dev/null 2>&1; then + git fetch origin "${current_branch}" -q 2>/dev/null remote_version=$(git rev-parse --short "origin/${current_branch}" 2>/dev/null || echo "unknown") fi Suggestion importance[1-10]: 5 __ Why: The suggestion improves error handling by checking if the remote branch exists before fetching, which is a reasonable enhancement. However, the current code already handles failures gracefully with the || echo "unknown" fallback.	Low