Germany
Rust and NixOS enthusiast.
From Matthias Beyer to ~sircmpwn/sr.ht-discuss
On 14-07-2020 08:32:46, Drew DeVault wrote: > Also, after you merge or rebase commits from your feature branch to > master, their hash changes. So now we're deep comparing commits, and we > have to store the full patch somewhere instead of just the sha to know > that we've already built it. No, you misunderstood that part. I meant that only the hash is used to check whether the commit is already built, which would prevent building in fast-forward-merge cases, but not in other cases. Same hash: no rebuild. Other hash (rebase, cherry-pick, whatever): normal build. Matthias
From Matthias Beyer to ~sircmpwn/sr.ht-discuss
Hi, I was thinking whether it would be a good idea to introduce a flag for builds.sr.ht which tells the platform to not rebuild a commit if it was already successfully build. Usecase: In the early-development phase of a project, I like to play around with feature-branches which I change until I like what I have and then fast-forward master. That means that master gets the commit which was already built and re-starts a build (see [0] and [1] for example). I mean, I don't mind that, but I do actually not care about the build at all because the output is the same anyways. Maybe that's a case where an optional optimization would be possible.
From Matthias Beyer to ~sircmpwn/sr.ht-discuss
Hi, On 07-06-2020 09:12:18, Elias Naur wrote: > Furthermore, I'd like to suggest a send-email-to-me button to send > myself emails from the archive or patches tabs. I prefer to review > patches by email, but that's only practical because I subscribe to the > mailing list that receives all patches. By selectively sending emails to > oneself, you can email review patches that you're interested in without > having to subscribe to them all. You can download the patchset as mbox, that's exactly what you're asking for, isnt it? --
From Matthias Beyer to ~sircmpwn/sr.ht-discuss
Hi,
On 28-05-2020 21:07:48, Drew DeVault wrote:
> https://paste.sr.ht/~sircmpwn/c5516b2c64466b2381710092af37453ce204d2b9
I can totally see where this comes from and what the purpose of such a change
is. I think that changing the rules this way is a step forward (IMHO into the
right direction, but that is of course to be discussed, hence your mail :-) ).
My only concern is, that one may argue that you're taking away freedoms of the
user, essentially. This is just a really minor thing and I am personally not
affected, as my repos on sourcehut are MPL or (L)GPL, but I can see that users
might point out that you're restricting their freedom.
The obvious counter argument is that they still have the freedom to unlist their
From Matthias Beyer to ~emersion/public-inbox
Hi,
just stumbled over kanshi. In the repo (on github) you link to
https://wayland.emersion.fr/kanshi/
but the page says "No releases yet", although the github repo lists two.
Might wanna update the website? :-)
Best,
Matthias
From Matthias Beyer to ~mort/public-inbox
Signed-off-by: Matthias Beyer <mail@beyermatthias.de> --- src/main.rs | 26 ++++++++++++++------------ src/purge.rs | 10 +++++----- 2 files changed, 19 insertions(+), 17 deletions(-) diff --git a/src/main.rs b/src/main.rs index 7f81f2a..a2be060 100644 --- a/src/main.rs +++ b/src/main.rs @@ -1,3 +1,5 @@ #[macro_use] extern crate log; mod config; [message trimmed]
From Matthias Beyer to ~mort/public-inbox
Signed-off-by: Matthias Beyer <mail@beyermatthias.de> --- src/main.rs | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/main.rs b/src/main.rs index 0067e25..7f81f2a 100644 --- a/src/main.rs +++ b/src/main.rs @@ -317,6 +317,9 @@ async fn on_request(req: Request<Body>) -> Result<Response<Body>, Infallible> { #[tokio::main] async fn main() { let _ = env_logger::from_env(env_logger::Env::default().default_filter_or("info")).init(); [message trimmed]
From Matthias Beyer to ~mort/public-inbox
Hi, > Do you know if there's something I can do to merge successfully (in a way > which preserves attribution), or would you have to send a new set of changes? Here's simply a re-send with the fixup commits squashed away. I saw that you applied the first patch of my series, so this resend does not contain it anymore. You should be able to apply these from your email client (for mutt, use "| git am" to simply pipe one patch after another to "git am" within your working copy of the repository). Best,
From Matthias Beyer to ~mort/public-inbox
Signed-off-by: Matthias Beyer <mail@beyermatthias.de> --- src/main.rs | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/main.rs b/src/main.rs index 8fd7c1d..609d71f 100644 --- a/src/main.rs +++ b/src/main.rs @@ -1,3 +1,5 @@ #[macro_use] extern crate log; mod config; mod purge; [message trimmed]
From Matthias Beyer to ~mort/public-inbox
Signed-off-by: Matthias Beyer <mail@beyermatthias.de> --- src/main.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/main.rs b/src/main.rs index 685bf80..8fd7c1d 100644 --- a/src/main.rs +++ b/src/main.rs @@ -307,7 +307,7 @@ async fn on_request(req: Request<Body>) -> Result<Response<Body>, Infallible> { #[tokio::main] async fn main() { let _ = env_logger::from_env(Env::default().default_filter_or("info")).init(); [message trimmed]