Bring back trunk-ng into trunk #623
Conversation
Ultimately, deeper investigation has revealed that std::fs::copy will generate modification events on the source file (the file being copied) on some platforms. This has proven to be a source of difficulty for the FS watcher, and has lead to infinite build loops, despite the fact that none of the files / directories being watched were actually changed. Here we implement a post-build cooldown interval of 1s. This ensures that in very fast builds, we do not end up receiving a modification event due to std::fs::copy (from the copy source). Moreover, any FS events which have accumulated during the 1s cooldown will be purged. Altogether this will hopefully fully address the recursive build issue, and will hopefully not disrupt the development workflow. Also, update deps, changelog and a few README items.
This should allow to work around issues on windows, where the FS events don't get detected well.
ctron
force-pushed
the
feature/back_to_trunk_1
branch
3 times, most recently
from
e8900e2 to
a6c5b54
Compare
ctron
force-pushed
the
feature/back_to_trunk_1
branch
from
a6c5b54 to
522d138
Compare
|
If that's ok with you, I would like to try a release. If I'll mess it up, I'll owe you a few beers more 😉 |
|
@thedodd It looks like I can't rebase this PR, but I definitely don't want to squash it either. Would you be ok with doing a one-time merge with this? |
|
@ctron you should still be able to rebase it, but you will have to do it on the CLI, not in GH. Even if we enable merge commits, it will still requite the conflicts to be resolved. Do you know the source of the conflicts? Different point in history where you branched off? Also, why not squash? That will make the rebase MUCH easier. |
No, when doing a merge commit, it won't require a linear history. That makes things a lot easier.
Yes. There had been commits post my fork. Which are merged now too. But not in a linear history.
Because that would erase the history of all committers having contributed to that. So yes, I should be able to merge locally and then push the result. But I wanted to check with you first. |
|
So it looks like the master branch is protected in a way that I can't directly push merge commits. |
|
@ctron ok, I've disabled the linear history requirement on master. Looks like your PR can be merged straight away. I'll let you do the honors. Once I see this PR merged, then I'll press the button to move the repo over to the new org. |
This PR brings back the changes from
trunk-ngintotrunk.There are a few non-technical changes in there too:
Also, those changes come in with all their commits, un-squashed. I know this is a lot of personal taste. However, I believe that having the full history of a PR makes some sense. Maybe ask on the PR to squash certain commits. But then again, let's make it easy for people to contribute.