RFC: new name for project?

[arxanas]

Calling it "git-branchless" has caused a slew of confusion among people who understandably think that you need to adopt a branchless workflow to use the suite of tools (#255, #259, various conversations) (although some people do find the name intuitive #4 (comment)). So we should probably explore a new name.

The problem from my perspective is that there's not actually a specific coherent theme for the various commands. Some general themes:

• Speed (in-memory operations, fast execution due to being Written In Rust)
• Ease of use (git sl, git undo, git restack, speculative merges)
• Developer velocity (git next/git prev/git co, git restack, branchlessness)
• Scaling to monorepos (index-less operations, in-memory operations, centralized main branch)

It seems like any name which covers all of those would be generic enough to not be useful. But that might still be better than misleading, since it seems like some people see the name of the project and reject the workflow change outright.

Some ideas:

• git-fast
• git-velocity
• git-derivative/git-deriv (because it's a derivative Git workflow, but also because we want to improve velocity, i.e. increase the mathematical derivative of velocity)
• git-easy/git-ez
• git-mono/git-monorepo (but also we don't want to dissuade people using non-monorepos)
• git-manipulate
• git-centralized/git-central/git-cent
• git-city (just to continue in the tradition of https://www.git-town.com/)

[martinvonz]

git-gud! :)

[luciusmagn]

this is by far the best suggestion here lmao

[epage]

To summarize, you are looking for an umbrella term / brand for these tools that work together / use the backend database, right?

Speed (in-memory operations, fast execution due to being Written In Rust)
Scaling to monorepos (index-less operations, in-memory operations, centralized main branch)

imo these are a selli9ng point but not a defining characteristic, so I wouldn't base the name off of them

Ease of use (git sl, git undo, git restack, speculative merges)
Developer velocity (git next/git prev/git co, git restack, branchlessness)

What would you say defining characteristics of these are?

[arxanas]

To summarize, you are looking for an umbrella term / brand for these tools that work together / use the backend database, right?

Pretty much, although I think the presence of a back-end database is an implementation detail (and indeed, a lot of the features, like git move, don't directly use it).

imo these are a selli9ng point but not a defining characteristic, so I wouldn't base the name off of them

That's fair.

What would you say defining characteristics of these are?

In my view, the defining characteristics were "ease of use" and "developer velocity", so I'm not sure what you mean here 😅

[claytonrcarter]

git-laser? git-precision? git-focus? atomic-git/git-atomic? git-vorpal? git-warp?

I would encourage you to stay away from git-monorepo for the reason you stated: instead of "I use this but I don't use a branchless workflow..." you'll just start getting "I use this but I don't use a monorepo..."

Not that I'm representative, but the tools in this project have made it much easier for me to think about my changes in terms of commits vs branches. The speed and reduced friction of in-memory rebasing, plus the sheer joy of being able to move a branch that isn't checked out, have also been big for me. My actions feel more precise w/ these tools.

[claytonrcarter]

Sometimes I feel like I'm performing surgery on my commit graph!

Totally agree!

I've also had git quantum rolling around my head recently. I'm no PhD in physics, but as I recall:

1. quantum particles are fast (like this tool, ie "high velocity")
2. quantum particles represent a discrete amount of energy (in the same way that our commits and actions should be discrete amounts of work)
3. quantum particles can interact w/o actually touching (just as this tool allows us to manipulate commits and branches that we aren't touched (ie that aren't checked out) ... though, this one's a bit of a stretch)
4. but most importantly, git quantum just sounds really cool 😄

[martinvonz]

Hey, Quantum is a name I have been thinking of for Jujutsu! 😄 I don't know what name I'd use for the binary, though (it's hard to compete with jj in ease of typing). The reason I had been thinking of it for jj is that the conflict states it supports are like superpositions of states (and it sounds really cool as you said).

But feel free to choose git quantum, of course. There's just a small chance that I'll rename my project to something similar later (but without "git" in it).

[evanrelf]

@martinvonz You could name the binary qu, like how a "qubit" is a quantum bit 🙂

[snan]

Git laser is a fun name 👍🏻

[ShamrockLee]

As a Physics student who has taken Quantum Mechanics, Quantum Dynamics, and Introductory Quantum Computing, I believe the main drawback of the name "git-quantum" is the probabilistic nature of quantum mechanics. A particle's physical properties (position, momentum, etc.) in the quantum scope are uncertain, and repetition is required to get the desired outcome in quantum computation.

On the other hand, git-laser emphasizes the precision and focus this toolset would provide. Lasers are distinguished from other light sources by their (spatial and temporal) coherence, making it easier to determine their paths, frequency distributions, and phases.

(Disclaimer: I'm studying Particle Physics, and I know more about quantum particles than laser beams. Please kindly correct me if some statements are wrong.)

[AaronLieberman]

I'll put in a vote for keeping it "git branchless". It allows you to adopt a branchless workflow. I think if it were "git quantum" or something less clearly indicative of what it is, I wouldn't have given it a try. When I explain it to collegues, I do have to say, "you can still use branches and I do for some limited things", but then follow up with, "but you don't have to, and most of the time you won't".

[arxanas]

I've been considering renaming the feature in question to be called "anonymous branching", which is what I think Jujutsu calls it. (In the case of git-branchless, it happens to not be technically accurate — there are no actual entities that directly point to the live commits — but the effect is the same.) In particular, I think it would scare off fewer people to say that "it's a workflow which supports anonymous branches" rather than that "it's a branchless workflow".

I think if it were "git quantum" or something less clearly indicative of what it is, I wouldn't have given it a try.

I think, somewhat problematically, there are many features which appeal to different people. I'm not actually sure which features different people are using in practice. (Maybe I should run a survey?) I use anonymous branching quite a lot, but I also rely on in-memory rebase features constantly, so that I'm not frustrated with my work monorepo. This is the entire premise of git-revise, so that alone must be useful for some contingent of people. I don't know that git-branchless makes people think not to look further into its features, just like you might not have looked into anonymous branching if git-branchless were named e.g. git-quantum.

When I explain it to collegues, I do have to say, "you can still use branches and I do for some limited things", but then follow up with, "but you don't have to, and most of the time you won't".

That kind of sounds like an argue in favor of dropping the name git-branchless 😅 . I'm curious, have any of your colleagues tried it out, and did they find any features in particular to be useful?

[AaronLieberman]

I've been telling a few of them for a couple months, since I started using it, that I would teach a little course on it so they can see how much better it is than vanilla git. However, I keep pushing this plan back because there are some significant rough edges when used in our repo. We use a merge workflow with a graph of "main" branches for different feature releases that automerge downstream into one another. It works rather well but git-branchless has some significant troubles with it.

One of the worst problems was that restack was incredibly slow in our repo but thanks to the newest release, that's now fixed (thanks!)

The other big one is that there are a bunch of cases when you check out some other main branch and you find your smartlog has thousands of lines of visible commits that aren't logically yours. I don't fully grok what's going on. I think it's because I have some commits that are far from my current main branch (which I switch around) and have multiple paths between them. I can work around this myself (I worked in a hg monorepo for years) and I'm willing to deal with some of this weirdness to have the better workflow. Unfortunately, I think this might be a bit much for most of my team, so I haven't yet shown them the light. I've considered trying to help this project to see if I could help find a solution with you all, but I'm really limited on time right now and besides, I'm not sure I have as good of a handle on this material as you all seem to :)

In other words, I don't think the name is the detractor, it's that it doesn't work as well for many git workflows.

To me, the differentiating factor of branchless is the anonymous branches. It feels to me that this is probably what brings people here vs. using git-revise or something. The other features feel to me to be in support of that.

[snan]

To me, the differentiating factor of branchless is the anonymous branches. It feels to me that this is probably what brings people here vs. using git-revise or something.

I disagree with that 🤷🏻‍♀️

[DarwinsBuddy]

git-back

like back-to-the-future or git-back-up-from-what-you're-doing-and-think-about-what-you-want-your-tree-to-look-like

git-back to work like in get back to work

git-back like in git-bag, cause it rocks 🤘

git-back in time and rewire your reality

git-back

[ahornby]

I think most of the functions are about managing phabricator/eden style stacks, so how about git-stack?

[arxanas]

There's already a project named git-stack :) https://github.com/gitext-rs/git-stack

[ahornby]

git-stacked
git-piles
git-mounds
git-heap

Branchless is fine I guess, one has to use the branch name less!

[artempyanykh]

My 2¢: although, this project does enable stacks, you can do stacked development with vanilla git too, it's just much less convenient. In my mind what this project does is it provides sensible tools and defaults to do:

1. commit and branch navigation,
2. anonymous branching,
3. undo/redo,
4. etc.

So, perhaps git-sensible? :)

[waych]

How about just recognizing that this package has a lot of services, and also stick with the plumbing theme that git has already with plumbing vs porcelain. Borrow from Spanish and you get git-servicios, where servicios has multiple meanings including restroom, services, servants.

[ilyagr]

I have an image of shaping a forest of commits just the way you like it. So, git-gardener, git-shaper, git-sculptor, git-remodel come to mind.

[ilyagr]

On a more fun note, following the same reverse psychology that named git, how about git-bramble? That seems memorable and pretty close to branchless.

The only other word I thought of that starts with "br" is brook, which is an OK option (brooks are nice).

[h4l]

For me, git-branchless evokes a sense of curation (of the steps that make up a piece of work), being mindful that with intentional use, a tool like git really becomes part of the process of writing software. Not just a way to backup and synchronise files with other people, as many people think. However, curation doesn't quite have the right feelings of productivity and speed that are important aspects of git-branchless.

So my suggestion is git-craft (or gitcraft). As in craftspersonship — the craft of understanding, appreciating and using tools effectively. Plus you can call someone a "crafty git", so that fits.

[cloudhan]

This tool is f****** amazing, at least it boost my git productivity 100x!!!

git-branchless is indeed misleading. It actually turned me away at least 2 times before I finally got fed up with thoes rebase labour. The first try of sync is extraordinaryly satisfying. If you need me to quantify the degree of satisfaction, I would put it above orgasm xDDDD.

This tool is actually branchful. It makes cutting and pasting branches freakingly easier than the stock git rebase. If it needs a new name, then I'd suggest graft, a techinque that cut and paste branches in horticulture.

[DarwinsBuddy]

this ^

[feefladder]

Just came here to say that "grafting" is also a technique in origrami, where you insert strips of paper into the paper "cutting and pasting." Here here is a satisfying video with a better explanation.
As such it also kind of fits into the branchless strategy, since the paper (the commit) stays the same, but what's inside changes.

[talios]

Similar to grafting - I was just having the thought of git-path when rereading this thread. Before heading further down a branch, one often follows a path, or when bush walking you may make quick, short mini-paths as you try to navigate.

[ahal]

I propose git-evolution,

1. It's a throwback to hg-evolve which pioneered many of the concepts this implements.
2. It suggests that it is the next natural (and superior) step in ones Git journey.
3. It makes it more clear that the scope is broad and all encompassing, and not only branch related.

A downside is that it could get confused with Mercurial's Changeset Evolution feature, which this doesn't implement. Though I doubt too many users would be familiar with that anyway.

[ahal]

Though I doubt too many users would be familiar with that anyway.

Then again, I found this out of missing the Mercurial features I was used to, so maybe this isn't true.

[koppor]

Is there a voting option somewhere? Maybe, a comment for each proposed name? - I like git-city, because "git-branchless" has a broad feature coverage.

[zicklag]

How about git-it? That's probably bad for search engines, but I figured I'd throw it out there.

Honestly, I taught my brother who is not a git expert to use git branchless because it's so much easier to tell what you're doing when you need to rebase things, etc.

It seems like git branchless makes it easier to git it. ;)

[firmwar]

git-pm (piecemeal)

[hauleth]

Following git naming tradition - wanker or twit.

[h4l]

As an English person, I feel wanker is a bit too strong, but twit is a really good fit — rhymes with git, kinda similar meaning, short. It doesn't sound very friendly, but git doesn't either until we all got used to it!

[hauleth]

@h4l we had git - stupid content tracker and now there will be twit - stupid commit tracker

[h4l]

I'll throw another suggestion in the ring.
How about just gb. Pronounced like the individual letters g b. I.e. reference git-branchless but hide/downplay the branchless part. I don't think it's an existing unix command.

[claytonrcarter]

As an English person … How about just gb.

I see what you did there. Indeed, the Sun never sets on the opportunities to improve git workflows. 🇬🇧

[h4l]

Haha, guilty as charged. 🙃🇬🇧

[millette]

Just to add to the conversation:

• gitng (next generation)
• yagit (yet another)

Of course...

[stijlist]

No one has directly suggested git-forest yet, but I like the name as something that implies expansiveness and "more" than a normal git tree :)

[feefladder]

Hmm, its not really a forest though. Like git-branchless will make the commit graph look more like a nature tree, bc it doesnt have these weird merges that are very rare in nature.

[talios]

@stijlist git-forest may give connotations of the old mercurial forests extension (think subrepos). Something to consider maybe...

[bsima]

git-unbranch sounds less exclusive, like you can use branches if you want but you can also unbranch and be free

or maybe git-detached

[Akamig]

It's not a branch (or lack of it), twig, or tree (especially not tree because of confusion),
but intended to manage them efficiently and keeping it tidy.
And need to be a short word for ease of typing,

So I thought git-bonsai would be a nice take. (although bonsai is very slow)

[rleconte]

I don't know if it is off-topic, but changing the "About" section from:

High-velocity, monorepo-scale workflow for Git

To something else, more in line with the themes outlined in the initial message:

High-velocity, monorepo-scale tools to make Git easier to use.

Might be a good idea, and considerably less hard than finding a new name 🙂

[bryango]

I have the same exact feeling as cloudhan so eloquently (and explicitly 😆) put in #284 (comment). The name has to be changed. I've been thinking about this for a few weeks now, and I think I've found the perfect name:

git-bless

Do I even need to explain? It's perfect 😆

• It means something: git-branchless
• It means nothing and thus, anything! git bless you 🤯

[feefladder]

second! ()meaning yes please please pretty please!

[bsima]

ha, git-bless is really good

[DanEble]

spur (OED)

• noun. A device for pricking the side of a horse in order to urge it forward, consisting of a small spike or spiked wheel attached to the rider's heel.
• verb. To prick (a horse, etc.) with the spur, in order to urge to a faster pace; to urge on by the use of spurs.

[DanEble]

yoix (OED)

noun. Chiefly Fox-hunting. A call or cry used to urge on hounds. Sometimes also used more generally as an exclamation indicating excitement or...

[eritain]

The project overthrows a baroque old regime by putting practically everyone in detached head state. You could call it Robespierre.

[mcous]

Since my first interaction with the tool at the start of a work session is usually the smart-log, I’ve been thinking that git-smart could be a fun name if you wanted to make a switch

I love the tool and it speeds up my work considerably. I use it mostly to enable a stack-patch style workflow, so I like that git-branchless communicates the mental shift of thinking of commits instead of branches as my unit of work. It does muddy the waters a little when trying to “sell” it to my colleagues, though

[feefladder]

As to what a git repo will look like with vs without git-branchless, the name could be shortened to git-palm or git-fir, where an original git repo would look more like a hedge. I particularly like the pronounciation of git-fir, because it sounds like getver, Dutch for "yuk"