[GH-ISSUE #501] Lost four days of commits to Komodo stack repo #3373

New Issue

Closed

opened 2026-04-13 14:58:37 -05:00 by GiteaMirror · 14 comments

GiteaMirror commented 2026-04-13 14:58:37 -05:00

Owner

Copy Link

Originally created by @Dinth on GitHub (May 9, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/501

Hi. This is a second time this happened to me, but when it happened for the first time, i thought im just going crazy and havent had GH actions to prove otherwise.

For the last couple of weeks ive been working a lot on moving all my stacks to Komodo (and GH - im new to GH too), optimising them, making them work, etc. This morning, when i logged in to Komodo i have noticed that the recently created stacks, while running in Komodo, have GH compose file showing up as not initialised, while other stacks are failing to be redeployed, due to issues which i was sure i have fixed already. When i logged in to GH, i have noticed that the files which should be created and changes which should be commited to GH in the last few days are really not showing up in the History section of the repo, so i am indeed going crazy:

But, i also have a GH action which is being run on each file changed in each commit, and that one shows something else, im not going crazy after all:

Then i noticed GH activity history, which shows this:

That force push made 11h ago on the screenshot is the first push within 5 days which shows on the repository history (first screenshot), so its somewhere around that when the contents of the GH repository were wiped without a trace. But besides that force push being tagged as a "Force push" (not exactly sure what does it mean, but other pushes by Komodo are not tagged in this way) the details of that force push dont indicate wiping anything:

So my questions i guess are:

1. What happened here, why and how do i prevent this from happening again (it has already happened twice for me)?
2. This is not directly related to Komodo but maybe someone can help - how do i recover the contents of the repo? It really pushed me from a stage where all the stacks were working fine back to the time where nothing was working.

Originally created by @Dinth on GitHub (May 9, 2025). Original GitHub issue: https://github.com/moghtech/komodo/issues/501 Hi. This is a second time this happened to me, but when it happened for the first time, i thought im just going crazy and havent had GH actions to prove otherwise. For the last couple of weeks ive been working a lot on moving all my stacks to Komodo (and GH - im new to GH too), optimising them, making them work, etc. This morning, when i logged in to Komodo i have noticed that the recently created stacks, while running in Komodo, have GH compose file showing up as not initialised, while other stacks are failing to be redeployed, due to issues which i was sure i have fixed already. When i logged in to GH, i have noticed that the files which should be created and changes which should be commited to GH in the last few days are really not showing up in the History section of the repo, so i am indeed going crazy:  But, i also have a GH action which is being run on each file changed in each commit, and that one shows something else, im not going crazy after all:  Then i noticed GH activity history, which shows this:  That force push made 11h ago on the screenshot is the first push within 5 days which shows on the repository history (first screenshot), so its somewhere around that when the contents of the GH repository were wiped without a trace. But besides that force push being tagged as a "Force push" (not exactly sure what does it mean, but other pushes by Komodo are not tagged in this way) the details of that force push dont indicate wiping anything:  So my questions i guess are: 1. What happened here, why and how do i prevent this from happening again (it has already happened twice for me)? 2. This is not directly related to Komodo but maybe someone can help - how do i recover the contents of the repo? It really pushed me from a stage where all the stacks were working fine back to the time where nothing was working.

GiteaMirror closed this issue 2026-04-13 14:58:37 -05:00

GiteaMirror commented 2026-04-13 14:58:38 -05:00

Author

Owner

Copy Link

@Dinth commented on GitHub (May 9, 2025):

Looking at the log file in the repo cache this is it:

7898291c92e77f21b2953f9210b9703a3944cd8d 7898291c92e77f21b2953f9210b9703a3944cd8d komodo [komodo@komo.do](mailto:komodo@komo.do) 1746737772 +0000      checkout: moving from main to main
7898291c92e77f21b2953f9210b9703a3944cd8d 578a0dd6d204778a3cdc415dd4713e22e095c853 komodo [komodo@komo.do](mailto:komodo@komo.do) 1746737773 +0000      pull --rebase --force origin main (start): checkout 578a0dd6d204778a3cdc415dd4713e22e095c853
578a0dd6d204778a3cdc415dd4713e22e095c853 578a0dd6d204778a3cdc415dd4713e22e095c853 komodo [komodo@komo.do](mailto:komodo@komo.do) 1746737773 +0000      pull --rebase --force origin main (finish): returning to refs/heads/main
578a0dd6d204778a3cdc415dd4713e22e095c853 578a0dd6d204778a3cdc415dd4713e22e095c853 komodo [komodo@komo.do](mailto:komodo@komo.do) 1746737791 +0000      checkout: moving from main to main

7898291c92e77f21b2953f9210b9703a3944cd8d is the last commit before loosing data

<!-- gh-comment-id:2866229619 --> @Dinth commented on GitHub (May 9, 2025): Looking at the log file in the repo cache this is it: ``` 7898291c92e77f21b2953f9210b9703a3944cd8d 7898291c92e77f21b2953f9210b9703a3944cd8d komodo [komodo@komo.do](mailto:komodo@komo.do) 1746737772 +0000 checkout: moving from main to main 7898291c92e77f21b2953f9210b9703a3944cd8d 578a0dd6d204778a3cdc415dd4713e22e095c853 komodo [komodo@komo.do](mailto:komodo@komo.do) 1746737773 +0000 pull --rebase --force origin main (start): checkout 578a0dd6d204778a3cdc415dd4713e22e095c853 578a0dd6d204778a3cdc415dd4713e22e095c853 578a0dd6d204778a3cdc415dd4713e22e095c853 komodo [komodo@komo.do](mailto:komodo@komo.do) 1746737773 +0000 pull --rebase --force origin main (finish): returning to refs/heads/main 578a0dd6d204778a3cdc415dd4713e22e095c853 578a0dd6d204778a3cdc415dd4713e22e095c853 komodo [komodo@komo.do](mailto:komodo@komo.do) 1746737791 +0000 checkout: moving from main to main ``` 7898291c92e77f21b2953f9210b9703a3944cd8d is the last commit before loosing data

GiteaMirror commented 2026-04-13 14:58:38 -05:00

Author

Owner

Copy Link

@beckerinj commented on GitHub (May 9, 2025):

The way that stack commit works, either initialize or update file, is by issuing a WriteCommitComposeContents call to periphery:

7a3b2b542d/bin/periphery/src/api/compose.rs (L247)

The first part of this function is call to pull_or_clone_stack. This should ensure to contents on the server are up to date, and if it fails it will abort the rest (ie the push).

In the case it is successful, the next step is to write the update, and commit the file. The git stuff starts with the git add:
7a3b2b542d/lib/git/src/commit.rs (L75)

It only add the single file that was changed to the commit. Then it commits with message, and finally will force push:
7a3b2b542d/lib/git/src/commit.rs (L120)

I'm not sure what part of this process would lead to the behavior you describe. It will force push, but only after successfully pulling latest, which would include all the commits up to that point. Also, in the commit there is output for each of these steps, any answers will be in there. Can you find the Log in Komodo for the commit you suspect cause this issue?

<!-- gh-comment-id:2867699192 --> @beckerinj commented on GitHub (May 9, 2025): The way that stack commit works, either initialize or update file, is by issuing a `WriteCommitComposeContents` call to periphery: https://github.com/moghtech/komodo/blob/7a3b2b542deca4e031ae732aa9add426f238864e/bin/periphery/src/api/compose.rs#L247 The first part of this function is call to `pull_or_clone_stack`. This should ensure to contents on the server are up to date, and if it fails it will abort the rest (ie the push). In the case it is successful, the next step is to write the update, and commit the file. The git stuff starts with the `git add`: https://github.com/moghtech/komodo/blob/7a3b2b542deca4e031ae732aa9add426f238864e/lib/git/src/commit.rs#L75 It only `add` the single file that was changed to the commit. Then it commits with message, and finally will force push: https://github.com/moghtech/komodo/blob/7a3b2b542deca4e031ae732aa9add426f238864e/lib/git/src/commit.rs#L120 I'm not sure what part of this process would lead to the behavior you describe. It will force push, but only after successfully pulling latest, which would include all the commits up to that point. Also, in the commit there is output for each of these steps, any answers will be in there. Can you find the Log in Komodo for the commit you suspect cause this issue?

GiteaMirror commented 2026-04-13 14:58:38 -05:00

Author

Owner

Copy Link

@Dinth commented on GitHub (May 9, 2025):

Here is Komodo log from that day:

message (2).txt

and two consecutive commits to GH:
757890d606/r720-omv (contains folders like fgc, searxng, pricebuddy)
and the next one:
578a0dd6d2/r720-omv (new folders are gone, commits lost in existing folders)

also interesting thing is that the 757890d6065d44808aeea77eb186dfbf27d221c0 and previous commits now show "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository."

<!-- gh-comment-id:2867737162 --> @Dinth commented on GitHub (May 9, 2025): Here is Komodo log from that day: [message (2).txt](https://github.com/user-attachments/files/20128076/message.2.txt) and two consecutive commits to GH: https://github.com/Dinth/komodo_library/tree/757890d6065d44808aeea77eb186dfbf27d221c0/r720-omv (contains folders like fgc, searxng, pricebuddy) and the next one: https://github.com/Dinth/komodo_library/tree/578a0dd6d204778a3cdc415dd4713e22e095c853/r720-omv (new folders are gone, commits lost in existing folders) also interesting thing is that the 757890d6065d44808aeea77eb186dfbf27d221c0 and previous commits now show "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository."

GiteaMirror commented 2026-04-13 14:58:39 -05:00

Author

Owner

Copy Link

@mbecker20 commented on GitHub (May 9, 2025):

It won't be in the core logs, it is stored in the database. We need to see the output of the commands I linked.

<!-- gh-comment-id:2867775635 --> @mbecker20 commented on GitHub (May 9, 2025): It won't be in the core logs, it is stored in the database. We need to see the output of the commands I linked.

GiteaMirror commented 2026-04-13 14:58:39 -05:00

Author

Owner

Copy Link

@Dinth commented on GitHub (May 10, 2025):

I think thats the one. But the only difference i can see between this and logs for other Write Stack Contents is that "(forced update)" bit

<!-- gh-comment-id:2868768897 --> @Dinth commented on GitHub (May 10, 2025): I think thats the one. But the only difference i can see between this and logs for other Write Stack Contents is that "(forced update)" bit  

GiteaMirror commented 2026-04-13 14:58:39 -05:00

Author

Owner

Copy Link

@jschneekloth commented on GitHub (May 19, 2025):

I just hit this as well, blew away entire git repository including history. I have daily backups so only lost a day of work, but that force push is very heavy handed if there is a misconfiguration with the state in komodo. My use case roughly went like this:

1. Create a new stack, configure it with same repository as others, but I misconfigured it
2. Fat finger some of the configuration (I believe I left the run directory blank by mistake, when it should have been stack_folder/new_stack_name and missed adding proper repo directory as well
3. Go to info, hit initialize file, which failed the Write Stack Contents, notice the misconfiguration
4. Fix config, go back to Info and initialize the compose file
5. boom....repo/history gone

<!-- gh-comment-id:2889502078 --> @jschneekloth commented on GitHub (May 19, 2025): I just hit this as well, blew away entire git repository including history. I have daily backups so only lost a day of work, but that force push is very heavy handed if there is a misconfiguration with the state in komodo. My use case roughly went like this: 1. Create a new stack, configure it with same repository as others, but I misconfigured it 2. Fat finger some of the configuration (I believe I left the run directory blank by mistake, when it should have been `stack_folder/new_stack_name` and missed adding proper repo directory as well 3. Go to info, hit initialize file, which failed the Write Stack Contents, notice the misconfiguration 4. Fix config, go back to Info and initialize the compose file 5. boom....repo/history gone

GiteaMirror commented 2026-04-13 14:58:39 -05:00

Author

Owner

Copy Link

@rsocko commented on GitHub (May 31, 2025):

I just ran into this issue myself for the second time. Like the others it happened to me once before early in using Komodo a month ago and I assumed I must have done something wrong and simply started over.

Yesterday it happened a second time and now I lost quite a bit of config and all my stacks are disconnected from GH save for the one I just added.

Would love some help on two things:

1. How is this happening and how do I prevent the steps I caused it?

• I did make a change in recreating a stack which previously had bind mounts to volumes.
• my resource sync stopped working just before and I deleted and recreated the sync.

2. Is there a way to recover and restore the prior state?

I love the ability to have my config managed and synchronized to GitHub. But this feels very fragile with whatever I'm doing wrong. Would love to have the system warn or stop me from this outcome.

<!-- gh-comment-id:2925449879 --> @rsocko commented on GitHub (May 31, 2025): I just ran into this issue myself for the second time. Like the others it happened to me once before early in using Komodo a month ago and I assumed I must have done something wrong and simply started over. Yesterday it happened a second time and now I lost quite a bit of config and all my stacks are disconnected from GH save for the one I just added. Would love some help on two things: 1. How is this happening and how do I prevent the steps I caused it? - I did make a change in recreating a stack which previously had bind mounts to volumes. - my resource sync stopped working just before and I deleted and recreated the sync. 2. Is there a way to recover and restore the prior state? I **love** the ability to have my config managed and synchronized to GitHub. But this feels very fragile with whatever I'm doing wrong. Would love to have the system warn or stop me from this outcome.

GiteaMirror commented 2026-04-13 14:58:40 -05:00

Author

Owner

Copy Link

@Dinth commented on GitHub (May 31, 2025):

Another small issue im experiencing - im not sure if its related, but perhaps - is that sometimes Komodo doesnt refresh the edited files. Ie. I edit the compose file, click Save, confirm the changes, file gets saved successfully, but doesnt refresh in the UI. I need to click the refresh button manually, to get the changes i just submitted. If i wont notice that and carry on editing, i can overwrite the previous change i pushed.

Is there a way to recover and restore the prior state?
I have recovered my prior state quite easily because i had a github action running on each commit and in GH action history i found the links to the relevant commits.

Also it seems that setting a branch protection:

Prevents this from happening, without any negative side effects i noticed. So, if blocking force push doesnt break anything, is there really a reason for Komodo doing force pushes?

<!-- gh-comment-id:2925468325 --> @Dinth commented on GitHub (May 31, 2025): Another small issue im experiencing - im not sure if its related, but perhaps - is that sometimes Komodo doesnt refresh the edited files. Ie. I edit the compose file, click Save, confirm the changes, file gets saved successfully, but doesnt refresh in the UI. I need to click the refresh button manually, to get the changes i just submitted. If i wont notice that and carry on editing, i can overwrite the previous change i pushed. > Is there a way to recover and restore the prior state? I have recovered my prior state quite easily because i had a github action running on each commit and in GH action history i found the links to the relevant commits. Also it seems that setting a branch protection:  Prevents this from happening, without any negative side effects i noticed. So, if blocking force push doesnt break anything, is there really a reason for Komodo doing force pushes?

GiteaMirror commented 2026-04-13 14:58:40 -05:00

Author

Owner

Copy Link

@Dinth commented on GitHub (May 31, 2025):

Oh actually, i just found a "side effect" of branch protection. I have created a new stack, but when i try to initialise it, I got:

File contents to write
Stage 1 of 6
|
0.0 seconds

stdout

## Add your compose file here
services:
  hello_world:
    image: hello-world
    # networks:
    #   - default
    # ports:
    #   - 3000:3000
    # volumes:
    #   - data:/data

# networks:
#   default: {}

# volumes:
#   data:
Write file
Stage 2 of 6
|
0.0 seconds

stdout

File contents written to "/etc/komodo/stacks/pinchflat/r720-omv/pinchflat/compose.yaml"
Add Files
Stage 3 of 6
|
0.0 seconds

command

cd /etc/komodo/stacks/pinchflat && git add r720-omv/pinchflat/compose.yaml
Commit
Stage 4 of 6
|
0.0 seconds

command

cd /etc/komodo/stacks/pinchflat && git commit -m "[Komodo] dinth: Write Compose File: update "r720-omv/pinchflat/compose.yaml""
stdout

[main (root-commit) 0526bef] [Komodo] dinth: Write Compose File: update r720-omv/pinchflat/compose.yaml
 1 file changed, 16 insertions(+)
 create mode 100644 r720-omv/pinchflat/compose.yaml
Latest Commit
Stage 5 of 6
|
0.0 seconds

command

cd /etc/komodo/stacks/pinchflat && git rev-parse --short HEAD && git rev-parse HEAD && git log -1 --pretty=%B
stdout

hash: 0526bef
message: [Komodo] dinth: Write Compose File: update r720-omv/pinchflat/compose.yaml
Push
Stage 6 of 6
|
1.0 seconds

command

cd /etc/komodo/stacks/pinchflat && git push -f --set-upstream origin main
stderr

remote: error: GH013: Repository rule violations found for refs/heads/main.        
remote: Review all repository rules at https://github.com/Dinth/komodo_library/rules?ref=refs%2Fheads%2Fmain        
remote: 
remote: - Cannot force-push to this branch        
remote: 
To https://github.com/Dinth/komodo_library
 ! [remote rejected] main -> main (push declined due to repository rule violations)
error: failed to push some refs to 'https://github.com/Dinth/komodo_library'

<!-- gh-comment-id:2925689146 --> @Dinth commented on GitHub (May 31, 2025): Oh actually, i just found a "side effect" of branch protection. I have created a new stack, but when i try to initialise it, I got: ``` File contents to write Stage 1 of 6 | 0.0 seconds stdout ## Add your compose file here services: hello_world: image: hello-world # networks: # - default # ports: # - 3000:3000 # volumes: # - data:/data # networks: # default: {} # volumes: # data: Write file Stage 2 of 6 | 0.0 seconds stdout File contents written to "/etc/komodo/stacks/pinchflat/r720-omv/pinchflat/compose.yaml" Add Files Stage 3 of 6 | 0.0 seconds command cd /etc/komodo/stacks/pinchflat && git add r720-omv/pinchflat/compose.yaml Commit Stage 4 of 6 | 0.0 seconds command cd /etc/komodo/stacks/pinchflat && git commit -m "[Komodo] dinth: Write Compose File: update "r720-omv/pinchflat/compose.yaml"" stdout [main (root-commit) 0526bef] [Komodo] dinth: Write Compose File: update r720-omv/pinchflat/compose.yaml 1 file changed, 16 insertions(+) create mode 100644 r720-omv/pinchflat/compose.yaml Latest Commit Stage 5 of 6 | 0.0 seconds command cd /etc/komodo/stacks/pinchflat && git rev-parse --short HEAD && git rev-parse HEAD && git log -1 --pretty=%B stdout hash: 0526bef message: [Komodo] dinth: Write Compose File: update r720-omv/pinchflat/compose.yaml Push Stage 6 of 6 | 1.0 seconds command cd /etc/komodo/stacks/pinchflat && git push -f --set-upstream origin main stderr remote: error: GH013: Repository rule violations found for refs/heads/main. remote: Review all repository rules at https://github.com/Dinth/komodo_library/rules?ref=refs%2Fheads%2Fmain remote: remote: - Cannot force-push to this branch remote: To https://github.com/Dinth/komodo_library ! [remote rejected] main -> main (push declined due to repository rule violations) error: failed to push some refs to 'https://github.com/Dinth/komodo_library' ```

GiteaMirror commented 2026-04-13 14:58:41 -05:00

Author

Owner

Copy Link

@rsocko commented on GitHub (May 31, 2025):

@Dinth - I am relatively new to GH and GH Actions. Would you mind sharing any more info about what GH Actions you have configured to run on any commit so that I might replicate it as a bit of protection or recovery info?

<!-- gh-comment-id:2925701450 --> @rsocko commented on GitHub (May 31, 2025): @Dinth - I am relatively new to GH and GH Actions. Would you mind sharing any more info about what GH Actions you have configured to run on any commit so that I might replicate it as a bit of protection or recovery info?

GiteaMirror commented 2026-04-13 14:58:41 -05:00

Author

Owner

Copy Link

@Dinth commented on GitHub (May 31, 2025):

Me too, my action doesnt even work and fails every time, still saved my %%% here:) Check this: https://github.com/Dinth/komodo_library/blob/main/.github/workflows/docker-compose-check.yml

The log looks like this:

and you get link to each commit, even if its gone from repo history

<!-- gh-comment-id:2925703653 --> @Dinth commented on GitHub (May 31, 2025): Me too, my action doesnt even work and fails every time, still saved my %%% here:) Check this: https://github.com/Dinth/komodo_library/blob/main/.github/workflows/docker-compose-check.yml The log looks like this:  and you get link to each commit, even if its gone from repo history

GiteaMirror commented 2026-04-13 14:58:41 -05:00

Author

Owner

Copy Link

@jschneekloth commented on GitHub (Jun 1, 2025):

IMO, I think force push should be dropped. There shouldn't be a need for it, and if anything goes wrong, it really goes wrong. If for some reason one cannot programtically work out how to submit w/o a force push, probably best to leave it up to the user to unwind and fix things up as they have most likely done something out of band already...

<!-- gh-comment-id:2926099049 --> @jschneekloth commented on GitHub (Jun 1, 2025): IMO, I think force push should be dropped. There shouldn't be a need for it, and if anything goes wrong, it really goes wrong. If for some reason one cannot programtically work out how to submit w/o a force push, probably best to leave it up to the user to unwind and fix things up as they have most likely done something out of band already...

GiteaMirror commented 2026-04-13 14:58:42 -05:00

Author

Owner

Copy Link

@rsocko commented on GitHub (Jun 2, 2025):

I just recreated my environment and repo from scratch. I had basically nothing left in the GitHub repo, so I deleted each stack in Komodo and recreated the resource sync. Then I methodically created each stack once again and sync'd to GitHub. For now I have a clean and functioning repo and Komodo sync.

In an effort to make any such recovery much faster and to (hopefully) make it a little easier to track down which step or steps caused the force push / rebase, I added 2 GitHub actions to my repo that I thought I would share. They are somewhat redundant, but I thought it would be useful for the time being to have extra backup copies.

I used Copilot to help me create these two actions and tweak them. It was quite easy! I've stored the setup I'm using in Gists in case they help others.

1. On every PUSH to my MAIN branch - it will make a copy (archive) of the repo and stores as an artifact of the action.
2. Nightly (approx midnight Eastern Time) or on-demand, it creates a full archive (including history) and stores the zipped file as an artifact.

Notes:

• GitHub actions by default retain 90 days of history and artifacts. This should give me ample time to catch an error and have sufficient history backup to restore my repo and komodo setup as needed. You can adjust this retention period when storing the artifact
• The PUSH trigger for GitHub occurs AFTER the push on the repo. Thus when a Force Push / Rebase is executed by Komodo, that will store the now empty/cleared out Repo. But the prior action / history will be present for the workflow run of the change prior to the force push. If it has been >90 days then that history may not exist. This is partly why I also created a nightly backup job.

I still agree that eliminating the force push would be best, but will be using this as backup in the interim.

<!-- gh-comment-id:2932085504 --> @rsocko commented on GitHub (Jun 2, 2025): I just recreated my environment and repo from scratch. I had basically nothing left in the GitHub repo, so I deleted each stack in Komodo and recreated the resource sync. Then I methodically created each stack once again and sync'd to GitHub. For now I have a clean and functioning repo and Komodo sync. In an effort to make any such recovery much faster and to (hopefully) make it a little easier to track down which step or steps caused the force push / rebase, I added 2 GitHub actions to my repo that I thought I would share. They are somewhat redundant, but I thought it would be useful for the time being to have extra backup copies. I used Copilot to help me create these two actions and tweak them. It was quite easy! I've stored the setup I'm using in Gists in case they help others. 1. [On every PUSH to my MAIN branch](https://gist.github.com/rsocko/8a03b737e7f1a13bc043e726e8de21aa) - it will make a copy (archive) of the repo and stores as an artifact of the action. 2. [Nightly (approx midnight Eastern Time) or on-demand](https://gist.github.com/rsocko/a59eea862a57738d8c3b7e8c5f8f32d9), it creates a full archive (including history) and stores the zipped file as an artifact. Notes: - GitHub actions by default [retain 90 days of history and artifacts.](https://docs.github.com/en/organizations/managing-organization-settings/configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-organization) This should give me ample time to catch an error and have sufficient history backup to restore my repo and komodo setup as needed. You can [adjust this retention](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow#configuring-a-custom-artifact-retention-period) period when storing the artifact - The PUSH trigger for GitHub occurs AFTER the push on the repo. Thus when a Force Push / Rebase is executed by Komodo, that will store the now empty/cleared out Repo. But the prior action / history will be present for the workflow run of the change prior to the force push. If it has been >90 days then that history may not exist. This is partly why I also created a nightly backup job. I still agree that eliminating the force push would be best, but will be using this as backup in the interim.

GiteaMirror commented 2026-04-13 14:58:44 -05:00

Author

Owner

Copy Link

@mbecker20 commented on GitHub (Jun 7, 2025):

The force push is removed in 1.18.1. In cases where it would remove / reorder commits (which you wouldn't want anyways, leads to issues like above) the commit will fail, and may require resolution like pulling repo via refresh action, or maybe recloning repo before commit works.

<!-- gh-comment-id:2953095288 --> @mbecker20 commented on GitHub (Jun 7, 2025): The force push is removed in [1.18.1](https://github.com/moghtech/komodo/releases/tag/v1.18.1). In cases where it would remove / reorder commits (which you wouldn't want anyways, leads to issues like above) the commit will fail, and may require resolution like pulling repo via refresh action, or maybe recloning repo before commit works.

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

gh-pages-docs

legacy-v1-frontend

copilot/secure-local-authentication

v0

legacy

v2.2.0

v2.1.2

v2.1.1

v2.1.0

v2.0.0

v2.0.0-dev-124

v2.0.0-dev-123

v2.0.0-dev-120

v2.0.0-dev-118

v2.0.0-dev-114

v2.0.0-dev-112

v2.0.0-dev-111

v2.0.0-dev-102

v2.0.0-dev-98

v2.0.0-dev-90

v2.0.0-dev-86

v2.0.0-dev-72

v2.0.0-dev-59

v2.0.0-dev-53

v2.0.0-dev-50

v2.0.0-dev-36

v1.19.5

v2.0.0-dev-35

v1.19.4

v1.19.3

v1.19.2

v1.19.1

v1.19.1-dev-14

v1.19.0

v1.19.0-dev-9

v1.18.4

1.18.5-dev-5

v1.18.3

v1.18.2

v1.18.1

v1.18.0

v1.17.5

v1.17.4

v1.17.3

v1.17.4-dev-1

v1.17.2

v1.17.2-dev-1

v1.17.1

v1.17.0

v1.17.0-dev-7

v1.17.0-dev-4

v1.17.0-dev-3

v1.17.0-dev-5

v1.17.0-dev-6

v1.17.0-dev-2

v1.17.0-dev-1

v1.16.12

v1.16.11

v1.16.10

v1.16.9

v1.16.8

v1.16.7

v1.16.6

v1.16.5

v1.16.4

v1.16.3

v1.16.2

v1.16.1

v1.16.0

v1.15.12

v1.15.11

v1.15.10

v1.15.9

v1.15.8

v1.15.7

v1.15.6

v1.15.5

v1.15.4

v1.15.3

v1.15.2

v1.15.1

v1.15.0

v1.14.2

v1.14.1

v1.14.0

v1.14.0-rc1

v1.13.4

v1.13.3

v1.13.2

v1.13.1

v1.13.0

v1.12.0

v1.11.0

v1.10.0

v1.9.0

v1.8.0

v1.7.3

v1.7.0

v1.6.0

v1.5.0

v1.4.0

v1.2.0

v1.1.0

v1.0.0

v0.3.4

v0.3.3

v0.3.2

v0.3.0

v0.2.14

v0.2.13

v0.2.12

v0.2.11

v0.2.10

v0.2.9

v0.2.7

v0.2.6

v0.2.5

v0.2.4

v0.2.1

v0.2.0

v0.1.17

v0.1.16

v0.1.15

v0.1.11

v0.1.10

v0.1.9

Labels

Clear labels

1.19.0

1.19.1

1.19.2

1.19.3

1.19.4

2.0.0

bug

documentation

done

enhancement

help wanted

info

pull-request

Mirrored from GitHub Pull Request

question

security

seen 👀

setup

thinking 🤔

ui

v2

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/komodo#3373