On Mon, Jun 23, 2025, at 9:05 PM, 田玉桐 wrote:
I am tianyutong, responsible for the project heterogeneous-distributed-training-framework.(cfn/heterogeneous-distributed-training-framework: Heterogeneous distributed training framework researches the training method and framework over heterogeneous hardware. - heterogeneous-distributed-training-framework - OpenDev: Free Software Needs Free Tools <https://opendev.org/cfn/heterogeneous-distributed-training-framework/>)
I attempted to overwrite the previous commits on the following branches: master, release_1.0.0, and core_0.8.0. However, due to merge conflicts, the commit history became corrupted, and the format is now incorrect.
Looking at the commit history the repo itself seems to be ok. So things are not corrupted in such a way that breaks repo operations: https://opendev.org/cfn/heterogeneous-distributed-training-framework/commits.... Looking at the commits I think the problem is that merge conflict markers were not properly resolved in commits that were merged to the repo. I just want to clarify here that the git repo is fine. The concern is with the contents not being correct.
I need assistance in clearing all the previous commits and starting fresh. I would like to push new commits without keeping any of the previous history.
Assuming my interpretation above is correct the easiest solution is likely going to be reverting each of the commits that contain incorrect data (use `git revert`). Then move forward again with new commits. This will not delete or reset any of the history but gives a clear understanding that those commits were bad and reverted then you started again and moved forward in a new direction. Keep in mind that one of the benefits of using Gerrit for code review is that you should be able to catch problems like this before they become part of your git repo commit history.
Could you please guide me on how to remove the old commits and push the new changes?
In general we try to avoid properly deleting things. Doing so has downstream effects where users have to hard reset their git repos and can end up in a confusing place when the upstream repo history is no longer in sync with their local copies. Will the process I proposed above performing reverts of the bad data then rolling forward again work for you?
Best regards,
tianyutong