Labelling this bug although this behaviour may be intentional. I expected the whole adding the reset file feature to force the reset regardless of commit history. Turns out adding that file only does the reset on the commit that file is added, and not on any subsequent commits. That means you can’t do two resets in a row, which is useful for what I was doing. Taking a peak at @adam’s script I see that that’s because it’s looking for the presence of the reset file in $diff.
My recommendation is that the presence of the reset file in the git repo should always trigger a reset, that would make weblog debugging much easier, although I can see the rational in @adam’s implementation.
So, like much of weblog.lol, there’s a reason (albeit maybe not the best reason) for the current setup. I had to limit the reset trigger in this way to prevent people from leaving a reset file in place permanently, which triggers a full regeneration of the weblog. On larger weblogs, this is a relatively a costly operation in terms of resource usage… and, unsurprisingly, the largest weblogs tend to be managed via Git. At some point I might be able to optimize things to the extent that this wouldn’t be a problem, but I’m not there yet.
Apologies for the need to do a little song-and-dance with the reset file, but I hope this makes sense!
Thanks @adam! Not realy sure was working on my template and idealy I wouldn’t put any strain on your infrastructure and make and preview the whole thing locally, then upload, but I don’t see a way in that could be possible, so I’m just resorting to copying it to and from my IDE and on to the text box on the dashboard, then regenerating.
was working on my template and idealy I wouldn’t put any strain on your infrastructure and make and preview the whole thing locally, then upload, but I don’t see a way in that could be possible, so I’m just resorting to copying it to and from my IDE and on to the text box on the dashboard, then regenerating.