131–140 of 212 posts
Not really on topic, but I think it's funny that most MMA style gyms always offer Jiu Jitsu and Muay Thai as two classes, right after each other. Of the two, Jiu Jitsu seems to generally be the more popular one.
Earlier quoted context omitted.
It does require a google CLA.
What does "CLA" stand for? edit: apparently Contributor License Agreement
They don't want to accidentally bring in GPL-3 or private code into an Apache licensed project, and my understanding is this is a self-certifying statement that you won't and have full rights to make the contributions
Earlier quoted context omitted.
You're both working on the same branch on the remote? It will refuse to push unless you do `jj git push --force` at which point it will overwrite your coworkers work with yours. This is regardless of conflicts, like with git you have to pull the remote work locally, rebase on it, and then push it. > iiuc jj uses stacked commits instead of branches Locally jj doesn't really use branches, you can just create a commit o…
We don't use rebase at all, it's forbidden. Since jj does not have branches, it sounds like we are forced into the rebase environment? With git, I can push my changes without a force, regardless of what the work I build on does I think jj's biggest challenge to adoption or replacing git is not technical, it's that it requires people changing how they think about and perform a very central act of their non-coding acti…
No, I tend to use rebase by default (because I like linear history) so its the language I use but it's equally valid in both git and jj to merge via merge commits instead of rebases.
While JJ doesn't have a concept it calls branches, it has all the same semantic power of branches. The difference here is just that git insists on each leaf commit in the source control tree being tagged with a name it calls a branch, jj is perfectly happy to have leaves in the source control tree where you haven't given them a branch-name.
> This sounds like merge conflicts are "shifted-left"? Today we see merge conflicts when a PR is opened and devs fix as needed. With jj it sounds like they couldn't push until the merge fix is resolved. Many times it's not important to deal with that straight away and the dev can continue to get their task done, see builds and results for their changes, etc...
The behaviour here is the exact same between git and jj. If both you and a coworker push to the same remote branch you have to handle conflicts before pushing with either VCS. If both you and a coworker push to different remote branches and then you submit the change through a pull request you see conflicts when you try to merge the branches (or a reasonable forge like github will test merging behind the scenes and surface it early).
> Is this "shift-left" of conflict resolution an accurate way to describe jj's approach / philosophy?
No. jj never shifts conflict resolution left. JJ does sometimes shift conflicts right, allowing you to defer fixing the conflict until later.
I've worked in huge repos with hundreds of developers pushing code every day, dozens of MRs open per day, and all I always needed was a very limited set of what git is capable of (git commit, git co, git st, git merge/rebase, git log). To find bugs, I use "bisect but visually" (I usually use jetbrains IDEs, so I just go to the git history, and do binary search in the commits, displaying all the files that were affect…
I have never understood the claim that git is hard. the docs are good and there are plenty of examples online. feels the same when people say, "jq is hard i use python instead" like ok
Earlier quoted context omitted.
I have never understood the claim that git is hard. the docs are good and there are plenty of examples online. feels the same when people say, "jq is hard i use python instead" like ok
I am (was) a git expert. I’ve written a git implementation. I’ve used it since shortly after it was first announced. Git has lots of sharp edges that can get hairy or at least tedious really rapidly. You have to keep a ton of random arcana in working memory at all times. And a bunch of really useful, lovely workflows are so much of a pain in the ass that you don’t even conceive of doing them. I learned jj in one day…
I'm not a welder or a metalworker, but I do know how to weld. I use a welder a handful of times per year when I need/want to. Welding is dangerous, and achieving excellence is a difficult and long road. But I can use the same tools as a pro and still get a few pieces of metal stuck together without having to relearn and restudy the whole system each time something goes wrong.
I haven't used jj in anger yet, but I think it might at least be approaching that style of developer tool.
I've worked in huge repos with hundreds of developers pushing code every day, dozens of MRs open per day, and all I always needed was a very limited set of what git is capable of (git commit, git co, git st, git merge/rebase, git log). To find bugs, I use "bisect but visually" (I usually use jetbrains IDEs, so I just go to the git history, and do binary search in the commits, displaying all the files that were affect…
I have never understood the claim that git is hard. the docs are good and there are plenty of examples online. feels the same when people say, "jq is hard i use python instead" like ok
Earlier quoted context omitted.
> So, what am I missing? Here: git rebase is slightly broken in conflict handling. It can be made simpler to understand with jj.
What if we don't use git rebase at all? What does jj have to offer us?
Earlier quoted context omitted.
We don't use rebase at all, it's forbidden. Since jj does not have branches, it sounds like we are forced into the rebase environment? With git, I can push my changes without a force, regardless of what the work I build on does I think jj's biggest challenge to adoption or replacing git is not technical, it's that it requires people changing how they think about and perform a very central act of their non-coding acti…
> Since jj does not have branches, it sounds like we are forced into the rebase environment? No, I tend to use rebase by default (because I like linear history) so its the language I use but it's equally valid in both git and jj to merge via merge commits instead of rebases. While JJ doesn't have a concept it calls branches, it has all the same semantic power of branches. The difference here is just that git insists…
Earlier quoted context omitted.
> Since jj does not have branches, it sounds like we are forced into the rebase environment? No, I tend to use rebase by default (because I like linear history) so its the language I use but it's equally valid in both git and jj to merge via merge commits instead of rebases. While JJ doesn't have a concept it calls branches, it has all the same semantic power of branches. The difference here is just that git insists…
I mean, jj definitely has branches, they're just anonymous.
Earlier quoted context omitted.
> their own in-house distro Not really, it is just a well known outside distro plus internal CI servers to make sure that newly updated packages don't break things. Also some internal tools, of course.
Relative to what the rest of the world does, that is maintaining your own in-house distro. It's downstream of Ubuntu (unless that's changed) but it's tweaked in the ways you've noted (trying to remember if they also maintain their own package mirrors or if they trust apt to fetch from public repositories; that's a detail I no longer recall).
In 2018, Google replaced Goobuntu with gLinux, a Linux distribution based on Debian Testing