Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A better merge workflow with Jujutsu

ofcr.se

Post reply on HN
Print view View original

21–30 of 93 posts

Re: A better merge workflow with Jujutsu

#21

Post by stevage »

packetlost wrote: post #20
stevage wrote: post #16

All these things just remind me how depressing it is that we all use this deeply flawed tool, git, and no one can get enough critical mass for a substantially better version.

the world if filled with "good enough" tools and I don't foresee that ever changing tbh. You'd have to offer something really substantially better than the status quo to gain critical mass. That being said, I think the only thing about git that doesn't make reasonable sense are the damn command line flags and subcommand names. The actual semantics of git are pretty much exactly what you want for source control.

Nah, git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. There is a lot of state that is not recorded anywhere - history lost forever. The rebase vs merge disaster. Etc etc.

Re: A better merge workflow with Jujutsu

#22

Post by pc86 »

stevage wrote: post #21
packetlost wrote: post #20

Earlier quoted context omitted.

the world if filled with "good enough" tools and I don't foresee that ever changing tbh. You'd have to offer something really substantially better than the status quo to gain critical mass. That being said, I think the only thing about git that doesn't make reasonable sense are the damn command line flags and subcommand names. The actual semantics of git are pretty much exactly what you want for source control.

Nah, git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. There is a lot of state that is not recorded anywhere - history lost forever. The rebase vs merge disaster. Etc etc.

This will sound flippant but it's an honest question: who cares?

I use git all day, every day. Sometimes CLI, sometimes a dedicated UI (e.g. GH desktop but have also used Tower and other dedicated tools), sometimes a UI in something else a la VSCode. I write code every day.

Why should I care at all about rebase vs. merge, whether the internals of git are optimal, whether index needs to exist at all or what it even is?

I think this is sort of what the other comment is getting at about a replacement needing to be much better and that git is good enough. I can count on one hand the number times I've ever needed to glean information out of old commit messages and when something got merged into something else.

Arguing about git workflows and whether you should rebase, merge, squash merge, trunk deployment, gitflow, etc. all seems like ultimate bikeshedding to me. If you're shipping code and making money your git workflow is irrelevant. If your project is so convoluted and broken and you're gaining actual useful information from a 2-year old commit message that you couldn't get just by looking at the code it feels like something else is fundamentally broken that better git internals are not going to address.

Re: A better merge workflow with Jujutsu

#23

Post by rob74 »

pc86 wrote: post #22
stevage wrote: post #21

Earlier quoted context omitted.

Nah, git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. There is a lot of state that is not recorded anywhere - history lost forever. The rebase vs merge disaster. Etc etc.

This will sound flippant but it's an honest question: who cares? I use git all day, every day. Sometimes CLI, sometimes a dedicated UI (e.g. GH desktop but have also used Tower and other dedicated tools), sometimes a UI in something else a la VSCode. I write code every day. Why should I care at all about rebase vs. merge, whether the internals of git are optimal, whether index needs to exist at all or what it even is…

I would care if a new VCS would make my life easier. This quote from the linked article:

> very few working developers have a good mental model for Git. Instead, they have a handful of commands they have learned over the years: enough to get by, and little more.

...pretty much describes me TBH. I know enough of git to get by day to day, but if I need to do more than that, I have to rely on StackOverflow et al. Which is always frustrating and feels like a waste of time.

Re: A better merge workflow with Jujutsu

#24

Post by epage »

jFriedensreich wrote: post #19
stevage wrote: post #16

All these things just remind me how depressing it is that we all use this deeply flawed tool, git, and no one can get enough critical mass for a substantially better version.

you can start using sapling today. its github compatible and production ready. as long as the new tools support github or whatever forge/hub you are using, there is no need for critical mass for adoption. This is not possisble for radical approaches like pijul, but that approach is not fully proven yet.

Isn't sapling only compatible with git servers and not local repos? That is a huge impediment with so many tools expecting git. That is what i find impressive about jj is it is compatible with local repos.

Re: A better merge workflow with Jujutsu

#25

Post by alkonaut »

packetlost wrote: post #20
stevage wrote: post #16

All these things just remind me how depressing it is that we all use this deeply flawed tool, git, and no one can get enough critical mass for a substantially better version.

the world if filled with "good enough" tools and I don't foresee that ever changing tbh. You'd have to offer something really substantially better than the status quo to gain critical mass. That being said, I think the only thing about git that doesn't make reasonable sense are the damn command line flags and subcommand names. The actual semantics of git are pretty much exactly what you want for source control.

There was a time when a VCS could just be a slightly better VCS and it could probably gain traction.

But now, for both better and worse, git is no longer just an app or a tool, it’s just a fundamental library and protocol that IDE:s, Build systems and project/work management systems build on. It has become almost too late to change.

