I'm definitely interested in the promise here. But it seems very early days.
I'm sceptical about the whole "make a workspace for a feature, then code, then merge" workflow. For me in practice work often doesn't follow that linear path, I don't really know what feature will be finished and ready for committing until done.
One very surprising thing I have learnt about git is that it is intuitive for some people. Whereas maybe half of its users, including me, will never really get it, even after decades of use. So I am also skeptical about broad claims of intuitiveness.
I think the problem of creating a truly user friendly distributed version control system CLI is enormously challenging and requires a lot of deep thought if it is going to meet the needs of a wide range of software development practices. Looking at the DESIGN.md does not convince me they have gone deep enough in that analysis. It has a bit of a blase "it's just common sense that it should work like this!" and I'm pretty certain it's not so easy.
I think they may be too quickly assuming that there's never a need for long-lived branches. For example, for any company (like mine) that does on-prem deployments, we need to support old versions for an extended period of time by backporting security and bug fixes. This is naturally supported in git by creating a branch for each release, and I'd be curious how evo is thinking about that problem.
> Yeah. I do wish git added multiple named stages to keep this sort of thing a lot more organized.
You mean commits? You know that you can easily edit, reorder, squash, split, rename and reorganize them into separate branches before you push them anywhere, right?
No I don't mean commits. The UX is different and it would be really cumbersome to try to split work in progress code.
What would be the suggested solution? Make two empty commits and the cherry pick change chunks into each? Then to shelve/stash a change you need to make a new branch and cherry pick back? Sounds really cumbersome compared to the current staging workflow.
Making many wip commits with small chunks and then squashing and/or splitting them into proper sharable commits once I'm done is my usual mode of operation whenever a single staging area is not enough for what I'm working on. `git rebase -i` makes it a breeze. I'm trying to imagine what multiple named staging areas would bring into the picture there that isn't already provided by commits and I struggle.
If you think that's easier or just as easy as adding an id to the staging commands then I guess its meaningless to you. I think it can be made much easier than what's possible now and I think there's value in fleshing out the part of git that this is actually about, ie staging incomplete commits.
If its actually single commit, auto-squashed branches behind the scenes, that's fine.
I'm sceptical about the whole "make a workspace for a feature, then code, then merge" workflow. For me in practice work often doesn't follow that linear path, I don't really know what feature will be finished and ready for committing until done.
One very surprising thing I have learnt about git is that it is intuitive for some people. Whereas maybe half of its users, including me, will never really get it, even after decades of use. So I am also skeptical about broad claims of intuitiveness.
I think the problem of creating a truly user friendly distributed version control system CLI is enormously challenging and requires a lot of deep thought if it is going to meet the needs of a wide range of software development practices. Looking at the DESIGN.md does not convince me they have gone deep enough in that analysis. It has a bit of a blase "it's just common sense that it should work like this!" and I'm pretty certain it's not so easy.