raylu

I've thought about using https://github.com/dlvhdr/diffnav for that

I'm having a hard time understanding your question. are you asking how people who are unfamiliar with git and jj should mentally model a stack of PRs? and that this is a problem because it's intimidating for them when an expert (in git? in the codebase?) is reviewing their code?

if yes:

while jj does make stacked PRs quite easy, I think this tutorial is mostly aimed at people who are still getting their feet wet and not making stacks of PRs. and if the expert is intimidating, tell them to be helpful or fuck off

if no:

well I don't understand your question, but probably don't `jj edit` the commit at the bottom of a stack; `jj new` and, when you're ready, either `jj squash` it down or `jj rebase -s @ -A @-` your change into the stack instead

the thing about rebasing/cherry-picking (including just popping the stash) in git is that you only have 2 choices: fix the conflict now or abandon the entire rebase/cherry-pick

with jj, you have the option to fix half of it and come back later. you can take a look and see how bad the conflicts are if you go a certain route and compare to another option

`jj op` has `log` to show you the op log, `show`/`diff` which work like their non-op versions, and `jj op restore` which is sorta like `git reset --hard HEAD@{whatever}` but for your whole repo state

wait what?

bitbucket will merge a PR from your feature branch onto the base branch even if it's not fast-forward from the base branch. as long as you use the "squash" or "rebase" option on the PR interface (instead of the "merge" option), the resulting history will be linear

`git rebase -i` lets you reorder one branch of commits easily

in a stacked PR workflow, after the bottom PR merges, you now want to rebase the whole stack atop the main branch. if that's 3 PRs, that's 3 branches, 3 rebases

one thing `git rebase` doesn't let you do but `jj rebase -s source -d dest` does is move a commit from one branch to another (`git switch dest`, `git cherry-pick source`, `git switch -C source source^`, `git switch dest`)

I ran into this at first on a large-ish repo. watchman fixed it: https://jj-vcs.github.io/jj/latest/config/#filesystem-monito...

it feels like we're conflating two issues here: fixing the bug on time and paying out the researcher. at the point where the bug is too complicated to fix within SLA and the exception has been escalated to senior leadership, surely the bug bounty team can pay the researcher?

much smaller, less wealthy companies attract far fewer reports

Good thing you sold immediately when they vested.

Don't jump to conclusions too fast about a reduced example to demonstrate a problem.

I probably originally had 2 expressions that evaluated to booleans. I may have been using `is` to check that the type of one was actually a bool rather than just falsey.

IIRC, I originally had 2 expressions that evaluated to booleans that I was comparing. I don't remember if I had parens, but I do remember being deeply confused once there were no parens.

But also, those high ladders of abstraction support some pretty cool software...

Oh, hi!

Yeah, that was a real head-scratcher.

Why? What even was the point in making them 'typed' then?

To prevent you from passing a String as a String[Zipcode].

Nullsec is dominated by the nullsec alliances, and big battles, which are the only thing non-EVE media reports on, happen almost exclusively in nullsec.

Yeah, but if you have a test suite you add Python 3 and silence the existing failures.

They likely already know where a lot of their failures are going to be even without tests. The effort involved in fixing those known failures alone is prohibitive. The fact that the rest of regression testing will be easier with tests is nice, but doesn't reduce the work required to a level where they can justify doing it.

Now you can (at least partially) avoid writing new code that wouldn't work on 3,

Once you're on 3, you can just run your code and see if it works on 3. You don't need tests to avoid writing code that works on 2 but not 3.

as well as gain the option of refactoring things to resolve compatibility - with lots of freedom to decide how much effort to spend on that if any.

I don't think resolving compatibility issues is optional...

That's quite a glorified view of tests. You can have the best test coverage in the world backed by a great CI culture but if porting something is a huge time investment, it may still be a huge time investment. Maybe there's one 2.x feature that you use almost everywhere that has been removed in 3.x and there's no simple way to replace it automatically.

See every organization still running on XP ? They may be sentence to death in 3 month, that may be the hardest way learn it.

See that place running COBOL? Yeah, that's your bank.

libx264 doesn't provide a decoder. Did you mean H.264?

I find it difficult to imagine that anyone would actually believe the two are equivalent, but maybe I've just been hanging around HN-types too much.

Reminds me of http://mod16.org/hurfdurf/?p=12 .

"since they're all held to a reasonable minimum standard."

Except the ones that are too big to fail right?

https://bugzilla.mozilla.org/show_bug.cgi?id=647959

If you have a compiled project, files that aren't tracked include all of your intermediate .o files, for example. If you `grep -r` the wrong way, it may traverse the .git directory.

I assume you've already considered using gvim?

The problem isn't making changes to the source. The monoculture or de-facto standards come up because those are the rendering engines used by users. You can make WebKit or Trident a billion times better but it won't matter to web developers or users until users adopt the new code.

I was using "your" in the third-person, a quirk of the English language that is too late to fix.

Configuration should not be able to cause your software to segfault. Configuration shouldn't be software. And, in case it's not clear, configuration should not be written in C/C++.

If every page was similar to this one, the web would be plainer and simpler. It seems that you seem to think this is a bad thing by characterizing it as "bleak and characterless." I think it would just be a whole lot less stupid :D.

I'm rather annoyed that you're not reading anything I've said.

No, the problem is not that I haven't read the page. I have. It can cause segfaults. Your configuration can cause segfaults. Your configuration can cause segfaults. Your configuration can cause segfaults.

And yes, I acknowledged that they can't remove it because it's too late, using those exact words. That doesn't mean it's not a problem. It means you should jump ship to something saner, like lighttpd, which also doesn't have the rewrite-sometimes-redirects problem.

Ah, that's unfortunate. https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/5...