The semantics of git are “ok”, but mostly it’s just a big leap ahead of cvs and Subversion. As always in any git thread we’ll see people (including me) expressing hope that Pijul will one day be successful enough to break the git monopoly.

Re: A better merge workflow with Jujutsu

#26

Post by alephnerd »

alkonaut wrote: post #25
packetlost wrote: post #20

Earlier quoted context omitted.

the world if filled with "good enough" tools and I don't foresee that ever changing tbh. You'd have to offer something really substantially better than the status quo to gain critical mass. That being said, I think the only thing about git that doesn't make reasonable sense are the damn command line flags and subcommand names. The actual semantics of git are pretty much exactly what you want for source control.

There was a time when a VCS could just be a slightly better VCS and it could probably gain traction. But now, for both better and worse, git is no longer just an app or a tool, it’s just a fundamental library and protocol that IDE:s, Build systems and project/work management systems build on. It has become almost too late to change. The semantics of git are “ok”, but mostly it’s just a big leap ahead of cvs and Subve…

> There was a time when a VCS could just be a slightly better VCS and it could probably gain traction

That was also a time when the entire software development industry numbered at most 50,000 globally and was still a nascent industry.

Re: A better merge workflow with Jujutsu

#27

Post by epage »

KingMob wrote: post #6
chasinglogic wrote: post #2

> Using Jujutsu, “amending a commit” also produces a new commit object, as in Git, but the new commit has the same change ID as the original. This is confusing to me, though to be fair I'm a "git expert" by trade. If you're amending a commit surely the "change" has changed so the change ID should also change? If the "change" isn't tracking the actual changes then what could it be tracking? Overall I think this is jus…

> If you're amending a commit surely the "change" has changed so the change ID should also change? If the "change" isn't tracking the actual changes then what could it be tracking? The author is using newer terminology around "changes", but I prefer the older "revisions", as being less overloaded. But yes, the revision/change ID remains the same even if the commits underneath changes. `jj obslog` will show you the hi…

imo revision is worse.

I feel like the best terms are patch id and patch revision id.

Re: A better merge workflow with Jujutsu

#28

Post by steveklabnik »

pc86 wrote: post #22
stevage wrote: post #21

Earlier quoted context omitted.

Nah, git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. There is a lot of state that is not recorded anywhere - history lost forever. The rebase vs merge disaster. Etc etc.

This will sound flippant but it's an honest question: who cares? I use git all day, every day. Sometimes CLI, sometimes a dedicated UI (e.g. GH desktop but have also used Tower and other dedicated tools), sometimes a UI in something else a la VSCode. I write code every day. Why should I care at all about rebase vs. merge, whether the internals of git are optimal, whether index needs to exist at all or what it even is…

I mean, you can use this logic to favor the status quo in any given circumstance. Some people are of course happy with that, but some folks want to try and improve. Not everyone has to care, but not everyone has to not care, either.

I swapped to jj because it’s both easier to use and more powerful than git. To me, anyway. And I was a “you can take git from my cold dead fingers” type person. A “the git cli is fine” type of person.

Re: A better merge workflow with Jujutsu

#29

Post by packetlost »

stevage wrote: post #21
packetlost wrote: post #20

Earlier quoted context omitted.

the world if filled with "good enough" tools and I don't foresee that ever changing tbh. You'd have to offer something really substantially better than the status quo to gain critical mass. That being said, I think the only thing about git that doesn't make reasonable sense are the damn command line flags and subcommand names. The actual semantics of git are pretty much exactly what you want for source control.

Nah, git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. There is a lot of state that is not recorded anywhere - history lost forever. The rebase vs merge disaster. Etc etc.

> git has lots of bad design choices that are deeper than UI. The index doesn't need to exist.

The index is a useful tool. You can opt out with `git commit -a`

> There is a lot of state that is not recorded anywhere

Examples?

> The rebase vs merge disaster

??? How is this a disaster? They serve different purposes and have entirely different semantics. You can use rebase to force fast-forward merges (which do not create merge commits), but I fail to see how this is a disaster.

Re: A better merge workflow with Jujutsu

#30

Post by stevage »

pc86 wrote: post #22
stevage wrote: post #21

Earlier quoted context omitted.

Nah, git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. There is a lot of state that is not recorded anywhere - history lost forever. The rebase vs merge disaster. Etc etc.

This will sound flippant but it's an honest question: who cares? I use git all day, every day. Sometimes CLI, sometimes a dedicated UI (e.g. GH desktop but have also used Tower and other dedicated tools), sometimes a UI in something else a la VSCode. I write code every day. Why should I care at all about rebase vs. merge, whether the internals of git are optimal, whether index needs to exist at all or what it even is…

That's all well and good if

a) you almost always work in the same repo; or B) you are in charge of the repos you work in.

Often these are not true for me. I have no deal with other people's repos, dealing with merge or rebase depending on their conventions etc.

Post reply on HN