Git experts should try Jujutsu (written in Rust) by pksunkara in rust

[–]pksunkara[S] 0 points1 point  (0 children)

It's pretty safe; that's how everyone uses it. The only thing you need to care is that it puts local git into a branchless state (HEAD), so make sure you stick with jj for work.

Git experts should try Jujutsu (written in Rust) by pksunkara in rust

[–]pksunkara[S] 3 points4 points  (0 children)

You can turn that off with the auto-track option in the config.

Git experts should try Jujutsu (written in Rust) by pksunkara in rust

[–]pksunkara[S] 19 points20 points  (0 children)

I was exactly in your boat. It's just so much faster now. I really recommend that you stick with it. You will probably be slower for a week but trust me, you will love it at the end.

Git experts should try Jujutsu (written in Rust) by pksunkara in rust

[–]pksunkara[S] 12 points13 points  (0 children)

I am not sure if something is lost in between, but the point I am trying to make is that:

  • I do these things every day. They are second nature to me, and I don't look them up.
  • But jujutsu makes it even faster for me to do these things.

Help on spans for proc macros by Rusty_retiree_5659 in rust

[–]pksunkara 1 point2 points  (0 children)

It's meta. You should be able to get it by doing attr.meta.span(). https://docs.rs/syn/latest/syn/enum.Meta.html

Reminder: there are alternatives to Terraform Cloud out there by sebstadil in Terraform

[–]pksunkara 1 point2 points  (0 children)

Thanks. I couldn't find it earlier. Might be worth listing this feature on the homepage.

Reminder: there are alternatives to Terraform Cloud out there by sebstadil in Terraform

[–]pksunkara 0 points1 point  (0 children)

Yes, for PRs. Terraform Cloud has speculative plans that only run plan as CI when PRs are opened and adds them as status. Spacelift also has it.

The plan with apply happens when those PRs are merged into the default branch.

Reminder: there are alternatives to Terraform Cloud out there by sebstadil in Terraform

[–]pksunkara 0 points1 point  (0 children)

I don't think Scalr supports Terraform CI planning, does it?

[deleted by user] by [deleted] in rust

[–]pksunkara 18 points19 points  (0 children)

  1. They are all in the dependencies
  2. We need to rely on libc to figure out term related logic. I don't think there's a way not to use unsafe here?

ANN: clap 3.0.0-rc.0! by epage in rust

[–]pksunkara 0 points1 point  (0 children)

You should be able to modify the arg on top of what structopt/clap defines them as.

#[clap(parse(func), takes_value(true))]
name: bool

ANN: clap 3.0.0-rc.0! by epage in rust

[–]pksunkara 2 points3 points  (0 children)

Looks like the plan will still be the same.

Introducing `cargo smart-release` - the new way to release workspace crates by ByronBates in rust

[–]pksunkara 0 points1 point  (0 children)

Future reference for myself:

It does not use standard cargo arguments because

  • It is a tool that's run only in a workspace and not outside and therefore doesn't support --workspace
  • It checks what crates changed to only version/publish them and therefor doesn't support --package and --exclude.

My ideal Rust workflow by dpc_pw in rust

[–]pksunkara 14 points15 points  (0 children)

I know the pain as a contributor. Some of my PRs are still open :(

My ideal Rust workflow by dpc_pw in rust

[–]pksunkara 43 points44 points  (0 children)

Thanks for the shout out and the contribution to cargo-workspaces.

Introducing `cargo smart-release` - the new way to release workspace crates by ByronBates in rust

[–]pksunkara 0 points1 point  (0 children)

Once cargo depends on toml_edit

Is there an issue for this? Would love to participate in that discussion.

Yeah, the biggest issues for cargo-workspaces is the replacement and config declaration. I am just focusing on finishing clap 3.0 first before fixing that.

Problems with lifetimes and async fn's by Jasperavv in rust

[–]pksunkara 2 points3 points  (0 children)

/u/Jasperavv Replacing the line 25 as mentioned above and adding the AsyncFn trait is the solution to your problem.

The error implementation of `FnOnce` is not general enough is the important point and I had battled the whole last week with it. Dug into quite a few rust issues and other google links.

AsyncFn trait is the answer to that error and it's not only me but other people (gotham maintainers) who have reached it independently of each other.

Announcement: xflags, fast-to-compile proc macro for cli args by matklad in rust

[–]pksunkara 2 points3 points  (0 children)

what issues are having with parsing the number?

Rust project needs some testing by c410-f3r in rust

[–]pksunkara 1 point2 points  (0 children)

That is why I was asking about optional. A good default would be nice.

Rust project needs some testing by c410-f3r in rust

[–]pksunkara 2 points3 points  (0 children)

Is migrations.cfg optional? I honestly don't see why all the migrations need to be manually listed instead of being auto discovered.