"Update with rebase" results in wrong commits reported as 'new' #112690
Replies: 1 comment
-
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Question
Body
With reference to Genivia/ugrep#370 (commits)
Near the end of a lengthy PR review, I rebased my PR and inserted two new commits:
drok added 2 commits 35 minutes ago:
Correct/Expected Behaviour
The following two commits should have been shown as "note-worthy" or "new' commits:
Wrong Behaviour
The PR activity feed lists two commits added, but it shows the wrong commits as "note-worthy":
The PR includes several commits that have been rewritten (new SHAs), but their dates and commit message/author/committer remained unchanged. It's pretty neat the GH was able to detect they are uninteresting, as only their SHA changed, and not pollute the feed.
Just to be clear: I know it's not cool to rebase and push, but this is a PR and is expected to be modified as part of review. When finally committed, there should be a neat, clean, finalized list of commits in the history, so IMO it's appropriate to force push. The point of this post is not pushing best practices, but the fact that the UI almost did the smart thing and almost correctly listed the two interesting commits that should have been spot-lit.
Beta Was this translation helpful? Give feedback.
All reactions