Jujutsu: a new, Git-compatible version control system
Jujutsu is a Git-compatible distributed version control system originally started as a hobby project by Martin von Zweigbergk in 2019. It is intended to be a simpler, more performant Git replacement. Jujutsu boasts a radically simplified user interface and integrates ideas from patch-based version control systems for a novel take on resolving merge conflicts. It is written in Rust and available under an Apache 2.0 license.
Unlike some other projects that build on top of Git — such as
Gitless or
Magit — Jujutsu is designed with eventual
independence from Git in mind. Jujutsu's own code is written in Rust, but it links
libgit2 (a C implementation of core Git features)
to interact with Git repositories. Jujutsu can either use a Git repository as its
storage backend, or use its own custom storage backend. The native
backend is not yet ready for serious use.
The project's README
states: "The backend exists mainly to make sure that it's possible to
eventually add functionality that cannot easily be added to the Git
backend
".
Von Zweigbergk, who is now paid by Google to work on the project,
plans to extend Jujutsu with a backend for Google's internal cloud-based
storage (as shown in
the slides
of his
2022 Git Merge talk). Jujutsu is designed to fetch information from its storage backend
lazily, specifically to support large
monorepos
like the one used at Google.
For now, Jujutsu seeks to be usable as a Git replacement for simple, everyday workflows. The core contributors use it to work on the Jujutsu repository without significant problems. However, the project still lacks support for some of Git's more esoteric features, including submodules, partial clones, shallow clones, multiple work trees, sparse checkouts, signed commits, and Git Large File Storage (LFS).
Also difficult to do without is the lack of support for hooks — external scripts that can be called at different points during Git's operations. Git used to have many components written as shell scripts, making it easy to add hooks to be called for various operations. Even though many core components have been rewritten in C, Git has maintained backward compatibility around when hooks will be invoked. Git contributor Elijah Newren cited this as one of the difficulties with improving the performance of Git's rebase operations.
There are plans to add support for a subset of hooks to Jujutsu, but this is more difficult than it might appear. Unlike Git, Jujutsu aims to have all operations work directly against the underlying storage, with any necessary changes rendered to the filesystem afterward. This choice allows Jujutsu to work with the same commands in a bare repository, and to perform more efficient in-memory transformations without touching the filesystem, but makes it challenging to support hooks. Since hooks are external programs, they usually expect to interact with a repository through the filesystem, which is impossible when operations are performed directly in memory. This lack also means that Jujutsu has no configurable merge strategies.
Jujutsu's from-scratch design with performance in mind means that it can complete rebase operations significantly faster than Git can. Jujutsu's superior performance has driven Elijah Newren and Christian Couder to propose a new "git replay" command that makes rebase operations faster. It does this partly by adopting reasonable defaults (such as making the equivalent of "--reapply-cherry-picks" the default), and partly by avoiding walking the commit graph as much as "git rebase" does. Walking the commit graph to obtain extra information that would reduce the number of required merges was a reasonable performance optimization when "git rebase" was first introduced, but now other performance improvements to merging have made the tradeoff not worth it for most situations. While "git replay" offers a significant improvement over "git rebase", it still lags behind Jujutsu's rebase operation.
Features
Jujutsu differs from Git in several other ways. The most striking is perhaps the removal of the index. In Jujutsu, the working tree is represented directly by a real commit. Editing that commit can be done directly by editing the files on disk, with no need to stage or unstage them. Running a Jujutsu command will copy any changes from the filesystem into the working commit before taking other actions. To finalize the commit and stop editing it, the user simply creates a new working commit on top of the old one with "jj new". Since the working copy is a commit like any other, Jujutsu doesn't need any equivalent of commands that modify the index, such as "git add" or "git stash".
Most commands in Jujutsu affect the working copy by default, but can perform the same operations on other commits by specifying their revision. For example, "jj describe" is used to alter the commit message of a commit. If invoked without any other arguments, it alters the commit message of the working copy. If invoked with another revision, it alters the commit message of a historical commit and transparently rebases everything that depends on it. Other commands such as "jj move", that moves a diff between commits, work on the same principle.
Automatically rebasing commits like this, while convenient, creates its own set of problems, especially when rebasing commits that have already been sent to other developers or a centralized server. To ameliorate the many conflicts that implicit rebases create, Jujutsu uses an idea from patch-based version control systems such as Darcs and Pijul. These systems allow one to commit conflicts and resolve them later. This does not involve committing the textual conflict markers, but rather a representation of the conflicting trees. Then those conflicts can be resolved in later commits.
Von Zweigbergk gave an example of how this works. Consider a Git history that looks like this:
o---*---o topic
/
o---o---o---*---o---o main
The two commits marked with asterisks have conflicting changes. The author of this code would like to merge the main branch into the topic branch, resolve the merge conflicts, and then later rebase the topic branch onto the main branch to eliminate unnecessary merges. With Git, the author could use "git rerere" to remember the conflict resolution and replay it later while rebasing. With Jujutsu, they could simply rebase on top of the main branch and fix the conflict, resulting in this history:
o---*---o---+ topic
/
o---o---o---*---o---o---o---o main
Now if the author inspects this history with "jj log", they will see that the commit marked with an asterisk on the topic branch is marked as having a conflict, as is the commit after it. The commit with a plus is the one that resolves the conflict. Later, if they want to clean up their history, they could move the conflict resolution into the original problematic commit and obtain a clean linear history like so:
jj move --from <plus commit> --to <star commit>
By storing conflicts in this way, Jujutsu can ensure that merges and rebases always "succeed" — they might just leave some conflicted trees that can be dealt with afterward. Conflicted trees can be committed, checked out, and edited like ordinary trees. Conflicted files are rendered with textual conflict markers like the ones that Git adds after a failed merge, but are represented internally as a series of diffs. One use case for which the approach of storing conflicts might not work as well is bisecting, since conflicted commits may not build correctly. There are plans to add bisection support, but the implementation is not yet finalized. One advantage of representing conflicts in this way is that Jujutsu doesn't need an equivalent of "git rebase --continue". Every rebase and every merge completes in one command, without stopping in the middle to ask for assistance, as Git is prone to do.
This permits Jujutsu's final headline feature: the operation log. Like Git's reflog, the operation log tracks previous states of the repository. Unlike the reflog, the operation log treats rebases or other complex operations as single atomic entries. The operation log then powers the "jj undo" command that can undo the effects of any other Jujutsu command.
This combination of fast, atomic, pervasive rebases provides a different vision of how to manage a repository. Whether Jujutsu's user interface is ultimately an improvement remains to be seen, although the radical simplicity of its design is promising.
Trying Jujutsu
While Jujutsu has not yet been packaged for most distributions (the exception being NixOS ), readers interested in trying it can download a precompiled version or compile the source. Cloning an existing Git repository for use with Jujutsu is done with "jj git clone". Cloning Git repositories with many refs can be slow, and the Jujutsu documentation warns that hybrid repositories that use Git and Jujutsu together may see Jujutsu commands run slowly because of the need to check Git refs for changes between commands.
The command-line interface is fairly similar to Git, except for the omission of commands to manipulate the index. One difference to be aware of is that "jj log" only shows local commits by default. To show the full history of the repository, one uses:
jj log -r 'all()'
The Jujutsu documentation has a thorough introduction and a comparison between Git commands and Jujutsu commands.
Conclusion
Jujutsu has come a long way in only a few years. It is already usable for working on projects that don't need more complex Git features, and offers a more consistent user interface, better performance for some operations, and an interesting approach to conflict resolution. With ongoing support from Google, it seems likely that Jujutsu will continue to see active development.
At the same time, Jujutsu lacks some of the features that make Git flexibly adaptable to different use cases, such as hooks or submodules. Importing many refs from Git remains slow, and there are still some rough edges around getting a repository initially set up. Whether Jujutsu will come to be used outside of Google depends on if its simplified interface wins out over its reduced applicability to uncommon workflows.
Posted Jan 19, 2024 20:47 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (7 responses)
How many months do we give it until Google kills it? Taking bets
Posted Jan 19, 2024 20:53 UTC (Fri)
by willy (subscriber, #9762)
[Link] (5 responses)
(Is Bazel dead yet? Please please please ...)
Posted Jan 19, 2024 22:56 UTC (Fri)
by tux3 (subscriber, #101245)
[Link] (3 responses)
It's now a mix of everything, with Bazel as the latest and greatest, but seems a good bet that they won't be able to get rid of any of these build systems for many more years.
I can't imagine them starting _yet another_ migration to replace Bazel!
Posted Jan 20, 2024 15:41 UTC (Sat)
by khim (subscriber, #9252)
[Link] (2 responses)
This depends on your definitions of won't be able to get rid of any of these build systems, I guess. Someone in Google realized that having three build systems is a madness, and the decision was to nix bazel… except kernel build would remain on Bazel because kernels are not built when Android is build, they are built separately and dropped into AOSP as prebuilts.
Posted Jan 20, 2024 15:53 UTC (Sat)
by tux3 (subscriber, #101245)
[Link]
Oh..that was not what I expected!
Then I suppose the documentation may need an update:
>Google has a multi-year plan to migrate the Android Build system to Bazel. This migration is in early stages, but some changes can be made to current build files to start preparing them for Bazel.
Posted Jan 20, 2024 17:00 UTC (Sat)
by khim (subscriber, #9252)
[Link]
I guess they still don't know what to write there. Because they still want to have bazel, in the end, just the decision was to stop using three build systems simultaneously. So either all makefiles should be converted to soong first, or, at least, they should be convertable to bazel, at least in theory. The actual path to that nirvana where only bazel exists is still not determined, but the path where there are three build system and none can be removed because every one of three have something unique that other two couldn't do… that was nixed. Conversion from soong to bazel is easier than doing something to the mess that's in these remaining Makefiles thus they went back to Plan A: first convert everything from Make to Soong, then decide how to adopt bazel.
Posted Jan 22, 2024 20:48 UTC (Mon)
by scottlaird (subscriber, #96306)
[Link]
Or, at least, blaze won't die, not for many years. Google depends on it for *everything* internally. It's deeply, deeply baked into a lot of infrastructure, and replacing it would probably be a decade-ish long project.
Posted Jan 20, 2024 0:32 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link]
(The above is my personal opinion, don't attribute it to my employer, yadda yadda yadda.)
Posted Jan 19, 2024 22:05 UTC (Fri)
by josh (subscriber, #17465)
[Link] (95 responses)
> In Jujutsu, the working tree is represented directly by a real commit.
makes a lot of sense, and I like the idea that everything is "just" a commit. In particular, while it's a mental shift, the idea of "you're always working on a commit, and at some point you declare that commit finished and create a new one on top" is a really good one.
There are a couple of things that make me not consider it, one likely fixable and one that makes it dead in the water.
First, it seems like they dismiss some workflows as unimportant. For instance, in their table of equivalents, https://martinvonz.github.io/jj/v0.13.0/git-comparison/#c... , "git stash" is shown as "not needed". It very much *is* needed if you need to temporarily work on the last checked-in version. I'm *guessing* there's an equivalent by checking out the parent commit (the commit above the working-tree commit), but the fact that it's just dismissed as "not needed" does not give me hope that they empathize with people who *actually do use it* and want to know how to do the equivalent.
Second, I thought about contributing a fix to that table, and then I saw the contributing requirements:
> Contributor License Agreement
Nope, not happening. Nobody should adopt this until it's been freed from that requirement, either by getting the project to remove it or by establishing a version of the project that takes contributions without that requirement.
Posted Jan 19, 2024 22:41 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (32 responses)
I make edits all over the code and it's not until later after doing much more work that I understand the changes I am making sufficiently to decide how to construct a correct stepwise set of commits from them.
Posted Jan 19, 2024 23:00 UTC (Fri)
by arxanas (guest, #169225)
[Link] (28 responses)
jj actually has many more ways of slicing and dicing commits than Git does. You can use I implemented the now-default TUI for jj's commit editing, but you can use any difftool. It has a similar interface to `hg commit -i`. The previous default was
Posted Jan 19, 2024 23:58 UTC (Fri)
by roc (subscriber, #30627)
[Link] (26 responses)
In git, the staging area is OK for the simple case where the changes you want to split up across commits are the last thing you did. But when you have already-committed changes that you decide to split up further, git is not helpful... temporary branches, reset, etc.
And of course once you have nice tools for splitting and otherwise mutating commits, the staging area *is* worthless unnecessary complexity.
Posted Jan 20, 2024 22:12 UTC (Sat)
by madscientist (subscriber, #16861)
[Link] (24 responses)
?? ITYM interactive rebase. Git definitely has help for this; I never use temporary branches or reset to chop commits.
But as I mentioned before I use Magit. Much of the workflow that is clunky through the Git CLI, including interactive rebase, is breezy using Magit.
Posted Jan 20, 2024 22:21 UTC (Sat)
by apoelstra (subscriber, #75205)
[Link] (23 responses)
In complicated cases I can imagine using temporary branches in step (c) or before step (a) to avoid losing work.
Is there a way to do this without the reset step?
Posted Jan 20, 2024 22:38 UTC (Sat)
by madscientist (subscriber, #16861)
[Link] (20 responses)
I suppose under the covers Magit does need to use a reset operation (your step (b)) as part of "unstaging" all the changes in the commit-to-be-edited.
If I have a "complicated case", I usually just make more smaller commits in this interactive rebase, then after this interactive rebase is finished I start another one and move the smaller commits to where I want them and squash them. Magit makes interactive rebase so simple that it's easier to just run it multiple times than to get complicated and try to do it all in one go. I can't think of a situation where I'd need a temporary branch.
Posted Jan 21, 2024 5:01 UTC (Sun)
by intelfx (subscriber, #130118)
[Link]
That's exactly the semantics of a git (mixed) reset.
Posted Jan 21, 2024 5:49 UTC (Sun)
by roc (subscriber, #30627)
[Link] (18 responses)
You don't need the staging area if you just move changes directly from the working tree to commits. Hg has that, and even git can do that with "git commit -p".
Jujutsu (which I haven't used, but sounds excellent) takes the next step and gets rid of the working tree as well as a distinct concept. It's just the "working commit", so you can use the same commands to move changes from that commit to other commits that you would use to move changes between any pair of commits. Great!
Posted Jan 22, 2024 2:50 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (1 responses)
With all due respect, you sound like you're not a magit user :-)
Magit presents everything as diff hunks, so I don't really think in terms of "trees" when using it (every day). I just move hunks around freely. I totally understand how the staging area can confuse a lot of people; I frequently use the command line too. But Magit makes it incredibly natural to use. Ask a friend for a demo?
Posted Jan 22, 2024 10:02 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Having used Magit, a good description of the way it handles things is: "the presence of three types of tree - working copy, index, and commits - is confusing to users. Unify all three into one type of tree, and hide the difference so that as far as a Magit user is concerned, it's all just commits". They do this because commits are the fully featured type of tree, and it's trivial to convert any operation on any type of tree into "turn the tree into a commit, operate on the commit, turn the new commit back into a working copy or an index".
Jujutsu makes Magit's implementation a lot simpler, because instead of Magit having to balance all three types of tree internally, and work out the "correct" way to implement any operation for you, it can instead only implement operations on commits, and get the same advantage. It also doesn't cost any Magit features, since Magit already works this way from a user perspective.
Posted Jan 22, 2024 14:53 UTC (Mon)
by madscientist (subscriber, #16861)
[Link] (14 responses)
It might just be a matter of how you look at things. I treat the index as a way to construct a commit. I expect this is how it was designed to work. So in my mind I have (a) work I'm doing that is not committed, (b) a staging area (usually empty) that I use to construct a new commit from either all or, very often, just selected parts of the work I'm doing, and (c) already committed code.
So yes it is three things but they are all on a continuum of work and it's pretty simple to understand. IMO of course.
I know that as CS folks we like to use a single model for everything, but the reality is that sometimes it's easier to understand things if they have distinct models. I haven't used Jujutsu so I can't say whether it really is simpler to treat everything as the same thing, or not.
I can say that based on the replies here showing command line operations, while Jujutsu may be simpler to use than the Git CLI (I mean... yeah) it seems to me that Magit is simpler than both of them :)
Posted Jan 22, 2024 15:08 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (8 responses)
Note, though, that Magit makes things work by saying that you're always dealing with hunks in a commit - it hides the differences between the working copy, the index, and your forest of commits from you. If Magit makes things simpler, then it does so by reducing the number of things you need to juggle in your head by two - get rid of "working copy" and "index" as separate entities.
Posted Jan 22, 2024 19:25 UTC (Mon)
by madscientist (subscriber, #16861)
[Link] (7 responses)
I don't agree with this.
Staging is visible and important in Magit. It's up-front and clearly distinct. The Magit status buffer shows different sections for the unstaged files, the content of the staging area, and a list of recent commits. And staging files vs. hunks is just a difference in granularity; it doesn't use a separate workflow.
Maybe you mean, it hides the differences in the way you work with the different parts? That might be true to some extent. But it definitely doesn't try to pretend that they are all the same thing; it's more you don't have to remember the various commands and options. For example, it's clear in Magit that neither unstaged or staged hunks are "the same as" a commit.
Posted Jan 22, 2024 21:45 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (6 responses)
Behaviourally, having used Magit, the staging area behaves exactly the same way as a commit does - it's something you can stage hunks to, and aside from naming it differently, it's possible to make Magit treat the staging area exactly the same as a commit.
Aside from it being given a funny name, it's functionally a commit - you don't get different commands for it, or different options, or different behaviours, or indeed anything to justify treating it specially.
Posted Jan 22, 2024 22:07 UTC (Mon)
by madscientist (subscriber, #16861)
[Link] (5 responses)
In addition to staging hunks into the staging area, which could be considered equivalent to amending a commit, you can unstage them again, delete them completely, etc. That is not possible with commits: the only way to modify a commit in that way is to go through a rebase operation.
It's actually more accurate to say that the staging area behaves exactly the same way that the unstaged changes area, except that you can create a commit from the staging area and you can't create a commit directly from the unstaged changes. Other than that staged and unstaged work pretty much identically in Magit, and are treated very differently than commits.
I understand that there could be a different implementation that uses a real commit instead of staging and hides all the work to "unstage" hunks behind the scenes, but that's not how it works and it's not how the mental model is presented.
Posted Jan 23, 2024 10:14 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (4 responses)
Hmm. The version of Magit I've experimented with allowed me to unstage hunks and delete them from commits, and allows me to create a commit directly from the unstaged changes. Under the hood, it did a rebase operation in the process, but from my perspective it was completely transparent; Magit hid this from me.
From my perspective, Magit is completely hiding the staging area from existence - there's something that behaves just like any other commit, and is called the "staging area", and there's unstaged changes which also behave just like any other commit, but are also present in the working copy on disk, but otherwise Magit makes the differences go away, and just works in terms of moving hunks between the various places in the forest of VCS commits I could see. Perhaps you've configured Magit to be more explicit about the staging area? My configuration for Magit is quite large, and has built up over the last decade.
Posted Jan 23, 2024 15:48 UTC (Tue)
by madscientist (subscriber, #16861)
[Link] (3 responses)
It's true that you can ask to "unstage" a hunk in a commit, but what happens is that Magit will add a staged change that reverts that hunk, then an unstaged change that adds it back again. You can choose which one you want and if you want to keep the revert you can apply that change either by adding a new revert commit or by using Magit's fixup facility (which makes a commit then uses rebase to squash it into the original commit, but done for you).
It is pretty different from a UI perspective to unstaging a hunk from the staging area, which simply moves it back to unstaged as if you'd never staged it at all.
Posted Jan 23, 2024 15:51 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (2 responses)
I've never seen that UI behaviour from Magit; you have it set up differently to me (I copied someone else's config ~10 years ago to get started, and stuck with that). I don't ask it to unstage a hunk; I ask it to move hunks between locations, and the staging area is just one of those locations. I can literally ask Magit to move a hunk straight from the commit to the unstaged work, or to the staging area, or to another commit, and it works out what sequence of operations makes that happen for me.
In this setup, there's no need for the staging area - it's just a commit with a funny name - as all the "move hunk" operations work just as well between two commits as they do between a commit and the staging area.
Posted Jan 26, 2024 16:44 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (1 responses)
I don't know what keys/commands you are using to get the behavior you see, but I'm using bog-standard Magit with all the basic settings and very little customization. The key I use to unstage a hunk is "u". If the cursor is on a hunk that's been staged, then the hunk is moved back to "unstaged changes" by pressing that key. If the cursor is on a hunk in a commit (I view the hunks in the commits by selecting a commit in my "Recent Commits" list then pressing ENTER to see its changes) then I get the behavior I described previously.
Perhaps you are entering some other "commit editing mode" in Magit, that I'm not using. It sounds cool! But in any case there is a clear difference in the UI behavior between staged hunks and hunks in commits.
Posted Jan 30, 2024 12:32 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Jan 22, 2024 16:49 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (4 responses)
Problem is, it's your *opinion*. Which you're welcome to.
But as someone who doesn't use git much, the index/staging to me is extremely confusing. And while I'm slowly trying to get into it, despite working with computers pretty much my entire career I've always avoided "software house" environments; with one exception spending it in "end user computer departments" or, as now, being the programming/computer guru in an end-user department.
I view things through end-user eyes. And as you'll know from my database rants, I simply cannot understand why main-stream computing is just so damn complicated! I quite get you don't see it that way, but probably that's all you've ever known. Just like end-user is pretty much all I've ever known...
Cheers,
Posted Jan 22, 2024 18:14 UTC (Mon)
by madscientist (subscriber, #16861)
[Link] (3 responses)
Also I'm not talking about Git. I'm talking about Magit. Whether you find the staging capability of Git confusing or not is irrelevant to my point, which is that Magit makes it clear why staging exists and what it's good for and how to use it, and makes it easy to use. And, Magit doesn't hide staging or pretend it's just a different way to talk about commits: it's a separate thing, which is integral to the workflow.
I don't really know what you mean by "software house environments"; Emacs is not exactly specialized or with limited availability.
Just to remind there's no such thing as a "programming/computer guru" who is not also an end-user. We are all end-users.
As for why it's complicated, well, some things are just complicated and the only way to simplify them is to remove functionality. Obviously it would be great to have a simple interface to support simple uses and save the complexity for more advanced users, and it would be great if the complex uses could also be made simpler, but to paraphrase Pascal "I am sorry for the complexity of the interface, I have not the time to make it simpler".
Posted Jan 22, 2024 22:00 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (2 responses)
"Limited availabity" does not mean "in widespread use". I don't think I've ever known a regular user of Emacs apart from my brother.
> Just to remind there's no such thing as a "programming/computer guru" who is not also an end-user. We are all end-users.
You miss my point. All programming/computing gurus are end users, true. But not all (indeed, VERY FEW) end users are programming/computing gurus. In this environment (LWN) I may not be anything special, but *both* in my work and home environment I am a goliath amongst midgets.
In that sort of environment, where do I learn the things, that to you are second nature?
Cheers,
Posted Jan 22, 2024 23:47 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (1 responses)
Yes, but perhaps Emacs would be in more widespread use if more people knew about Magit (and org-mode, and all the other goodies that make Emacs so unique and incredibly powerful).
Posted Jan 23, 2024 10:29 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
I've already said I'm very much ALONE amongst my peer group of being a computer expert. MY peer group (which is far more representative of the general workforce than yours) wouldn't have a clue what a SCCS is if you hit them over the head with it! Even less a DVCS!
I don't have a problem with other peoples' opinions (we can all disagree quite friendlily?) UNTIL they assume their opinions apply to the majority. Guess what! We are a VERY SMALL minority!
Cheers,
Posted Jan 22, 2024 20:02 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
BTW: https://lwn.net/Articles/949963/ (in "Evans: Confusing git terminology", Nov. 2023
> The staging area is unnecessary complexity. It's completely superfluous.
24 answers :-)
Posted Jan 21, 2024 5:39 UTC (Sun)
by roc (subscriber, #30627)
[Link]
Posted Jan 22, 2024 9:44 UTC (Mon)
by geert (subscriber, #98403)
[Link]
(a) Interactive rebase to the commit in question (called "sha1" below),
To split in more parts, have more b/c/d steps in between a and e.
Posted Jan 21, 2024 9:15 UTC (Sun)
by jengelh (subscriber, #33263)
[Link]
Works for me, and complexity is reasonable enough to not warrant wrappers like stgit.
$ git log --oneline
Posted Jan 20, 2024 22:23 UTC (Sat)
by madscientist (subscriber, #16861)
[Link]
FYI the way I usually work is edit edit edit ... oh, this hunk and that hunk and this other one over here are really part of a different commit: pop up a Magit buffer, select those various hunks into staging, make a commit from them. Edit edit edit, rinse repeat.
After a while you have 10-15 (or more) "partial commits" that you want to turn into 2 or 3 or 4 "real" commits. Pop up a Magit buffer and enter interactive rebase: move the partial commits around into the right order and next to each other and squash the parts together and make a real commit message. If you accidentally have too much stuff in a commit mark it for edit and split it.
Then you're done.
Posted Jan 19, 2024 23:04 UTC (Fri)
by thoughtpolice (subscriber, #87455)
[Link] (1 responses)
The idea isn't really that the index is useless; quite the contrary. I chop commits up with far more power than I did before. Rather, it's just that you can represent these multiple concepts with a single design primitive. So, the index and the stash and those 'wip' commits we all put onto a quick temporary branch -- they're all the same thing now. They use the same vocabulary, the same verbs and nouns in the user interface, et cetera.
If you live in Emacs/Magit though, I suspect prying yourself away from it will be hard, even despite that. :)
Disclosure: I am a contributor to Jujutsu (not Google or otherwise work affiliated.)
Posted Jan 20, 2024 22:13 UTC (Sat)
by madscientist (subscriber, #16861)
[Link]
I'm looking forward to Emacs Majutsu!
Posted Jan 25, 2024 7:29 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link]
Posted Jan 19, 2024 22:48 UTC (Fri)
by arxanas (guest, #169225)
[Link] (50 responses)
The stashing explanation could certainly be improved. Regarding stashing itself, there's simply no further deliberate operations you need to do to save the work, as the working-copy commit is the stash. You would just switch to another commit as normal — which is the same workflow as for non-stashed work. My guess is that's the mindset under which "not needed" was written there. When you want to return to your stashed work, you can do so by inspecting the log to find its ID and then switch to that. You would have to deliberately throw away your work with We could update the table entry to
Posted Jan 20, 2024 0:16 UTC (Sat)
by josh (subscriber, #17465)
[Link] (49 responses)
Yes, I think showing jj new @- in the table would help people who have the use case that currently motivates git stash. And the model does seem reasonable; I do it already with git sometimes, by doing git commit -am WIP and then checking out something else.
Any way you can do something about the CLA? Either internally at Google, or by doing a bit of jujutsu :) by having an external contributor move the project to an external shared home that isn't owned by Google (e.g. https://github.com/jj-vcs/jj)?
Posted Jan 20, 2024 0:33 UTC (Sat)
by thoughtpolice (subscriber, #87455)
[Link] (48 responses)
I feel it's important to note that Google's Open Source CLA doesn't actually transfer ownership of anyone's copyright or ownership of the changes; they remain under the Apache 2.0 license, and you still own them (unlike the CLAs used by HashiCorp or the FSF, which transfer ownership.) That's better than the alternative but I admit it's a thorn, in particular there is a separate corporate/organization CLA, so it can and does honestly get in the way of some places to a reasonable extent (smaller institutions like universities that may have to review it, but they probably aren't equipped to really care so it just doesn't happen). I'm not sure if the distinction matters to you but feel it's important to mention with stuff like HashiCorp in recent memory.
Disclosure: I'm a contributor to Jujutsu, but I don't work for Google or anything like that.
Posted Jan 20, 2024 2:00 UTC (Sat)
by josh (subscriber, #17465)
[Link] (47 responses)
I hope that this issue can be fixed, so that jujutsu (rather than a future successor to it) can become a reasonable choice for Open Source usage.
> I'm not sure if the distinction matters to you but feel it's important to mention with stuff like HashiCorp in recent memory.
It does not, no.
Posted Jan 20, 2024 15:59 UTC (Sat)
by khim (subscriber, #9252)
[Link] (46 responses)
Sure. If someone else pay the principal developer. Do you volunteer to hire Martin von Zweigbergk and pay for the development of Jujutsu? Open Source folk are usually perfectly happy to use stuff made by Google. It's Free Software guys who think they are entitled to ask for help and then demand that help would be offered on their terms. The big question is whether Jujutsu would be adopted inside of Google. If that would happen then it would be much harder to cancel it.
Posted Jan 21, 2024 2:45 UTC (Sun)
by Conan_Kudo (subscriber, #103240)
[Link] (45 responses)
This is not only unfair, but wrong. Many "Open Source" folks are unhappy about how Google runs their projects, but like everyone else, we don't really have much choice sometimes on whether we can avoid it.
Posted Jan 21, 2024 4:03 UTC (Sun)
by khim (subscriber, #9252)
[Link] (44 responses)
People may dislike CLAs and thus may keep patches to themselves, but only free software zealots are postulating that others have to change how they are doing things or else they wouldn't even touch something. Please read again: josh says that CLA have to go for merely for the Open Source usage (not development!).
Posted Jan 21, 2024 4:11 UTC (Sun)
by Conan_Kudo (subscriber, #103240)
[Link] (4 responses)
Posted Jan 21, 2024 4:26 UTC (Sun)
by khim (subscriber, #9252)
[Link] (3 responses)
Well, FSF was asking contributors to sign weird documents when they want to contribute a fix or improvement for years. In fact it's worse with FSF: while Google only asks for license and patent grant, FSF demands that you pass over all rights to what you are creating to them! Sure, they give you a license to use your own code, but still… that's passing all the rights compared to just grant of the license… Yet, somehow, animosity is reserved specifically just for the Google? Paint me unimpressed.
Posted Jan 21, 2024 8:38 UTC (Sun)
by josh (subscriber, #17465)
[Link] (2 responses)
Posted Jan 21, 2024 15:05 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
I know I don't understand the kernel's setup, and I gather there's quite a bit of cargo-culting there, so it's quite a hard problem to solve, but it's trying to get a cast iron guarantee that the person contributing a fix actually has the right to contribute it.
I certainly get the impression that certain sub-system maintainers demand certificates (or they won't merge a patch) from people who clearly have no authority to grant them, so ...
The only way to securely fix the problem is to have something like a CLA where a lawyer quizzes you and says "you DO have the right to contribute this patch, don't you?".
Cheers,
Posted Jan 21, 2024 21:29 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted Jan 21, 2024 14:26 UTC (Sun)
by apoelstra (subscriber, #75205)
[Link] (37 responses)
Maybe I'm misunderstanding you, but this seems wrong. People boycott stuff all the time. Sometimes to try to send a message, but often simply because they're trying to minimize the inconvenience in their lives.
For example sometimes I'll try to sign up for a service and they have weird password constraints on their signup page. If there's a similar competitor I'll just shrug and switch to that. As a security researcher I do have some moral feelings about how there shouldn't be such constraints, but life is short and I push those aside in favor of a simple practical "I'll use the site where I can signup in one step, vs the one where I need to edit the output of my password manager, probably only to find more hoops to jump through once I'm past this step".
A CLA is a similar thing. It's a pain in the butt so I won't do it. I would guess that most people who refuse to sign CLAs feel the same way. And this applies equally to the FSF or Google.
(Having said that, if Google had a CLA where you actually did transfer copyright to them, I can see people balking at the idea that they'd be "working for free" for a for-profit company. But it sounds like that's not what's happening here, and it's not what I see people complaining about here.)
Posted Jan 21, 2024 20:25 UTC (Sun)
by khim (subscriber, #9252)
[Link] (36 responses)
Sorry, but no. So when I'm skipping Kohlrabi in the supermarket because I don't like it that's called boycott? Sorry, but I don't think so. There's world of a difference between ignoring things you don't like and actively demanding from others certain things. Yes. But not everyone stops using things just because there's CLA which you need to sign to contribute. In fact I know of precisely zero people who are using neither gcc nor clang (and both projects required CLAs till very recently). It's one thing to say that you wouldn't contribute to Jujutsu till CLA would be removed. It's weird that few clicks on the web site are that awful that you would refuse to contribute because of them, but whatever. There are legal consequences and you may want to avoid them It's entirely different thing to demand that Google should stop using CLA or else your wouldn't even use that product.
Posted Jan 22, 2024 10:49 UTC (Mon)
by spacefrogg (subscriber, #119608)
[Link] (34 responses)
Whining about free software programmers "demanding" things, when, in fact, Google is demanding something, a CLA in return for other people's mental output. And they have every right to. Now, those "demanders" of yours, they just won't contribute and it will deminish the input of bright ideas that jujutsu might have had.
How you put that moral dilemma on the shoulders of people wanting to contribute their efforts under their terms, is beyond me. What do you expect how the world should be run? Of course I negotiate the rules for my own contributions! What else should I do instead?
Nobody should contribute to code that is owned by a company for free. Under no circumstances. This is a) distorting the labour market of programmers and b) should constitute tax fraud on behalf of google. They should be obliged to pay and care for their employees. (For all(!) of them!)
Posted Jan 22, 2024 11:25 UTC (Mon)
by khim (subscriber, #9252)
[Link] (33 responses)
Not only they wouldn't contribute, they would whine a lot about how they couldn't use things if there are JavaScript involved, about how they would fork the project if someone would do things differently from how they like (read the whole sentence, please, it's not long: I hope that this issue can be fixed, so that jujutsu (rather than a future successor to it) can become a reasonable choice for Open Source usage. They automatically assume jujutsu would fail just because of CLA and there would be some king of successor, for crying out loud! Sure, jujutsu may still easily fail, but that wouldn't happen because of CLA, that's for sure. I know how the world is run, that's the issue. Free Software zealots don't know that (or, more precisely, refuse to accept that knowledge). How about creating these oh-so-valuable contributions? Patches, fork, whatever. Then you may decide whether they are valuable enough to demand something. Sometimes this even works (like happened with Go-oo), but most of the time your contributions would either be ignored or duplicated instead. Don't throw around an empty threats if you don't actually plan to act on them. If you have no real desire or plan to create these oh-so-valuable contributions then don't whine about CLAs, once you'll have them you may create a fork or do something else. And now you go again and decide about other people what they are supposed to do. If you don't like CLAs, or don't like corporate projects or don't like some other things then do something about that. And they should stop giving Jujutsu away for free because then it's hard to make living from the Bitkeeper. Yawn. I heard that before. Please, make something valuable and then discuss your plans about doing something with it. Nobody is interested in hearing what you wouldn't do. And nobody would change anything till you would convincingly show that change benefits them (not just you).
Posted Jan 22, 2024 12:24 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (22 responses)
> > They should be obliged to pay and care for their employees. (For all(!) of them!)
I'm planning to write into my code for Scarlet, a royalty-free licence for Ladybridge software to use any and all of my Scarlet code. Doing exactly what you say I shouldn't - giving a company a free pass!
The reason is dead simple. They donated the original code base that became Scarlet. Why *shouldn't* I donate back, IN GRATITUDE, if I want to!
(There's another reason too - I'm learning the hard way why companies don't like Open Source software). If Scarlet does collapse - and I have no intention of letting it do so - all the users will have the CHOICE of moving to the commercial version if they want to. I'M PROTECTING MY USERS.
Cheers,
Posted Jan 23, 2024 16:04 UTC (Tue)
by spacefrogg (subscriber, #119608)
[Link] (21 responses)
Let me repeat, it is bad for society if companies are allowed to give stuff away for free, because this creates a situation where people easily get dependent on the free stuff. At some point it is (wonders of the capitalism) not free anymore, but people still depend on it. We have already discovered this to be a worse situation than enforcing proper sales rules right from the beginning.
I don't understand how programmers really think they are inventing something radically new, here. No, "free stuff" has long been discovered before the first computer program was ever written. And there are rules for how to deal with that as a society, for a reason. All this is really not that hard to comprehend, once you replace MY_FAVORITE_SW with a physical product.
Creating a dependence on a company-owned product by giving it away for free is not okay.
Posted Jan 23, 2024 16:41 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (18 responses)
> Companies are not people!
Who says? I know the guy pretty well (well, as well as you can know someone over the internet).
> Let me repeat, it is bad for society if companies are allowed to give stuff away for free,
Okay. Let's ban free stuff. Let's ban all Open Source software, let's ban all Free Software, let's ban Barn Raising, let's ban what we call American Suppers, let's make caring for your neighbour a criminal offence!
Scarlet is Free Software. And if I choose to express my gratitude to the PERSON who released it under the GPL, that's down to ME, not you.
And if I choose to protect my users by giving them the CHOICE to go back to him, if they so want, as their upstream then that's down to ME, not you. Are you REALLY saying it's for the best to expose my users to a bus factor of one, so if anything happens they're up shit creek without a paddle?
Free Software is all about CHOICE, and this is MY choice, not yours!
Cheers,
Posted Jan 23, 2024 16:57 UTC (Tue)
by paulj (subscriber, #341)
[Link] (17 responses)
I think they were arguing against large companies releasing free (as in beer) software as loss-leaders, to destroy value in markets and hurt any competition, and try gain (or hold) some monopoly position for themselves. Typically, where a company can succeed in this - i.e. the company with the deepest pockets, and the most ability to subsidise the loss-leader from revenue from other markets - it will later use that to gouge consumers in some way, be it by prices on the product directly or using control over the free product to force consumers into other paid products. Once monopoly has been created, investment tends to decrease, people working on it tend to become complacent - quality of the product also tends to suffer and/or innovation declines.
As an example, remember Microsoft and Netscape? MS bought a browser, bundled it for free into Windows - all paid for by their Windows and Office licensing revenue - and thus destroyed Netscape's ability to earn revenue.
MS eventually faced anti-trust actions, and lost.
Posted Jan 23, 2024 18:05 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
... did they really lose?
After all, the legal penalties they were eventually saddled with were even less than a slap on the wrist compared to the direct and indirect profits they made.
Posted Jan 23, 2024 18:41 UTC (Tue)
by khim (subscriber, #9252)
[Link]
They were important to make Chrome viable, although I'm not sure whether this should be considered success or not.
Posted Jan 24, 2024 10:33 UTC (Wed)
by paulj (subscriber, #341)
[Link] (2 responses)
If not for that, Internet history could be quite different.
Posted Jan 24, 2024 14:30 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
They lost _on paper_ but by that point they long since accomplished what they set out to do, and are _still_ reaping the benefits. The fines they faced were a pittance, and the "default browser ballot" BS was per formative nonsense, because by that point IE was intimately tied into the entire MS business software ecosystem and _completely_ owned the corporate desktop + backend.
(What eventually broke that wasn't the browser ballot, but the rise of the modern smartphone)
> They had to unbundle IE too and give other browser equal opportunity to be the default browser.
Um, IE _never_ ceased to be bundled with MS Windows. It is a core component of Windows. [1] At best, the only thing "removed" was the icon that launched the "browser wrapper" around that built-in component. (Sure, it's now called "Edge" and is built on the Chrome engine instead of Triton, but it's still just as proprietary and intrinsicly bundled as ever!)
[1] An embedded browser engine is a core component of every OS, commercial or otherwise. released since Windows 98, and it's _not_ replacable.
Posted Jan 24, 2024 15:02 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Posted Jan 23, 2024 22:47 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (4 responses)
The problem is "where do you draw the line?" I know I was being hyperbolic, intentionally, but seriously, do we want to ban giving things away?
And if giving stuff away is anti-competitive, then we should make anti-competitive behaviour illegal, not make giving stuff away illegal.
In this particular case, there are (or rather were) a couple of big contenders. There's Pick Systems (aka Raining Data, aka Tiger Logic, aka maybe a few other names too). Then there's INFORMATION, UniVerse, and Unidata, who merged into Ardent, aka Informix, aka IBM.
Then there were the minnows, jBase, QM, Reality, and Cache/MV. Ladybridge, aka a guy called Martin Phillips, was persuaded to release QM as the GPL OpenQM. (Incidentally, I didn't know that the "Open" has nothing to do with Open Source and everything to do with Open Systems aka commercial Unix! An earlier product, PI/Open, used the term Open in the same way, hence the inspiration for "QM on Linux" to be called OpenQM.)
Unfortunately, a company called Rocket has bought out pretty much all the commercial players, and the only real competitors left are Scarlet, Reality, and another minnow called OpenInsight. For example, I think the price of OpenQM has quadrupled since it was absorbed into Rocket a few years ago. UniData / UniVerse were always on the expensive side, but Rocket has raised the price of everything else to the same level.
I think that's why some of us want Scarlet as a viable competitor, but there's no way I want to leave potential Scarlet users up a gum tree if anything goes wrong, and given my experience trying to get Scarlet into my employer, I actually see the existence of a commercial version as a plus. I hope they come to see the existence of the Open Source version as a plus, too.
Cheers,
Posted Jan 24, 2024 10:38 UTC (Wed)
by paulj (subscriber, #341)
[Link] (3 responses)
Anti-competitive behaviour can be 1 large monopoly player abusing that position. It can also be all the corporate players in a market behaving in a certain way, which then undermines the competitiveness and interests of the programmers supplying the labour - which was spacefrogg's point.
Posted Jan 24, 2024 12:54 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (2 responses)
But that's called a Cartel, which is just as illegal as anti-competitive dumping. You don't make giving things away illegal. If giving things away is part of wider misbehaviour, you tackle the misbehaviour, not the giving away.
And while I'm not going to say the company I'm talking about was a one-man-band (I really don't know), it was pretty much a one-pony show, even if there was a supporting cast.
Cheers,
Posted Jan 24, 2024 13:40 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
AFAICT, spacefrogg was arguing against anti-competitive behaviours by corporates, including where the labour market is the victim of the anti-competitive behaviour. You are obviously aware of competition law. Not sure why you're arguing against positions no one here seems to have taken.
Posted Jan 24, 2024 15:36 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
To quote spacefrog himself ...
> Companies are not people! Companies cannot be gracious or nice or happy or caring. Like, you really think that? Companies should not allowed to give anything substantial away for free
If that's not spacefrog arguing for banning giving things away, I don't understand English !!!
Okay, and I admitted it, I've gone a bit over the top and taken his argument to an extreme. But it was his argument first. And as soon as you start getting into "where do you draw the line" you're going to end up in a war between the anarchists and the dictators. I'm firmly on the side of "(VOLUNTARILY!) giving things away is a good thing". If it's done with malicious intent, then you target the malice, not the gift.
Cheers,
Posted Jan 24, 2024 7:10 UTC (Wed)
by rqosa (subscriber, #24136)
[Link] (6 responses)
> MS bought a browser, bundled it for free into Windows Bundling an application into an OS is not exactly the same thing as giving that application away for free, especially at a time when… > MS eventually faced anti-trust actions, and lost. …the OS in question held a de-facto monopoly position in the market for desktop-PC operating systems. (MS having that de-facto monopoly was the main reason why they were hit with an antitrust lawsuit, after all.)
Posted Jan 24, 2024 13:44 UTC (Wed)
by paulj (subscriber, #341)
[Link] (5 responses)
Are other cases, inc. ones that spacefrogg may be worried out, different in their details? Sure. Still potential anti-competitive behaviour if some large corporate uses free products undermine the market for other actors (inc. those supplying labour).
Posted Jan 24, 2024 15:01 UTC (Wed)
by paulj (subscriber, #341)
[Link] (3 responses)
One of the reasons for the suit being that Netscape had had deals with PC makers to ship PCs with Netscape installed, which then became awkward / suboptimal when MS bundled IE and made it hard to set other browsers as default (fully). The ruling provided some relief on that. I don't know if many vendors went for that unbundled OEM version though - 1 did I thought, but that's my vague recollection. Part of how they got away with so little punishment was the Clinton admin got replaced by Bush.
Did it address all the issues, did it right all wrongs MS did with anti-competitive behaviours? No. But it did damage their reputation, it did put some kind of check on them, and it was the catalyst for further competition law investigations and restrictions put on them. E.g., the EU required them to open up protocol specs, and stop stymying projects such as Samba. They also got a massive fine and had to unbundle WMP cause of EU actions.
Things would certainly be much much worse now if MS had been left completely unchecked.
Posted Jan 25, 2024 1:58 UTC (Thu)
by rqosa (subscriber, #24136)
[Link] (2 responses)
> Things would certainly be much much worse now if MS had been left completely unchecked. Case in point: this
(see also this Q/A on superuser.com for some more technical details that might be relevant here)
Posted Jan 25, 2024 13:34 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
As it turned out, Win8 was so bad that most folks downgraded it to Win 7 (via an officially-sanctioned-by-Microsoft mechanism), and the status quo didn't really change until Win 10.
This had nothing to do with any antitrust action, and everything to do with actual market forces.
Posted Jan 25, 2024 14:12 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Mess-up or not, I'm pretty certain it was rather more than market forces. The EU is keeping a close eye on Microsoft, and I'm pretty certain it got pushed through as "If MS is allowed to do that, then it's a pretty safe bet that consumer hardware will ONLY be able to run Windows". Hence the requirement that buyers MUST be able to disable Secure Boot, if they so wish.
Cheers,
Posted Jan 25, 2024 0:17 UTC (Thu)
by rqosa (subscriber, #24136)
[Link]
> The issue that led to the antitrust case in the USA was the web browser, […] The real reason I posted that comment was to dispute spacefrogg's statement that "it is bad for society if companies are allowed to give stuff away for free, because this creates a situation where people easily get dependent on the free stuff", on the basis that a monopolistic company (e.g. Microsoft circa 2001) should not be considered equal to a smaller & less-powerful company (e.g. Netscape circa 2001), let alone to a non-wealthy individual person (e.g. some random hobbyist programmer who has some Git repos hosted on Codeberg today). Antitrust law (both in the US and in the EU) certainly doesn't treat monopolists the same as non-monopolists, by design. And for good reason, IMO. > […] and MS leveraging their Windows monopoly to bundle IE for free into Windows Exactly my point: MS's Windows monopoly was a necessary condition which needed to be met in order for the government to sue MS (for violating antitrust law).
Posted Jan 23, 2024 17:22 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
The usual regulations apply to selling products below the marginal cost of production - if mining 1 gram of unobtanium and shipping it to me costs you $1,500, then you cannot sell unobtainium to me for less than $1,500 per gram; if the mining is $500 of machine time, and shipping is $1,000, that sets your lower bound. However, the cost of finding unobtanium deposits, and of designing and building the mining machine, are ignored for this analysis; it may cost you billions of dollars in analysis to find each gram of unobtanium, or trillions of dollars to design and build a mining machine that works long enough to mine 10 grams before needing replacement, but that's ignored by the rules.
So, for example, you can't sell DRAM chips at less than the cost of making a DRAM chip; you can sell them cheaply, but it must be possible for someone who owns a semiconductor fabrication plant to make DRAM chips at or above the price you sell them for. Note, though, that semiconductor fabs are expensive, but that cost is not taken into account here; it's assumed that you already own one for the purposes of determining if you're selling DRAM chips at a loss, and so what's accounted for is the cost of silicon wafers, dopants, chemicals and electricity (over and above that consumed if the plant is idling waiting for an order) to run the plant for the duration of a batch of DRAM chips, etc.
Software escapes from this because virtually all the cost of software is in the analysis and design phases, which are outside the rules; the marginal cost of one more copy of a piece of software that already exists is tiny (what's the total cost of transferring 1 GiB from my server to yours, given that the cost of the server and the Internet connection are already paid, and it's only the additional electricity over and above idle that counts?), and the rules say that it's only those marginal costs that matter.
Also, importantly, this has only become a significant issue now that electronic distribution is cheap; in the days when software came on physical media (tapes, disks, CDs, DVDs etc), your bound on the price was set by the cost of the medium you were using; if getting a DVD pressed costs you $500 per thousand disks, your lower bound on price is $0.50. With Internet distribution of software (or music or video for that matter), your lower bound is some tiny fraction of a cent, and accounting rules let you write it off because it's so small; for example, if you use (chosen at random) Backblaze to store software for distribution, then your marginal cost is at most $0.01/GB plus $0.0000004 per copy. For a piece of software that's 10 MB in size, that's close enough to zero to be a permissible write-off.
Posted Jan 23, 2024 22:31 UTC (Tue)
by kleptog (subscriber, #1183)
[Link]
I don't think that argument works here. Google is not delivering a product, they're delivering source under an open-source license. Publishing it doesn't make people dependant and if Google goes away you still have everything had before, so there's no downside. You can do anything with this source that you like, including selling it. If Google decided to start charging, you could just fork it and start a competing community without any loss of functionality.
The CLA isn't giving Google any special powers, since anything you grant to Google is also granted to everyone they distribute the source to which is basically everyone. It's mostly just making explicit which would otherwise be implied (ie. if you make a contribution, then Google may presume you have the rights to do so. In the normal course of business this is the default position, but having it spelt out explicitly is not a bad thing when dealing with international contributors.)
Posted Jan 24, 2024 1:25 UTC (Wed)
by rqosa (subscriber, #24136)
[Link] (6 responses)
Contrary to what you seem to be implying with all of this pro-"Open Source" / anti-"Free Software" us-versus-them rhetoric that you've been posting here recently: pretty much every so-called "Free Software zealot" who's risen to prominence in recent years (such as Rebecca Giblin and Cory Doctorow, maybe) are much more similar in terms of their general ethos, sensibilities, and worldview to both the original "Open-source software" advocate from 1998 and the main person to whom Firefox & Thunderbird users owe their gratitude for the fact that those two apps exist in the first place — neither of whom have ever been pro-FSF partisans or (in your preferred terminology) "Free Software zealots" — than they are to pro-FAANG partisans who want the general public to believe that the upper management at those megacorporations are good guys who usually act in the best interests of "Joe Average" (i.e. the general public), I'd say. > I know how the world is run, that's the issue. Free Software zealots don't know that (or, more precisely, refuse to accept that knowledge). From reading your comment above while keeping in mind the fact that, at roughly the point in time that ESR mentioned in this part of his book from 2003, a sea change took place in the way that "the world" (or, more precisely, the IT industry) was run:
So then, in order to accomplish that goal, you've called for national governments to hold every last bricoleur/hobbyist programmer to the same level of legal liability that smartphone hardware companies (like Motorola/Lenovo, Asus, or even Google themselves with their Pixel product line) will be held to in the near future, thereby ensuring that never again will any such hobbyists be allowed to develop software that poses a threat to any present-day equivalent of the "traditional vendors" that ESR referred to there (such as SaaS vendors in general, and/or any of the current "Big Five" tech companies), as happened throughout the 1990s. At least twice recently, you've almost explicitly said that you want EU legislators to enact laws that would have that effect on to hobbyist developers, for example here: > if you are creating a GitHub page and write README there then now you are marketing something …and also here:
> And you may bet pretty large sum on the desire of EU legislators to keep these small guys around. [with "these small guys" being some hypothetical hardware company "that produces DVR based in MythTV"] > That, by necessity implies that large open source “forges”, if, maybe, not individual contributors, would have to deal with liabilities. If a law like that were ever to be enacted, it would likely end up preventing any new bricolage (meaning a hobbyist-led project, like KDE) from bubbling up out of the Internet to eventually reach KDE's level of fame & popularity ever again! Do you really want that to happen? (Remember: back in KDE's early years, approximately 100% of its developers — including Lars Knoll, David Faure, and Matthias Ettrich, among many others — fit the aforementioned "hobbyist programmer" description while at the same time not being pro-FSF partisans. Even today, most of the commits/contributions to Git repos hosted on invent.kde.org come from hobbyists, IIUC.) But, fortunately for anyone who fits any of these descriptions:
…it looks like several other LWN commentors disagree with khim on the topic of what kind of law the EU legislators really want to enact, e.g. bluca here:
> A readme, or a website, are not equivalent to marketing a product. …and also Wol here:
> The crucial words here are "and markets them". If you look up the definition of marketing, it does not include "making available for J Random Passerby to help themself". And I strongly suspect that those two commentors are correct in what they said there. In conclusion, here's the TL;DR version (written for a target audience of any LWN readers who've ever used their own self-written open source software as a showcase for their programming abilities while searching for a job): Whichever corporation you might have believed was your ally (against Microsoft, or against AOL/CompuServe/Prodigy et al.) during any of the past 3 decades is probably your enemy right now. That's because there are various big-money interests out there who see hobbyist-developed FLOSS projects — along with the hobbyist-oriented forge sites that host them (such as invent.kde.org, SourceHut, Codeberg, etc.) — as things which in the future might become existential threats to their own business model(s). This even applies to some corporations which on the surface appear to be FOSS-friendly (case in point: this). Consequently, right now there's a danger that some people with deep pockets might try to lobby national governments into strangling those hobbyist-led FOSS projects with red tape!
Posted Jan 24, 2024 11:27 UTC (Wed)
by khim (subscriber, #9252)
[Link] (4 responses)
It's true that when RMS wrote his essay there was no separate well-defined “open source camps” and “free software camps”. That happened later when free software zealots rejected the peace offering. And yes, we have to admit that free software zealots even managed to convince some people to release some software for free (Netscape, StarOffice). Credit where credit i due. It's absolutely not clear how much that helped, long term (most browsers these days tack their ancestry not to Netscape source release, but to work of KDE guys who were, very much, an open source group (as evidenced by the fact that free software zealots rejected their work and started an alternate project instead, which very much split the community and in general probably caused more harm than good (although it's very hard to say for sure because we couldn't just look on the alternate history where GNOME never happened). And what code these people have created recently? Before the introduction of Open Source software two worlds were intermixed and it wasn't as obvious. Especially because some of most active “free software” proponents were also prolific coders (starting from RMS himself, but also Tridgell and some others). But after “grand separation” (which, again, happened because the free software camp insisted on it) number of people who were producing anything notable in the “free software” camp was dwindling and today it includes almost entirely people who try to force other people to act against their wishes and don't themselves create much new code. It's not about about what I want, but about what may happen and what may not happen. And no, IT industry is not reverting to how it was run in the mi-'90s. Government control would be much more strict and chances of anarchy developments taking over would be slim. That's what happened to every other industry, after all. I guess some governments would fail to apply a tight leash and these government would fail… but that wouldn't lead to free software nirvana but to the proliferation of failed states where development of the software (free or otherwise) just wouldn't happen. If you seriously think that I have this level of influence then you need to have your head examined. That's not what I want governments to do, that's what they will do, whether I like that or not. When, not if. The question is only how many steps would it take to reach there. The end position is more-or-less clear. If you are sitting on the bottom of the mountain and notice that avalanche danger is increasing… do you want your lawn to be destroyed or not? If not then you don't scream at the mountains and don't threaten them, but rather prepare for the time when avalanche would actually happen. Sometimes it's even prudent to trigger avalanche early to reduce it's power. But crying about the fact that winter have come is just simply stupid. IT industry wasn't regulated for too long and have grown too big and too influential to be left alone. That means governments would react harshly and would enact laws that would be more damaging than if industry would have guided them. But free software zealots are still in denial and still believe they may stop that process if they would yell loud enough. Not gonna happen. And you know it, or else you wouldn't have been so angry. They may be correct in describing the law as it's drafted today. If that's true then it just means that there would be a different law later, which would bring control and responsibility into the IT industry. Wow. So much cope. No, there are no such danger. Or maybe there is, but that part is pretty much minor and insignificant. We have just arrived at the time where products made by hobbyists would stop being used by non-hobbyists. Like people are no longer using cars designed and made by hobbyists or radios designed and made by hobbyists. Except if they are hobbyists, of course, and even then they have to pass strict checks to be allowed to drive on regular roads or use their radios (except in certain niches dictated by governments). That's the tectonic shift that IT industry would pass soon. Like every major industry passed before. And if you want to say that this wouldn't happen then you should explain what differs IT industry from any other industry where that have happened already. Not try to write long screaming texts. I, for one, couldn't see why IT industry should be different from dozens of other industries that have passed that path before.
Posted Jan 26, 2024 11:00 UTC (Fri)
by rqosa (subscriber, #24136)
[Link] (3 responses)
> when RMS wrote his essay (Note: that link goes to Eric Raymond's 'Goodbye, "free software"; hello, "open source"' essay from 1998, not to anything that RMS wrote. Did you mean to write "ESR" there instead of "RMS"?) > That happened later when free software zealots rejected the peace offering. As of right now, there are very few people anymore who still believe that "separate well-defined “open source camps” and “free software camps”" ever existed. The hard-binary distinction to which you're referring was more-or-less an illusion, not a real state of affairs. And from 1999 onwards, there have been an ever-increasing amount of hobbyist developers posting their work on forge sites, and this trend accelerated rapidly in the next decade when GitHub and Gitorious appeared on the scene. Collectively, these hobbyist developers definitely do not fall into separate well-defined “open source camps” and “free software camps”, and that's the way it's been ever since SourceForge debuted. Now I'll pose this question: what, exactly, motivates those hobbyist developers to post their work on forge sites? Here's one major reason why they do that (which I already mentioned once): in order to publicly showcase their own programming work, so that people from their own potential future employer(s) can read & evaluate said programming work as part of the job-application process. If regulators were to regulate these forge sites (Codeberg, SourceHut, invent.kde.org, etc.) out of existence, then that would have the effect of economically harming tech workers, by making it next to impossible for tech workers to showcase any fully-functioning software they've written themselves on their CVs, and thereby benefitting the employers at the expense of the workers. > most browsers these days tack their ancestry not to Netscape source release, but to work of KDE guys who were, very much, an open source group The historical background of KDE isn't very important in the context of the upcoming Cyber Resilience Act. Here's what really matters currently: KDE e.V. and Codeberg e.V. are both nonprofit orgs, neither of which have anywhere near as much financial resources as a giant corporation like Google. If the CRA were to cause KDE or Codeberg (or individual developers hosting their own software there) to be fined the same large amount of money for a security vulnerability in some software hosted on their GitLab/ForgeJo instances (invent.kde.org and codeberg.org, respectively) as Google would be fined for shipping a security vulnerability on tens of millions of Google Pixel handsets, that likely would ultimately cause this to happen: no hobbyist-developed software will be allowed to be hosted anywhere on the Web anymore, because all of the "forge" sites would have either been fined/sued into oblivion. And if the CRA (or other similar legislation) is being lobbied for by Google thmselves or other similar giant companies, then that's a textbook example of regulatory capture! (However, I don't believe that's actually what's going on now w.r.t. the CRA itself — more details about this below…) Alternately: regulation might instead cause forge sites to end up being "locked down" to the point where they host nothing but Git repos belonging to big corporations rather than hobbyists, along with requiring the companies hosting their software on the forge sites to sign contracts in which the company agrees to accept all legal liability for bugs in their own software so that the forge site itself isn't held liable for any bugs on software hosted there. That would have the same effect, though, of forcing hobbyist-developed software off of forge sites. As for the historical background of KDE, though: your own timeline of events contradicts the statement that they "were, very much, an open source group". KDE Beta 1 was released in October 1997. That was before the point in time when (according to what you said) "free software zealots rejected the peace offering" (note: RMS wrote that essay in 1998, according to the copyright notice at the end of that webpage), and consequently before the point in time when (again, according to what you said) "separate well-defined “open source camps” and “free software camps”" sprung into existence. (Also note: the earliest version of KDE's HTML rendering engine was part of kfm (KDE File Manager). I'm not sure what its exact release date was… maybe July 1998 (KDE 1.0) or March 1999 (KDE 1.1)? Though, as far as I'm concerned, that makes no difference as to which one of your so-called "camps" was the one to which the original group of "KDE guys" belonged… because, once again, any such hard-binary distinction between "camps" was really just an illusion.) > as evidenced by the fact that free software zealots rejected their work and started an alternate project instead Now you're calling Miguel de Icaza a "free software zealot"? If you really believe he was a "zealot", then here's a little something about the GNOME's early-ish days that you might have overlooked: In the early 2000s, Nicholas Petreley occasionally wrote about Miguel de Icaza in his weekly editorials in Infoworld (an influential IT trade-press magazine, where Petreley was basically "the Linux and Java advocate guy" on their editorial board), and had nothing nice to say about him. Why? Because de Icaza is a dyed-in-the-wool Microsoft fan who made his own clean-room reimplementation of .NET and C# — that is, the Mono project — who also wanted Mono to become the main platform API for GNOME app developers to target, despite the fact that other people (including Nicholas Petreley, plus some developers of GNOME itself, plus some GNOME app developers) raised concerns that Microsoft might sabotage Mono — and, by extension, also sabotage GNOME and Linux as a whole — by using their patent portfolio to sue users of Mono or of any other clean-room reimplementation of .NET. (Those worries about Microsoft and their patents are probably among the various causes that led to the creation of Vala.) According to his Wikipedia article: de Icaza would later go on to work for Microsoft, even winning a Microsoft MVP award in 2010. (It also says that he had a job interview at Microsoft as long ago as 1997, but they couldn't hire him at that time due to legal restrictions.) That sure doesn't sound like someone who, even if we're only considering the 1997-through-2001 timeframe (note: 2001 was when Mono began), qualified as being a "Free Software zealot". (Side note: if it weren't for Nicholas Petreley's weekly editorials, along with his XOOPS-powered (and at other times WordPress-powered) news/forum website — VarLinux.org, which, sadly, no longer exists — I might not have ever found my way to LWN.net in the first place.) Also, keep in mind the fact that GTK+ and GNOME's core API libraries were LGPL-ed from the very beginning. By contrast, the zero-cost/gratis variant of Qt went through a series of license-changes throughout the years: at first it was under the "Free Qt license" (non-FOSS), then the "QPL" (FOSS but GPL-incompatible), then the plain GPL, until at long last, in 2009 (version 4.5) changing to the LGPL. For that reason, prior to 2009, developers of proprietary-commercial Qt needed to pay Trolltech (or their successors-in-interest) fees for commercial Qt licenses. What's more: the native Windows variant of Qt wasn't for available for zero-cost at all until 2005 (version 4.0), and (similarly) the native Mac OS X variant of Qt wasn't available for zero-cost at all until 2003 (version 3.2). I suspect that the higher-ups at Red Hat took note of all those things, and decided to favor GTK+ and GNOME (over Qt and KDE) and even fund the development of GTK+/GNOME, so that 3rd-party proprietary app developers wouldn't be required to pay licensing fees to Trolltech. So, no, I don't believe it's correct to characterize GNOME devs as being anti-corporate "Free Software zealots" in contrast to KDE devs who (supposedly) are a pro-corporate "open source group". That's not the way things were back in 1997/1998, and it's still not the way things are. > And no, IT industry is not reverting to how it was run in the mi-'90s. I said "a few years before" the mid-'90s, i.e. the era when Novell NetWare and (later) Windows NT ruled the roost in corporate America's datacenters (and in U.S. local/state-level governments's datacenters, too). To pick a specific point in time for this, I'll say 1990, i.e. the year when Windows 3.0 was released. Or, for a larger timespan, let's say approximately 1986 (when NetWare version 2 was released) up until 1995 (when Red Hat Linux version 1 was released). > Government control would be much more strict […] If the government in question were to put Codeberg — and/or programming work by individual developers being showcased there — equally strictly as it's going to treat the current "Big Five" tech companies, then that kind of government control would in practice amount to regulatory capture by the "Big Five"! However, judging by LWN's recent article about the Cyber Resilience Act and especially the comments posted there by people who (judging purely by what they wrote in those comments) live in Europe/UK and consequently understand how current Euro/British vendor-liability law works, I'm not worried that the CRA is going to do any serious harm to hobbyist-oriented forge sites (like Codeberg) or to hobbyist-developed Git repos hosted on them. That's because the intended primary target of the CRA appears to be consumer-electronics manufacturers/vendors, particularly smartphone makers, and also IoT / home-automation gadget makers. > […] and chances of anarchy developments taking over would be slim. Well, since you mentioned "anarchy", I'll pose a question: out of either the U.S. (which is all of the current "Big Five" are headquartered) or Germany, which one of those two countries do you believe is the one that's closer to anarchy? With that question in mind, I'll re-post here a YouTube comment (originally posted on this video) that was written by someone who lives in Germany:
On the "German Model": In Germany, we in fact have 3 "levels" of Board participation: The one mentioned above, for most companies between 500 and 2000 employees, one for Heavy industries and some other cases with parity between employer and employee representatives, and one for Companies over 2000 employees with parity of employer and employee representation, with the President of the Board having double votes in case of a stalemate. The companies that are exempt from employees on the board are those with under 500 Employees. The real deal about the Employee participation in Germany is the workers council, which has a lot more power (They have co-decision or veto rights on things like including, but not limited to: work time, measues controlling workers, worker protection, (Paid) time off rates, firing of employees...) For that reason, I'm guessing that the EU regulators will act to reduce, not increase, the amount of political power held by those "Big Five" U.S. corporations… and probably also act to improve the negotiating position that European tech-workers hold relative to their bosses (e.g. by ensuring that those tech-workers are able to showcase their work to other potential employers). (Side note: two of the Democratic Party's candidates running for U.S. President made Co-determination a.k.a. Workplace Democracy part of their campaigns in the 2020 primary election cycle. And if a political-activist organization such as Citizens Trade Campaign were to successfully get that kind of public policy enacted into law — via international trade treaties — throughout the entire USMCA trading bloc, and the entire EU, and all of the BRICS countries, then imagine what human society as a whole might end up being like from that point onwards. It'd be a damn sight better than what we've got right now, that's for sure! For example, if the Philippines had that kind of public policy in place, it might do away with the CONTENT-MODERATION SWEATSHOPS that Facebook et al. are using right now, thus preventing content moderation at scale from being even remotely feasible and forcing a return to pre-2005-style small-scale web forums like phpBB or its modern equivalents like public-inbox and Discourse, and likewise forcing Discord users to abandon it in favor of Matrix, and so on.) > That's what happened to every other industry, after all. Those kinds of grandiose sweeping statements about history tend to be massive oversimplifications of what really happened, and the people who make such statements often are motivated do so as a means of advancing their own present-day political agendas, or sometimes religious agendas, or other times financially-motivated agendas. (Remember back in 2016 when you predicted that "Android for the desktop" or something similar would replace all current desktop Linux distros Real Soon Now™, or maybe only replace the ones made by nonprofit orgs like Debian, in the same way that Tim O'Reilly predicted Mac OS X would replace desktop Linux back in the early 2000s? That still hasn't happened… though, now, it's looking like the Steam Deck is making some inroads in that direction…) Yes, things happened the way you described them in the three examples other industries that you gave: the car industry (which had a bunch of regulations put on it due to collision-unsafety in the '50s/'60s and Ralph Nader's exposé, and more recently had more regulations put on it due to ecological/air-quality concerns… though even in that industry the regulations were enacted surprisingly recently in Europe relative to the U.S., because Europe's transit system is less car-dependent than the U.S. one is), the food industry (again due to risks to human health), and bridge builders (ditto). One more industry regulated about as heavily as those three is terrestrial & satellite radio/TV broadcasting (due to inherent limitations of the EM spectrum & the laws of physics themselves — despite that, though, Wi-Fi hasn't been regulated out of existence by the FCC or anyone else). But every other industry… really? What about the paper industry, or the textile industry, or the clothing industry, or the furniture industry, or the home-audio-equipment industry, or the professional-grade A/V equipment industry, etc etc… There are certain smaller industries (which, generally speaking, are currently not regulated as much as the car industry is) — in particular, hobbyist-oriented SBC makers such as Raspberry Pi and their competitors… note, by now they have lots of competitors (if in doubt then just take a look as Christopher Barnatt's "Explaining Computers" YouTube channel), because RPis tend to be out of stock most places for the last few years (because there's so much demand for RPis from businesses, who want to use the RPis in scenarios such as electronic signage, that there aren't any RPis left over for hobbyists to buy) and so a bunch of RPi competitors have sprung up to sell to the hobbyist customer base the RPi Foundation has partially abandoned — which apparently qualify (by your standards) as being mere "cottage industries" that are unimportant in the grand scheme of things. And yet, when taken as a whole, those industries collectively make up a not-insignificant portion of the world economy. So, I'm not convinced that European regulators will disregard the economic impact that the CRA will have on those industries (or consider it to be unimportant), like you seem to believe they will… nor am I convinced that they'll disregard the impact those regulations will have on tech workers' negotiating position (relative to their bosses / managers / HR departments) in the labor market. (Remember also that there's a historical throughline from a state-funded "Computer Literacy Project" (that was its official name) in the UK to Eben Upton and the RPi Foundation. This goes to show that the Thatcher-era British state considered it important for general-purpose computers to be available for use — including programming-education use — to the public at large. And if today's British & European governmental bodies see things the same way — note, in 2013, the European Commission did see things that way — then they might take action to resist American BigCorp-led efforts like this recent one on the basis that it's important for societal reasons that a non-negligible portion of the general public must be able to use and program general-purpose computers.) Here's something else from recent history that goes to show just how unpredictable lobbyists & legislators can be — look at what happened in the U.S. as compared to Japan in the '80s/'90s with regard to the packaged-media rental industry: (And here are two more examples of how difficult it is to make accurate long-term predictions about the IT industry and human society more generally: in France back in the 1980s, X.25 and Minitel looked set to become what TCP/IP + the Web + SMTP email would go on to become in the mid-1990s; and didn't Andrew Tanenbaum once say that "microkernels have won", citing Windows NT as an example of a microkernel OS, but later had to take back that statement in part because NT turned out to not really be a microkernel OS after all?) > I guess some governments would fail to apply a tight leash and these government would fail… but that wouldn't lead to free software nirvana but to the proliferation of failed states where development of the software (free or otherwise) just wouldn't happen. Regulatory capture is the American way of doing things, to a greater extent than it is in Germany, and right now the U.S. is already dangerously close to being a failed state (to a far greater extent than Germany is)! Or at least that's how things in the present-day U.S. seem to be going as seen by most "Joe Average"-type Americans, who (unlike ultrawealthy people such as Marc Andreessen or Jack Welch) neither have nor ever will earn a living by working in upper-management and/or enterpreneurship and/or professional investment. Next, here's a personal story: I've watched in despair as lots of my own coworkers in the private sector (note, working conditions for public-sector employees are a lot better than what I'm about to describe here, due to labor unions such as SEIU) have spent only somewhere around 4 to 6 years working in any given engineering/technical job role (as opposed to a managerial role) before leaving that role in one of these 4 ways: being promoted upwards into management, or moving "sideways" within the org chart (i.e. moving from one internal "team" to another), or moving to a separate project within the same company, or leaving the company altogether. Why do they do that? Because climbing the corporate ladder is a major life goal for them, isn't that why?! And for those employees who care more about long-term maintainability of a codebase than (so-called) "career advancement", guess what happens: work turns into a never-ending barrage of "oops, it's 5:30 PM, but this problem we discovered at the last minute, and you must fix it TONIGHT, and stay up all night long working on it if necessary" demands from bosses! Consequently, the developers with the most working knowledge of the codebase suffer from severe burnout, and long-term maintainability of codebases falls by the wayside. In other words: when the turnover rate of employees is that high, the company's institutional knowledge deteriorates, causing code rot to set in, until finally the entire codebase is so messy/incomprehensible that it must be thrown away in its entirety. Lack of long-term maintainability is what led to the downfall of dBASE, and also to the original Netscape Navigator codebase (that is, Navigator's codebase as it was before the changeover "from the old layout engine to the new layout engine (Gecko/Raptor) [which] constituted an almost-total rewrite of the browser"). That is how software development is actually done in the milieu of big business today. And if new government regulations were to strangle all hobbyist-oriented forge sites (like Codeberg and invent.kde.org) with red tape, then that would likely prevent any new software project that values long-term maintainability like this one:
> If you seriously think that I have this level of influence then you need to have your head examined. Maybe books such as the aforementioned "Chokepoint Capitalism" (and its authors), along with activist organizations such as the FSFE (which, I'd say, is much more effective in getting their message out to the general public than the American FSF has been for a long time by now), might influence the actions of regulators/legislators in European countries that reject the U.S. style of so-called "laissez-faire capitalism" (especially Germany). And, aside from that, it sure looks like you have a tendency towards pro-"mass market consumer electronics" / anti-"old-fashioned desktop Linux" partisanship, ever since that time in 2011 when you said (to someone who, apparently, was one of the HP webOS developers) "The standard phrase applies: you [referring to corbet] don't exist", and also when you said that "most users value "pretty pixels" way, way, WAY above network transparency". (That's similar to the "user-friendliness to Joe Average User must be priority #1" kind of rhetoric that Apple fans were known for in the '80s and '90s, and despite that, the Macintosh got soundly trounced in the marketplace by the more bricoleur-friendly option — that being Wintel PCs — that gave rise to Linux during that same era… which in turn recently led to the Steam Deck, which for now at least appears to be a commercial success story.) Having read those and also this, it gives an impression of motivated reasoning like this: "you can't make a business out of [supporting niche use-cases*] since there are no money in it**". When viewed in that light, a lot of your comments could plausibly be read as FUD and/or Stop Energy directed towards hobbyist-developed FOSS projects. (*: in that instance, the use-case in question was reading email on a smartphone from a self-hosted IMAP server with a self-signed TLS certificate.) (**: although, to be fair, you did acknowledge that "certain niche markets appeared where GPLv3 is not considered large enough liability to try such software" that time.) > And you know it, or else you wouldn't have been so angry. No, I don't know that the CRA will be bad for forge sites, and neither do you. And neither do several other LWNers who've posted comments about the CRA… but at least they seem to have first-hand knowledge of how European laws (about liability for selling defective products) work, so I suspect that they are correct about how the CRA will play out in practice, and that the Apache Software Foundation is incorrect. (And as for the angry tone: I meant that to be directed toward the "Big Five" companies and big businesses in general, not towards EU legislators.) > If that's true then it just means that there would be a different law later, which would bring control and responsibility into the IT industry. "[Bringing] control and responsibility into the IT industry" shouldn't involve "making it possible for forge sites to be sued into oblivion", as far as I'm concerned… whereas it should involve cutting the Big Five down to size. > Wow. So much cope. If you're implying that I'm worried about the CRA in Europe, then you're mistaken (as I explained above). OTOH, it does look like someone at Google is worried that FOSS might pose a threat to their business model, and if that worry spreads to the board-of-directors, then they might start lobbying the notoriously big-business-friendly U.S. federal government to allow them to (as jwz said) "rule the world forever"… but on the other other hand, some U.S. legislators want a 2020s-era version of this to be imposed on the "Big Five" tech corpos, and no one knows which side will get to have things their way… > No, there are no such danger. That contradicts your earlier claim that "there would be a different law later". It also contradicts this ("if you are creating a GitHub page and write README there then now you are marketing something [and therefore you will be held legally liable for bugs under the Cyber Resilience Act]") and this ("That, by necessity implies that large open source “forges”, if, maybe, not individual contributors, would have to deal with liabilities."). > Or maybe there is, but that part is pretty much minor and insignificant. We have just arrived at the time where products made by hobbyists would stop being used by non-hobbyists. That's (conditionally) OK with me, as long as it remains possible for these 2 kinds of events to continue happening in the future:
In conclusion, here's one more quotation from ESR, this time taken from the front page of his personal website:
It's a shame, though, that ESR is a capital-L Libertarian, because that minor U.S. political party's economic policy preference (i.e. "laissez-faire" capitalism) is basically the main reason why both "the big-media machine" and the current Big Five U.S. tech companies were able to gain so much political power in the first place. Anyone who wants to have a hobbyist-friendly national economy ought to look to the parts of the world from which Linux and KDE (which might qualify as being the "top two" most famous hobbyist-developed FOSS projects) as the model to follow, and push for this kind of corporate governance to be mandated by law worldwide.
Posted Jan 26, 2024 23:09 UTC (Fri)
by kleptog (subscriber, #1183)
[Link] (1 responses)
They're actually called Works Councils in english and exist in many European countries, though they are the strongest in Germany. There's even a Works Council Directive. CxOs in English speaking countries have a hard time distinguishing them from unions but they have distinct roles. The Works Council represents the workers in the business and the goal is to improve the running of the business whereas unions are more focussed on the workers. From personal experience being on a Works Council having to decide whether to approve the firing of a significant number of colleagues to save the business is no fun at all. And that's just in the Netherlands where they're not as strong.
99% of the benefit of a Works Council is the mere fact that management actually has to motivate their decisions and it's surprising how many CxO-level decisions have no more motivation and analysis behind them than fits on a back of a postage stamp. Getting more than a slide-deck the first time round is rare. Once management can actually articulate what they want, the proposal is almost always a good idea.
As an aside, people seem to confuse the terms liability and responsibility with respect to the CRA. When it comes to fixing bugs in Apache, of course the Apache Core Team is responsible. No else has commit rights, so no-one else can fix them in the Apache source. That's different from the responsibility of a manufacturer to deploy any fixes. And completely different from liability which arises from the breaking of specific promises. The CRA is not about that your product in 100%-bug free. That's not possible, just like 100% error free hardware products don't exist. What matters is the process behind it: preventing, finding, reporting, fixing (security) bugs and deploying those fixes. All of which have had well known "best practices" for years, we just don't do them.
I'm so glad I've never worked in a place like that. I can't be held to deadlines that I did not agree to. If I gave a deadline and got it wrong, that's on me. But more often it's: that sound you're hearing? That's the sound of your deadline flying past. I honestly don't understand what motivates managers to give deadlines without asking the people who have to do the work if they're even feasible.
Posted Jan 27, 2024 8:59 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
"Something has messed up in our team, and tomorrow will break if we don't put it right".
Don't get me wrong, it's a great place to work, and there is a STRONG management recognition that our practices are broken. As far as I can tell, this particular incident was a bugfix that seemed to work, but then made matters worse. So we just reverted it.
But when a large amount of your work is "we just need tomorrow to happen!", then the odd thing like this does come along :-) I'm desperately trying to reduce technical debt, but when we have a huge database implemented in Excel VBA, there are limits ...
Chers,
Posted Jan 29, 2024 14:09 UTC (Mon)
by geert (subscriber, #98403)
[Link]
Probably the former, as it was present in the first version of KDE I tried, which must have been just before or at the 1.0 release.
Posted Jan 24, 2024 14:28 UTC (Wed)
by kleptog (subscriber, #1183)
[Link]
Businesses do not have feelings. They have always acted in what they think are their best interests. I think all open-source developers develop because they think it's in their best interests in some way. Open-source is where it is because sufficiently many people and businesses think it's better than the alternatives.
If FAANG are contributing to open-source, it's because they believe its the best thing for their bottom line.
> Consequently, right now there's a danger that some people with deep pockets might try to lobby national governments into strangling those hobbyist-led FOSS projects with red tape!
Hobbyist developers are basically on the same level as hobby model train builders, or you paying the neighbours kid to clear your gutters: in theory it would be great if they followed regulations, but there's no public policy reason to spend any effort on it. And no legal avenue to enforce it either.
Posted Jan 25, 2024 22:11 UTC (Thu)
by philh (subscriber, #14797)
[Link] (2 responses)
> Sure, jujutsu may still easily fail, but that wouldn't happen because of CLA, that's for sure.
All other things being equal, having paid attention to the success or otherwise of projects for about 30 years, I'd say that there is a high enough correlation between failure and the presence of a corporate CLA for me to assume that any new project encumbered by such a thing is not even worth looking at, because it'll very likely be superseded, and any time I spend on getting familiar with it will have been wasted.
That's without taking into account the real problem with corporate-backed CLAs, which is that I don't have a pet lawyer who will explain for free to me what the implications of signing it might be, whereas the other party did use expensive lawyers to ensure that their interests are protected. That being the case, I'm not going to sign one of those.
That means that I'm looking at a thing that is labeled Open Source, Free Software, or whatever name doesn't make you foam at the mouth, but really isn't in any practical sense, because only people that are careless of their own interests are going to contribute to it, so it might as well be labeled "Look but don't touch!"
I'm not demanding that they change that.
I am however disappointed that nobody at Google seems to have noticed that CLAs are the kiss of death.
Posted Jan 27, 2024 20:32 UTC (Sat)
by khim (subscriber, #9252)
[Link] (1 responses)
Wow. Where may I find your study? How have you picked the projects, where is the list, what was the outcomes you recorded? So you are not using C or C++, docker or kubernetes, don't use smartphones and so on? I suspect that you apply your avoidance of CLAs very selectively to reach that conclusion. Because from Google side it's most definitely not “kiss of death” at all. Many projects that require CLAs are leaders in the appropriate areas and even if you count some projects which currently don't require CLAs (like gcc or LibreOffice) they asked for CLAs for years. All Google-initiated projects require CLAs (be it Angular, Go or TensorFlow, whatever) and the same is true for the projects initiated in most other corporations, too. And they lose that requirement (if that ever happens) only when corporations involved ditch them or fork is happening. It would be interesting to see truly unbiased study which picks projects without looking on CLA and then looks on their fate over the years, but since both you and Google are looking for vindication of their stance (Google would definitely consider CLAs of Android an important part of its success while you would probably show us how Upstart was replaced with SystemD)… and given the fact that there are so very few which failed or succeeded because of CLA… extending your conclusions on the whole set of software available is just silly. Especially because “correlation does not imply causation”: you may say that Angular is no longer the most popular framework because CLA, but then why is it replaced with CLA-encumbered React, instead?
Posted Jan 28, 2024 15:02 UTC (Sun)
by gioele (subscriber, #61675)
[Link]
There are some numbers in:
Jonas Gamalielsson and Björn Lundell. 2017. On licensing and other conditions for contributing to widely used open source projects: an exploratory analysis. In Proceedings of the 13th International Symposium on Open Collaboration (OpenSym '17). ACM.
https://dl.acm.org/doi/pdf/10.1145/3125433.3125456
Table 8 seems to hint at the fact that projects with CLAs and similar contributor agreements tend to be more successful (according to BlackDuck's metric =~ being used) than projects without CLA. Correlation is not causation. This success could be due to having an entity (business, foundation) paying the programmers in charge of the project, rather than due to the CLA itself.
That study did not investigate the effect of CLAs on the number and variety of contributors to a project. So perhaps projects with CLAs are widely used, but not frequently contributed to (and the minute the sponsor goes away the project is dead, regardless of its widespread usage). But asserting that would require another study.
Posted Jul 7, 2024 22:17 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
> It's entirely different thing to demand that Google should stop using CLA or else you wouldn't even use that product.
No, for many people it is not "an entirely different thing". For many people, using free software and sending patches upstream is the same thing. Dropping that boundary is basically the main point of free software.
Even if they don't happen to actually send patches upstream (because the software is good enough for them), they want to make sure anyone else can easily for obvious "good maintenance" reasons.
Posted Jan 23, 2024 13:53 UTC (Tue)
by danielthompson (subscriber, #97243)
[Link]
A project where the development is primarily undertaken by a single corporate sponsor has, at best, significant risk regarding it's long term health since the sponsor may change their priorities. When that corporate sponsor *also* requires a CLA that confers them with rights that other contributors do not have then then the risk is higher because, by inhibiting contributions, they inhibit the formation of community around the project. They do not kill the community entirely but they do inhibit them. Isn't it therefore entirely reasonable to regard a CLA as a negative indicator of project health?
Thus in the case of a project with a vibrant competitor, such as git, then it's hardly zealotry to factor the CLA into a decision to not "even touch something".
Posted Jan 21, 2024 12:10 UTC (Sun)
by fw (subscriber, #26023)
[Link] (10 responses)
Posted Jan 21, 2024 16:27 UTC (Sun)
by amacater (subscriber, #790)
[Link] (9 responses)
_Requiring_ a CLA can be off-putting.
Posted Jan 21, 2024 22:26 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
Can somebody please explain the difference between Google's CLA, and a DCO? From other comments in this thread, it sounds like Google's CLA does *not* require you to transfer copyright to them (unlike some other CLAs), so I'm a bit confused about what exactly it does do, and how it differs from a DCO.
Posted Jan 22, 2024 10:00 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (5 responses)
The DCO requires you to assert that you created this thing, and it's OK for you to share under the terms you're offering it under. The Google CLA requires you to grant Google "a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works."
The distinction is that under the DCO system, if Linus decides to change the kernel licensing terms, he needs permission from all DCO contributors (some of whom may have already granted it, but still). Under the Google CLA, if Google decides that it wants to use my contribution in a fully proprietary system, it can, and it can even charge me for the privilege of licensing the latest version with my contribution included.
Posted Jan 22, 2024 11:30 UTC (Mon)
by khim (subscriber, #9252)
[Link] (2 responses)
Google doesn't need CLA for that, Apache License permits them to do that without any copyright assignment. That's precisely the only difference and it's more of theoretical one than practical one. If there would be some loophole in Apache License or law would be changed enough to warrant difference in license then Google wants to be able to change the terms. All other practical and theoretical needs are handled by Apache License itself, not CLA.
Posted Jan 24, 2024 11:52 UTC (Wed)
by adobriyan (subscriber, #30858)
[Link] (1 responses)
Why are they asking for CLA then?
Posted Jan 24, 2024 12:34 UTC (Wed)
by khim (subscriber, #9252)
[Link]
To shift the liability. The important part that CLA includes (and which Apache License doesn't include) is your signature and assertion that you have the right to pass that code to Google. If you also have agreement with your employer that prevents that then you couldn't just turn around and say that what you did was a mistake: you employer would have to sue you then get court decision and only then said license may be annulled. You may say that it's unfair that trillion-dollar corporation shifts the responsibility on poor small guy, but Google may also say that your two-line contribution is not worth taking that responsibility either. If your contribution is large and valuable, on the other hand, then you may always fork the project and then CLA, of course, doesn't apply.
Posted Jan 23, 2024 11:22 UTC (Tue)
by paulj (subscriber, #341)
[Link] (1 responses)
In most (all?) projects that use "signed-off-by" there no process to explicitely document that new developers certainly are aware that this tag indicates assents to the DCO; and the day-to-day interactions between patch submitters and integrators/maintainers often re-inforce cargo-culting.
Note: If you had that process to establish knowledge of and agreement with some DCO text, the per-commit tag becomes.... redundant!
I'd love to see a court case where a project with the (typical) cargo-culting SOB practices had to argue it showed agreement with DCO.
Remember: DCO and SOB came into life cause Linus just wanted to head off all kinds of calls for much worse bureaucracy in the wake of SCO. He invented this as a sop. IMO (given his previous opinions in those debates) a deliberate "we did something" to shutdown the "we must do something" types. It was designed to be the least intrusive thing that would shut those people up - being meaningful didn't matter (given the context of Linus' prior views).
Posted Jan 23, 2024 11:50 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
In that context, it's also worth noting that none of the bureaucracy being proposed would have helped with the SCO case; in the SCO case, the submitter of the code thought that they had the right to do so, and could have passed any bureaucratic hurdle, because the core of the SCO case was that SCO thought that IBM did not have rights that IBM thought it had.
But, because something bad had happened (the SCO case), people wanted to do something to stop it happening again. And Linus was fending off the "this is something, ergo we must do it, because we must do something to stop a repeat".
However, note that the Google CLA could, instead of giving Google an unrestricted patent and copyright licence, merely require you to assert that you have permission to grant those licences, and require that you license the code to Google under the same terms that the Google-owned project already uses; that it's one-way (and - for example - permits Google to sue you for infringing its patents, while allowing Google to lean on the CLA for permission to use yours) is something that often means that lawyers have to get involved if people outside Google are going to contribute (I'd have to get a lawyer involved with every contribution, for example, so that they're happy that Google can't argue that my contribution gives Google a licence to hardware patents not relevant to my contribution, which would be unnecessary if the grant was scoped down to the licence of the project I contributed to).
Posted Jan 22, 2024 11:49 UTC (Mon)
by zdzichu (subscriber, #17118)
[Link] (1 responses)
Jujutsu may fall into obscurity because of CLA. Just like Sapling.
Posted Jan 22, 2024 14:52 UTC (Mon)
by khim (subscriber, #9252)
[Link]
You are deluded if you think CLA caused Sapling or, e.g., Google's repo to fail. One simple counterexample: React from the same company as Sapling was adopted by people, and it requires CLA, too. Sapling just wasn't interesting to anyone who doesn't work with terabyte-sized repos (and most people who have such repos have specialized tools to use with them). Same with Jujutsu: if it would fail it would fail not because of CLA but because people would see nothing interesting to adopt it for.
Posted Jan 20, 2024 14:57 UTC (Sat)
by apoelstra (subscriber, #75205)
[Link] (13 responses)
Unlike other "git but different" schemes it looks like they moved in the right direction -- having the index be a real commit, letting conflicts be real commits (though in my workflows I imagine I'd always squash conflicts into their source so that the history is easier to read), etc. Talk of dropping `rebase --continue` raises my eyebrows. I hope that there continues to be a notion of `rebase -i` where you can edit specific commits, and where you can choose to fix conflicts mid-rebase so that they don't cascade too much.
I tend to use stash with workspaces when I find I've been writing code in the wrong directory. I do `git stash && cd ../other_workspace && git stash pop`. Sounds like `jj move` will do this, which is a much more natural invocation, even if it's less familiar.
Very glad they didn't take pijul's "the ordering of commits doesn't matter and cannot be specified" philosophy, which maybe works in a timeless Platonic universe but definitely not in this one.
I can't use jj without signed commits and I wouldn't want to without workspaces, but those don't sound conceptually hard, just low priority. Looking forward to seeing how this evolves. The git comparison page also says that it lacks a "current branch" and named branches in general...not sure whether this is a principled stance or a matter of development priorities. From a user POV I think these are pretty important features, even if technically there is no longer any garbage collector to guide. (Also how does garbage collection work if every tip is kept around?)
As others have said, the messaging needs a bit of tweaking -- e.g. "index is unnecessary" sort of phrasing sounds so much like other projects' "we threw away the index because it confused users who had first been shown a computer five minutes ago".
In some ways it's the opposite of Fossil -- from "rebasing is evil" to "rebasing should be done constantly behind the scenes" :) Probably they'll need to add some UX-layer stuff to warn users about this or require confirmation when replacing pushed commits.
Posted Jan 20, 2024 16:51 UTC (Sat)
by martinvonz (guest, #169226)
[Link] (12 responses)
Yes, I think most users do resolve conflicts pretty much as soon as they arise.
> Talk of dropping `rebase --continue` raises my eyebrows. I hope that there continues to be a notion of `rebase -i` where you can edit specific commits, and where you can choose to fix conflicts mid-rebase so that they don't cascade too much.
Cascading conflicts isn't really a problem, thanks to the simple algebra we do on the conflict representation (https://martinvonz.github.io/jj/prerelease/technical/conf...). After rebasing a stack of commits where you end up with conflicts, you would check out the first commit with conflicts, resolve those conflicts, and then squash the conflict resolution into the conflicted commit. The descendants are then automatically rebased, and the conflict resolution is effectively applied to each descendant. If there were other conflicts further down the stack, you would then check out that commit and continue the process. Even if these conflicts touched the same code as the conflict you just resolved, they would have been simplified (terms cancel out in the algebra) at this point, so they would be regular 3-way conflicts.
> I can't use jj without signed commits and I wouldn't want to without workspaces, but those don't sound conceptually hard, just low priority.
Workspace are actually supported (https://martinvonz.github.io/jj/prerelease/working-copy/#...). Support for signing commits is close to done (https://github.com/martinvonz/jj/pull/2728).
> The git comparison page also says that it lacks a "current branch" and named branches in general...not sure whether this is a principled stance or a matter of development priorities. From a user POV I think these are pretty important features, even if technically there is no longer any garbage collector to guide.
Named branches are actually supported. What we meant by "No need for branch names" is just that you don't have to create a branch for a commit to remain visible or to prevent GC of it. There's instead a `jj abandon` for when you want to get rid of a commit. I've sent a PR to try to clarify that branches are supported.
I wouldn't mind a "current/active branch" concept. I think we just haven't found that it's worth the extra UX complexity yet. https://github.com/martinvonz/jj/discussions/2425 has some discussion about it.
> (Also how does garbage collection work if every tip is kept around?)
Objects not reachable from the operation log are eligible for garbage collection. As you imply, that means that practically no objects are eligible, because they have been reachable at some point in time. So we have a `jj op abandon` command for abandoning old operations you, which makes some old objects eligible for garbage collection. This is similar to how Git's reflog prevents garbage collection but has commands for expiring reflog entries, allowing objects to be collected.
> As others have said, the messaging needs a bit of tweaking -- e.g. "index is unnecessary" sort of phrasing sounds so much like other projects' "we threw away the index because it confused users who had first been shown a computer five minutes ago".
Thanks for the feedback. We tried to improve that a while ago, but we clearly still have work to do there.
> In some ways it's the opposite of Fossil -- from "rebasing is evil" to "rebasing should be done constantly behind the scenes" :) Probably they'll need to add some UX-layer stuff to warn users about this or require confirmation when replacing pushed commits.
We have a configurable set of "immutable commits" (configured by a "revset", https://martinvonz.github.io/jj/prerelease/revsets/). Commands that attempt to rewrite such commits will error out. The set defaults to the "trunk" commit and tagged commits (ancestors are implicitly immutable).
Posted Jan 20, 2024 17:38 UTC (Sat)
by apoelstra (subscriber, #75205)
[Link]
BTW in git I usually completely disable the garbage collector -- I work on very few projects large enough to feel the disk space or performance hit. Sometimes I find myself scribbling bare commit IDs onto paper or into some other journal, before abandoning something that I'm unlikely to care about again. It would be very nice if there were some facility for "anonymous branches" that I could keep around Just In Case, and it sounds like the operation log provides exactly this.
Posted Jan 20, 2024 19:28 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (4 responses)
> Thanks for the feedback. We tried to improve that a while ago, but we clearly still have work to do there.
Just say you don't have a git style index because it doesn't sit well with the way you work, but you have the equivalent which works even better :-) Or say that index is a uniquely git fix and you do it differently. Or whatever, just stress that you're different, and your solution to the problem is different. The current vibe apparently implies you don't acknowledge the underlying problem, and THAT is your problem.
Cheers,
Posted Jan 20, 2024 19:58 UTC (Sat)
by martinvonz (guest, #169226)
[Link] (3 responses)
Right, that's what we've tried to do.
> The current vibe apparently implies you don't acknowledge the underlying problem, and THAT is your problem.
Can you point to where you got that impression? I can understand if one gets that impression by seeing just "There's no index (staging area)." out of context. Do you think that's what people do? (I do want to clarify the text, but I want to fix it in the right place(s), and I just don't know where it's currently most confusing.)
Posted Jan 20, 2024 20:55 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (2 responses)
There's no index (staging area). Because the working copy is automatically committed, an index does not make sense. Git workflows that rely on the index can be simply achieved using native jujutsu commands instead.
Cheers,
Posted Jan 20, 2024 21:00 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
Personally, it sounds to me like a jujutsu porcelain over git with this approach might be an excellent idea ... :-)
Cheers,
Posted Jan 20, 2024 22:02 UTC (Sat)
by martinvonz (guest, #169226)
[Link]
Ah, it took me a while, but I see what you mean now. Thank you! I sent https://github.com/martinvonz/jj/pull/2856 to try to improve it.
Posted Jan 20, 2024 19:31 UTC (Sat)
by ceplm (subscriber, #41334)
[Link] (5 responses)
Does it mean that `jj` recreates multiple heads hell of Mercurial? If yes, then it is a good reason to stay faaaaar away from it.
Posted Jan 20, 2024 19:53 UTC (Sat)
by martinvonz (guest, #169226)
[Link] (4 responses)
No, they are not named branches in the Mercurial sense, they are what Mercurial calls bookmarks (and what Git calls branches).
Posted Jan 22, 2024 3:49 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
* I want the VCS to never lose my data, unless I explicitly discard it (Jujutsu, Mercurial).
I'm having a hard time thinking of a coherent UX where you can have both of those options, and you don't accidentally lose a ton of data every now and then from being in the "wrong" mode.
Posted Jan 22, 2024 5:04 UTC (Mon)
by thoughtpolice (subscriber, #87455)
[Link] (2 responses)
Posted Jan 22, 2024 20:12 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link]
Posted Jan 24, 2024 8:33 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
Obviously.
Posted Jan 21, 2024 0:58 UTC (Sun)
by Phantom_Hoover (guest, #167627)
[Link] (2 responses)
Posted Jan 21, 2024 1:49 UTC (Sun)
by thoughtpolice (subscriber, #87455)
[Link] (1 responses)
But jj is designed internally to not *rely* on the specific characteristics of Git's data model, or any kind of "physical" specifics of any backend. It is designed as a set of libraries, that are abstracted by underlying interfaces. We all see this as a good thing; Piper (Google's VCS) and Git are quite different in design, but most of our workflows are perfectly supported across both of them. That helps keep our design and UX honest and ensure we do not "overindex" on Git support or its specific design choices.
We do want to implement our own native backend, though; there are many very interesting features we could make first-class citizens that are difficult to handle with just Git's data model and nothing else, and that would better serve several kinds of teams and alternative workflows (ACLs, large file chunking/deduplication, cloud storage, virtualized FUSE checkouts, "filters" for exporting sparse subsets of a monorepo, commit-on-save, et cetera). Some of that work might be inspired by Piper/CitC, some from other solutions (like Meta's "Sapling", or josh-proxy by Metahead.) However, that's a significant amount of work and not going to realistically planned to happen soon. But we're thinking about it.
As I've disclosed elsewhere: I'm a Jujutsu contributor, but have nothing to do with Google or anything.
Posted Jan 22, 2024 10:39 UTC (Mon)
by Phantom_Hoover (guest, #167627)
[Link]
Posted Jul 8, 2024 1:31 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (1 responses)
https://v5.chriskrycho.com/essays/jj-init/
(hosted on https://github.com/chriskrycho/v5.chriskrycho.com)
Posted Jul 8, 2024 1:34 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
https://github.com/martinvonz/jj/blob/main/README.md#rela...
This after reading about JJ for hours...
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
> It's now a mix of everything, with Bazel as the latest and greatest, but seems a good bet that they won't be able to get rid of any of these build systems for many more years.
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
https://source.android.com/docs/setup/build/bazel/introdu...
>At the completion of the migration Bazel will replace all existing build systems and build configuration systems in AOSP (Make, Kati, Soong, Make-based product configuration).
> Then I suppose the documentation may need an update:
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
jj commit -i to most straightforwardly replicate the common "interactive staging" workflow. There are also a lot of other variations on splitting commits in jj:
jj split -i: Split any commit into multiple commits interactively. (jj commit -i is more or less an alias for splitting the working-copy commit; I believe the difference is something about the default commit message population.)jj move -i: Move changes from any one commit into any another commit (without creating any new commits).jj amend -i: Move changes from the target commit (defaulting to the working-copy commit) into its immediate parent. (If I recall correctly, this is very similar to jj move -i with some arguments filled in, but there might be a difference I'm forgetting about.)jj diffedit: Modify the diff for a given commit interactively. Changes can be selectively updated or discarded in this way.meld.Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
"Limited availabity" does not mean "in widespread use".
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
(b) Revert the parts you don't want to be part of the first commit.
This can be as simple as "git show -- path/to/file/ | patch -p1 -R" if you just want to revert all changes to one file, or "git show > d", "vim d", "patch -p1 -R < d" for more complex cases.
(c) "git commit -a --amend", to edit the commit message for the first part,
(d) "git cherry-pick <sha1>" to pick up the remaining parts,
(e) "git commit --amend", to edit the commit message for the remaining parts.
Jujutsu: a new, Git-compatible version control system
777777 sample
666666 sample
555555 sample
$ git rebase -i 666666^ # and insert 'x bash' before 666666 or $ git rebase -i 666666^^ # and mark 555555 as 'edit'
$ git checkout -p 666666 # select hunks you want
$ vi blah.c; make; git add (-p); # fixup some more if needed
$ git commit -c 666666 # commit first part of 666666 -> 66666a
$ git rebase --continue # commit second part of 666666 -> 66666b, 777777, etc.
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
jj abandon if you didn't want it anymore. (This aligns with research on how novices use Git: they actually expect their working-copy changes to "stay" on the currently-checked-out branch rather than "coming with them" when they switch commits.)jj new @- (check out the parent commit, as you ascertained), if you think that would be helpful?Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
> Google uses and contributes to non-Google projects that don't have CLAs all the time.
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Open Source folk are usually perfectly happy to use stuff made by Google. It's Free Software guys who think they are entitled to ask for help and then demand that help would be offered on their terms.
Jujutsu: a new, Git-compatible version control system
I don't disagree with that statement either. Ideally usage begets contribution, so we shouldn't put people in a situation where they have to sign weird documents when they want to contribute a fix or improvement based on their usage of the tool.
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
> Maybe I'm misunderstanding you, but this seems wrong. People boycott stuff all the time.
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
> Now, those "demanders" of yours, they just won't contribute and it will deminish the input of bright ideas that jujutsu might have had.
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
> Every new PC sold with Windows 8 will be locked up tight with Microsoft's UEFI ... secure boot on
I don't remember the exact details, but for some reason I'd been under the impression that the final settlement with the DOJ in that 2001 antitrust lawsuit in the U.S. had the effect of imposing that requirement that PC owners must be allowed to disable Secure Boot. (Or if not specifically that one, then maybe the 2004-2007 antitrust action in Europe is the one that forced MS to not prohibit end-users from disabling Secure Boot instead?)
Not that I don't agree that there's a potentially dangerous precedent here, but this is omitting a key detail. For x86 computers, MS's certification requires that users can disable secure boot. (emphasis mine) Of course, this is not true for ARM computers, hence the dangerous precedent.Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Usually, there are regulations against selling products under value. It is just that, for some reason unbeknownst to me, these laws never seem to be applied to software.
Jujutsu: a new, Git-compatible version control system
KDE devs & other hobbyist programmers, beware: upper management at FAANG hates your guts
By late 1993, […] the long-awaited dream of a cheap Unix system for everybody had snuck up on them from an unexpected direction. It didn't come from AT&T or Sun or any of the traditional vendors. Nor did it rise out of an organized effort in academia. It was a bricolage that bubbled up out of the Internet by what seemed like spontaneous generation, appropriating and recombining elements of the Unix tradition in surprising ways. (emphasis mine)
…and also keeping in mind what jwz wrote (in his anti-Instagram polemic from 2016) about another sea change in the IT industry that also occurred in the mid-1990s (and was at least partially caused by the exact same event that ESR referred to above):
All of the "social media" services want to lock you in. That's been the case for a while. They love their "walled gardens" and they think that so long as they tightly control their users and make it hard for them to escape, they will rule the world forever.
This was the business model of Compuserve. And AOL. And then a little thing called The Internet got popular for a minute in the mid 1990s, and that plan suddenly didn't work out so well for those captains of industry. (emphasis mine)
…I get a strong impression that what you actually WANT to happen sometime soon is for the IT industry to revert to being run in a very similar way to how it was a few years before those two sea-changes took place in the mid-'90s!KDE devs & other hobbyist programmers, beware: upper management at FAANG hates your guts
KDE devs & other hobbyist programmers, beware: some "captains of industry" see you as a threat to their business models
As far as I'm concerned, this famous 1975 movie's depiction of an "anarcho-syndicalist commune" is a lot closer to the aforementioned "German system" of corporate governance than it is to the U.S. system of corporate governance (which is the way that all of the "Big Five" tech corporations are governed); that's because, in the U.S. system, major shareholders are the only people who choose people to serve as directors on the board. That "German system" of corporate governance has been the law of the land in (West) Germany since 1976, so as of now it appears to be a tested-in-practice system that's successful.
So, apparently, lobbyists from the Japanese equivalents of the RIAA and the MPAA failed in their attempts to get rental shops outlawed… whereas in the U.S., the RIAA's lobbyists prevailed over the rental shops (e.g. Blockbuster Video) but the MPAA's lobbyists lost their struggle against the rental shops. Just how predictable was the outcome of that lobbying battle?No manager of a [Linux] kernel developper can say "I know it's half baked but merge it now beacuse marketing wants it" and Linux largely maintains the "it'll ship when it's ready" and "longterm maintability is important" mindsets that are missing in most commercial projects.
…from ever being created in the future. You've said that you want government regulations to "bring control and responsibility into the IT industry", but kicking all hobbyist-developed software off of forge sites, or fining all of the forge sites (or the individual hobbyists hosting their work there) into bankruptcy, will just have the effect of putting big business in charge of most or all software development, where they do everything not in a controlled-and-responsible way, and instead do everything this way: "damn the torpedoes, full speed ahead; we don't care if it's buggy, just get this thing done RIGHT NOW!"I will not tolerate having general-purpose computing hardware, which should be an instrument of liberation and creativity, reduced to a locked-down delivery pipe for "content". By trying to cripple my tools, the big-media machine has made me its enemy. DRM delenda est!
You keep saying that, since 1998 up through the present, there exist "separate well-defined “open source camps” and “free software camps”", and (at least implicitly) that the "open source camp" is pro-corporate whereas the "free software camp" is anti-corporate. But that ESR quotation goes to show that the original "Open Source camp" was never 100% pro-corporate, and that their general ethos, sensibilities, and worldview are much different from the (in jwz's terminology) "captains of industry" who are in charge of Google, Facebook, etc.
Just a small addition to your comprehensive response.
KDE devs & other hobbyist programmers, beware: some "captains of industry" see you as a threat to their business models
The real deal about the Employee participation in Germany is the workers council, which has a lot more power (They have co-decision or veto rights on things like including, but not limited to: work time, measues controlling workers, worker protection, (Paid) time off rates, firing of employees...)
work turns into a never-ending barrage of "oops, it's 5:30 PM, but this problem we discovered at the last minute, and you must fix it TONIGHT, and stay up all night long working on it if necessary" demands from bosses!
KDE devs & other hobbyist programmers, beware: some "captains of industry" see you as a threat to their business models
Wol
KDE devs & other hobbyist programmers, beware: some "captains of industry" see you as a threat to their business models
Typing a full URL in the file manager's path dialog box and seeing the rendered web page was very cool, and impressed quite a few of my friends!
KDE devs & other hobbyist programmers, beware: upper management at FAANG hates your guts
Jujutsu: a new, Git-compatible version control system
> All other things being equal, having paid attention to the success or otherwise of projects for about 30 years
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
>
> Wow. Where may I find your study? How have you picked the projects, where is the list, what was the outcomes you recorded?
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
> Under the Google CLA, if Google decides that it wants to use my contribution in a fully proprietary system, it can, and it can even charge me for the privilege of licensing the latest version with my contribution included.
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
> Jujutsu may fall into obscurity because of CLA. Just like Sapling.
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Wol
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
* I want the VCS to automatically lose my data, unless I explicitly preserve it (Git).
Well, I would say Jujutsu does support throwing your work away. You can throw away vast amounts of work very quickly. But throwing it away implicitly just from changing states is Very Bad and a footgun. Jujutsu: a new, Git-compatible version control system
git checkout taking you away from detached HEAD to some other place means that you potentially just lost work, but it's frankly a bit strange that a normal command can have ramifications like that. It's why detached HEAD is scary for most people in the first place.
The approach you describe doesn't cleanly map onto the Jujutsu design unfortunately; a lot of the implementation is simplified by the underlying invariant that a snapshot is taken first, that snapshot becoming the working copy commit. And then the commands only ever operate on commits; there are no other states. For example, jj new can just change the current working copy commit, it doesn't need to have any logic to handle the "what if the working tree is dirty case", because it doesn't happen, by definition. Contrast git checkout in your example, where you would be prevented from leaving detached HEAD until you ran git commit -am "garbage" first so that Git doesn't get scared of what might happen.
You can just abandon entire trees of commits in a single command, if that makes any difference to you. For example, if you make 5 garbage commits on top of main starting with the revision xyz, you can just jj abandon -r descendants(xyz) and you're done and those commits are gone. You can also get them back with jj undo if you want. This can be shortened to -r xyz::
The revset language even makes it possible to make this generic, and work independently of the actual change/commit id. For example what if you don't want to even look up the commit id xyz? You can use a revset like -r 'ancestors(@) ~ ancestors(trunk())' where x ~ y means "revisions in x that are not in y", so the whole thing roughly means "The working copy commit and all its ancestors, except those ancestors that are part of the trunk()," the trunk roughly being the main branch on the primary remote. You exclude those ancestors because, well, you can't throw those commits away (they exist upstream). So you can think of the revset language as just a language of sets. You could rephrase this many many ways, for example jj abandon -r '::@ ~ ::main@origin' is the same thing except with some shorthand syntax and referring to the exact remote branch instead. Many things like this are possible; for example "what are all my open patches that have a description that aren't on the remote main branch."
If you want to throw away work, feel free. Jujutsu does not even require you to give a description/commit message for any of these 5 garbage commits. But it won't throw away your work implicitly, and I think for 99.9999999% cases, that's the right move. I think it's just a mindset change, really. And if you throw away the wrong work, it's trivially recoverable; jj undo and jj op log make it very, very difficult to lose data in any meaningful way. I have a hard time really imagining a case where data in Jujutsu gets lost like it can in some cases with Git.
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
Jujutsu: a new, Git-compatible version control system
https://v5.chriskrycho.com/essays/jj-init/
https://v5.chriskrycho.com/essays/jj-init/