Do you pronounce "drip" with

@encthenet @whitequark @recursive To me this is a great example of how tools influence workflows.

Imagine if Dropbox forced you to right-click and add new files. It is immediately obvious to me that it would really suck -- people would hate it because they'd lose data all the time! Why should we not hold source control to the same standards?

@encthenet @whitequark @recursive I had the same issue! But to me, that is a maladaptive behavior in light of Git not forcing me to make a decision about them.

When I switched to Jujutsu, which does force you to make decisions about those files because it auto-adds new files that aren't ignored, I fixed my workflow within minutes.

@whitequark @recursive Right, and that's what gitignore is for. But that shouldn't be the default. (Dropbox also supports ignore files, incidentally.)

@whitequark @recursive Basically I think that to the extent that source control diverges from Dropbox, there needs to be a good, specific answer as to why. For example, there is no good reason to not add untracked files automatically just like Dropbox does, and doing so solves real data loss issues just like Dropbox does

@recursive @whitequark This feature does not go away when you make source control more like Dropbox

@whitequark I think that answers why source control needs to be more feature rich than Dropbox. I don't think it answers why source control has to be janky in a way that Dropbox isn't

Dropbox doesn't make you add new files, why does your source control?

Dropbox doesn't have a notion of uncommitted data, why does source control?

Dropbox isn't modal when it comes to conflicts, why is your source control?

Kind of convinced that Dropbox provides the baseline experience that source control should aspire to. "Dropbox does X, why doesn't your source control system?" should be asked over and over

And to be clear, often the user is right and there is a real need. sometimes the user has a real need but the solution they're proposing might make things worse down the road. sometimes users have a need but solving it would have too many negative externalities on everyone else. and sometimes users are just wrong

Expertise at building devtools means approaching these situations with empathy balanced with foresight, and getting better at distinguishing these cases

There are several git features, including submodules and assume-unchanged, that fall into this bucket. People think they want those features but don't really, and their existence has detrimental effects on the community. You have to withhold features like these for the benefit of the community

As a devtools expert, one of my stronger beliefs around devtools is forbearance: you don't want to give people the ability to do everything they want. Sometimes you have to make a judgment call and decide that what people want is going to be bad for them

@endocrimes @ellie (fwiw I have a lot of data to show that the JJ approach is strongly preferred by most people — I worked on source control at FB for many years, where we did a lot of the things jj does. The data was stark, over 90% of engineers , most of which had only used git before, preferred it to the git workflow)

@endocrimes @ellie what did you have in mind here? if it's the index/staging area then jj gives you all of the power in a different way

Thinking about writing something on why Tokio's semaphores are fantastic but you should never use Tokio's mutexes

I guess Windows shipped Rust in the kernel before Linux, huh