| champo | |
| Feb 19 2015, 9:34 PM |
| F309962: Screen_Shot_2015-02-19_at_18.30.44_(2).png | |
| Feb 19 2015, 9:34 PM |
| F309960: Screen_Shot_2015-02-19_at_18.31.27_(2).png | |
| Feb 19 2015, 9:34 PM |
I pushed an empty commit after landing a revision. I have a herald rule on commits without a revision that should've triggered, when it didn't I checked the transcript and found that diffusion thinks the empty commit has the same revision as the parent commit.
Commit in Diffusion
Herald Transcript
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | epriestley | T13290 Clean up remaining "Autoclose" behaviors related to "One Revision, Many Commits" | ||
| Open | None | T7333 Empty commits get same revision as parent |
The commit in the photo has a revision on it. It that the bug you're reporting? I just want to make sure I understand the steps to reproduce, and it doesn't seem like Herald should be involved in the report.
Yeah, that's the bug I'm reporting actually. Sorry, it's been a long day
and I didn't see the revision in the commit in diffusion.
I'm really sure the commit shouldn't have a revision though.
I don't think I even know how to push an empty commit. Assume this is the steps to reproduce?
git checkout branch arc land git commit --allow-empty -m "<your message here>" git push
Is that about right?
I think this is sort-of related to T4453 and the issue discussed in T3686. Specifically, one of the ways we match commits to revisions is by comparing their tree hashes.
If you revert a commit, or make an empty commit, you get two commits with the same tree hash. Presumably D9804 is associated with the commit immediately prior to this one?
In this case, we could special case and never associate empty commits by tree hash, although identifying empty commits may not be straightforward at association time.
Yeah, thats exactly it. I only have one or two repos where empty commits can exist, so I can work around it. Shouldn't be much trouble.
Specifically: empty commits and commits which strictly undo some of the work on a branch (e.g., revert HEAD, or revert HEAD + the prior commit, etc) produce a new commit with the same tree hash as an older commit.
We then incorrectly associate the new commit with the old commit's revision because the revision is associated with the tree hash.