Do you have any idea if this is coming to jj soon?

I wonder how guaranteed that is, can imagine GH deciding to 'clean' it (how much data can you put there theoretically? Or to close a range of potential security issues) and suddenly relatively niche but genuine uses like jj's change-id are unintentionally not preserved.

The change-id is exactly as much part of the commit object as the author/committer name/timestamp, description, parent commit ID, tree, and participates in the commit hashing as those do.

btw, did Martin leave google?

Martin left Google for this, yes.

That being said, there's a few things that lead to this perception: the first is that it used to be under Google's GitHub account, but is now under its own org. The second is that contributing to jj does require signing Google's CLA. That is something that is desired to change, but that's up to Google. Due to the license, the community could fork it, and still have the rights to use the code, but that would be pretty aggressive, and so everyone involved would rather work together on this than do so. The move to its own GitHub org was one example of movement in that direction, but I'm not aware of an actual timeline to remove the CLA just yet. The project will figure it out over time.

(I have a commit bit but am not a jj maintainer, so the above is my own impression from being involved in the community for the past few years.)

Maybe if Martin could comment - his @google.com email still appears in the repo readme, I'm assuming he doesn't have access to that box anymore - was the repo move and ownership coordinated with Google prior to his leaving?

I get why you may want to color this as non-Google-owned but it seems to very much still be Google-owned.

In theory there is now nothing stopping us (the community/project leaders) from just... Moving the repo somewhere else. We could do that. It would be a pretty sudden alienation of other Google contributors though and probably piss off their legal department -- 99% of them just submit regular fixes like any user, because they are ordinary users of JJ. They just happen to work at Google. It would just be stirring up shit for nothing. It isn't an unthinkable outcome, but it isn't one we're just going to "do" for no reason or because it would make people posting on forums happier.

Realistically a non-ownership-assigning CLA on a non-copyleft Apache 2.0 project like in this case doesn't actually mean anything or confer any power. It's all just paperwork that serves as a legal ass covering mechanism because big companies use lawyers. It's like checking the "Yes I am over 18 years old" box on a website. I say this as someone who hates the stupid CLA bot and am a contributor.

As far as actual leadership goes Google does not "own" anything in that regard, nor the day to day work, nor can it really force any of the community to do anything. There's 1 maintainer from Google out of 9 total and +95% of major contributions don't come from Googlers, ERSC, or even any particular company. They don't contribute most of the code, they don't lead most of the community, they are vastly dwarfed by the community in total size, contribution count, etc. What "ownership" or leverage do they have beyond a Github org in this setup? It's annoying but it isn't the same thing as being able to exercise meaningful levers of power, in my experience, and so most of us are just fine with it. Even if there was some stupid bullshit like a disagreement over implied trademark rights, the community could just rename and move on and Google would have nothing. That is where the real power lies.

You have to get out from under Google. This would be a red flag during due diligence for many investors.

I'm not saying Google is going to fuck you over but why not just get yourself into a place where you don't need to be writing replies like this, and we don't need to be having this conversation.

And also, I would strongly recommend acquiring trademark rights as soon as possible. If a foundation is formed later you can decide what to do with them, but having them protected is a huge deal.

There's nothing starting me from creating jjhub.com tomorrow and that is a real potential threat for you.

It's not an issue for investors, because again, Google does not own this, and we aren't even modifying jj at this point, and are unlikely to need to. The IP is very clear and not an issue.

> There's nothing starting me from creating jjhub.com tomorrow and that is a real potential threat for you.

That's fine! There's a lot of people already doing this, today. Competition is natural.

My point is not that it is “not Google owned” but to point out the specifics, which really matter. “Google owned” to me implies that they own the copyright to contributions, which they very much do not. That doesn’t mean that they have no control over it at all, of course, but the specific details matter a lot.

(Also, as I just said in another comment, I forgot about trademark: if the community did want to fork, they'd have to rename.)

Not really. I remember my early years with git and the favt was that I never needed more than clone, add, commit, pull and push. While I’ve done some mistakes that got ne to learn more, especially with creating branches and undoing. I’ve never needed a lot, even when I started using GUI which exposed more concepts.

Why? Because I have no understanding of version management and how it’s useful in a dev workflow/release process. I was just using it for checking in work.

Since then, I’ve read the “Pro Git” book, learned how devs and teams handle versioning and devel a good understanding of how git can help me in my coding process and general software development. And it’s very good at what it does.

Git is quite powerful, but the cli is a train wreck of complexity and inconsistency. Learning the options to one git command means you’ve learned the options to exactly one git command. No other git command is required to use the same terminology. Personally, I was stuck in “git basics land” (all the basic commands you list) until I adopted Magit in Emacs. IMO, the Magit team deserves a medal for making git usable at an advanced level.

I don’t have an opinion about jj yet, but no one can hold up git as a pinnacle of great source control. Yes, it’s powerful, but it’s a UI train wreck.

You forgot the “because it's actually kind of terrible from a UX standpoint”. My stance is against that. I haven’t learned git in depth because I never knew any other workflow than code and check in the changes. There’s not a lot of guides on how version control can help in the software development process.

It wasn’t until I got involved into OSS that I learned more which in turns give me the motivation to use and learn about git in depth. I’m also using magit (after a tour in various GUI) but for me it is to git what vi is to ex. Direct interaction instead of a command prompt.

I'm not sure I understand how "I use a specific text editor with a specialized interface into git that's superior" is a counterargument to the first-party tool having horrible UX. That seems basically the exact same as what I was saying about jj, except via emacs instead of a CLI. Either way, we've opted out of the actual experience of the tool in favor of using an alternative tool that operates on the version control.

It requires the same mental model as git.

The repository is a store, you check out the previously saved instance of a file, a group of files, or a subtree. In that regards, switching branches and restoring files is actually the same thing. A commit stores whole files and branches are pointers to commits (which update themeselves).

Maybe you can explain how is it leaky based on your understanding of version control?

At the team level, it’s guided by the release process, configuration management, which version is canonical. At the programmer level, it’s usually guided by how to switch between task, how easy to explore an idea and save the resulting experiment, how to reset the code to a know state and how to replay a previous changes on top of new changes.

So you discern what you want to do (which is independent of the tool), the learn how to use git to do them. If you start from git, you’re going to be confused, just like someone opening autocad with no knowledge of engineering drawing.

EDIT: GitHub had probably the first UX where I actually liked what I got, compared to various earlier git based ones, or the horrible CVS and SVN ones where clicking on a file name definitely didn't do what you expected.

I barely remember Bitbucket from the mercurial era but I do recall that while it was better than some, it was still worse than GitHub, whose "here's default branch's HEAD, plus auto-opened and formatted README" was really a game changer

I also have used plenty of SCM systems since mid-90's.

TBH learning git in depth was a hindrance for me learning jj - for my first few weeks I kept instinctively looking for complex solutions to simple problems and being confused, when the answer was always "use the tools you already know"

As a concrete example - git has one set of commands for managing commits, a different set of commands for managing the index, a third set of commands for managing stashes, a fourth set of commands for managing the working directory, and a fifth set of commands for managing conflicts -- in jj all of those things are a single concept with a single set of commands, equally (if not more) powerful, but also simpler

They have less to walk away from then.