|
| 1 | +# Product Requirements Document: Date-Based Search in GitContentSearch |
| 2 | + |
| 3 | +## 1. Introduction |
| 4 | + |
| 5 | +This document outlines the requirements for adding date-based search functionality to GitContentSearch. Currently, the tool allows searching for a string within a file's history between two specified commit SHAs. This enhancement will enable users to search between two dates, making it more intuitive and user-friendly. |
| 6 | + |
| 7 | +## 2. How It Works |
| 8 | + |
| 9 | +The date-based search functionality will be implemented as follows: |
| 10 | + |
| 11 | +1. **Date to Commit Mapping:** |
| 12 | + * GitContentSearch will use the `git log` command to identify commits within the specified date range. |
| 13 | + * The command `git log --since="start-date" --until="end-date" --pretty=%H` will be executed to retrieve a list of commit SHAs. |
| 14 | + * `--since`: Specifies the start date. |
| 15 | + * `--until`: Specifies the end date. |
| 16 | + * `--pretty=%H`: Formats the output to only include the commit SHA. |
| 17 | + * Supported date formats include `YYYY-MM-DD` (e.g., `2023-01-01`) and relative dates (e.g., `2.weeks.ago`). |
| 18 | + * The earliest commit after `--since` will be considered the "earliest commit". |
| 19 | + * The latest commit before `--until` will be considered the "latest commit". |
| 20 | + |
| 21 | +2. **Binary Search:** Once the earliest and latest commits are determined, the existing binary search algorithm will be used to find the commit where the search string was introduced. |
| 22 | + |
| 23 | +## 3. User Interface (UI) Changes |
| 24 | + |
| 25 | +* **Input Fields:** |
| 26 | + * Replace the existing "Earliest Commit" and "Latest Commit" input fields with "Start Date" and "End Date" fields. |
| 27 | +* **Date Picker:** |
| 28 | + * Utilize a date picker widget (e.g., from AvaloniaUI or a similar cross-platform framework) to provide a user-friendly date selection experience. |
| 29 | +* **Validation:** |
| 30 | + * Implement input validation to ensure: |
| 31 | + * The start date is before the end date. |
| 32 | + * Both dates are in a valid format (e.g., `YYYY-MM-DD`). |
| 33 | + * Dates are not in the future. |
| 34 | + |
| 35 | +## 4. Command-Line Interface (CLI) Changes |
| 36 | + |
| 37 | +* **Backward Compatibility:** |
| 38 | + * Retain the existing `--earliest-commit` and `--latest-commit` options for backward compatibility. |
| 39 | +* **New Date Options:** |
| 40 | + * Introduce new optional arguments: |
| 41 | + * `--start-date`: Specifies the start date for the search. |
| 42 | + * `--end-date`: Specifies the end date for the search. |
| 43 | +* **Example Command:** |
| 44 | + ```bash |
| 45 | + GitContentSearch.exe "path/to/your/file.xlsx" "SearchString" --start-date="2023-01-01" --end-date="2023-12-31" --working-directory="/your/git/repo" --log-directory="/your/log/directory" --follow |
| 46 | + ``` |
| 47 | +* **Option Priority:** |
| 48 | + * If both commit-based (`--earliest-commit`, `--latest-commit`) and date-based (`--start-date`, `--end-date`) options are provided, prioritize commit-based options. Log a warning message indicating this prioritization. |
| 49 | + |
| 50 | +## 5. Edge Case Handling |
| 51 | + |
| 52 | +* **No Commits in Range:** |
| 53 | + * If no commits are found within the specified date range, display a clear and informative error message to the user. Example: "No commits found between 2023-01-01 and 2023-12-31". |
| 54 | +* **Time Zones:** |
| 55 | + * Consistently use UTC (Git's default behavior) for date and time comparisons. |
| 56 | + * Include a note in both the UI and CLI documentation clarifying the time zone handling (UTC). |
| 57 | +* **Invalid Dates:** |
| 58 | + * Implement robust date validation to prevent errors. This includes: |
| 59 | + * Rejecting dates in the future. |
| 60 | + * Ensuring the date format is correct (e.g., `YYYY-MM-DD`). |
| 61 | + * Handling invalid date inputs gracefully (e.g., February 30th). |
0 commit comments