Evo: Version control that works the way you think • Hacker News Board

Re: Evo: Version control that works the way you think

#41

Post by jayd16 » Thu, Jan 23, 2025, 3:26 PM UTC

seba_dos1 wrote: post #21

jayd16 wrote: post #16

Earlier quoted context omitted.

Yeah. I do wish git added multiple named stages to keep this sort of thing a lot more organized. Perforce can have multiple active CLs but they can only hold changes at the file level instead of hunks. That ends up even more maddening somehow.

> 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.

Re: Evo: Version control that works the way you think

#42

Post by seba_dos1 » Thu, Jan 23, 2025, 4:08 PM UTC

jayd16 wrote: post #41

seba_dos1 wrote: post #21

Earlier quoted context omitted.

> 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.

Re: Evo: Version control that works the way you think

#43

Post by jayd16 » Thu, Jan 23, 2025, 5:21 PM UTC

seba_dos1 wrote: post #42

jayd16 wrote: post #41

Earlier quoted context omitted.

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.

Re: Evo: Version control that works the way you think

#44

Post by remram » Fri, Jan 24, 2025, 4:11 AM UTC

cryptonector wrote: post #40

remram wrote: post #23

Earlier quoted context omitted.

You need both. Even with Git (a snapshot-based system), some commands take a hash as a revision and some take a hash as a change (e.g. checkout/rebase/reset/bisect vs cherry-pick/revert/amend). You'll hear both in common parlance too ("this commit doesn't pass tests"/"this commit is deployed"/"rebase onto this commit" vs "I did the last commit"/"this commit is too big"/"that commit broke X"). You really have to think…

I only think of commit hashes. Branches and tags and any refs are just names for commit hashes.

We were never talking about branches and tags. I think possibly you don't know what "revision" means?

A commit hash identifies both a patch or a revision, that's my point.

Re: Evo: Version control that works the way you think

#45

Post by ltbarcly3 » Mon, Jan 27, 2025, 5:06 PM UTC

marssaxman wrote: post #39

ltbarcly3 wrote: post #35

Git works the way I think it does, because I bothered to learn how it works. Be like me, learn how things work.

We don't expect people to learn how a piece table, line array, rope, or gap buffer work in order to use a text editor built around one. If you had to understand some editor's core data structure in order to use it effectively, we'd say that editor had a terrible UI and warn people away from it. We don't expect people to learn what a VFS is and how it works before plugging in a thumb drive. If some OS expected its use…

This is not true at all, and your examples are bad.

You don't need to know how btree's work to use SQL, true, but you need to know they exist and how they can be used by the database.

You don't know how to rebuild an engine to use a car, but you need to know what to put in the gas tank, when to change the oil, when to change the tires, what tires you can buy, how much air goes in them. You have to know a lot about how a car works to operate a car, or you have to pay someone to figure it out for you every time something needs done.

Git is the same. You have to know about how it works, not all the details of how it works. You could hire someone to do everything in git for you like you probably do with a car, but Git isn't a tool for stupid babies, it's a tool for professionals, and frankly professionals should know how their professional tools work.

If you can't be bothered or struggle to understand how your tools work as a professional, you should change professions as you are incompetent. If you think it's better if you don't have to know, then you will be passed by like you are standing still in your career by people who don't have qualms about knowing how things work and therefore can solve lots of problems in a couple minutes you think are too icky to bother to understand and would take you weeks.

(Note: I'm saying 'you' but I'm not addressing anyone in particular with that, so please don't take this as some kind of personal attack.)

Re: Evo: Version control that works the way you think

#46

Post by cryptonector » Mon, Jan 27, 2025, 5:38 PM UTC

remram wrote: post #44

cryptonector wrote: post #40

Earlier quoted context omitted.

I only think of commit hashes. Branches and tags and any refs are just names for commit hashes.

We were never talking about branches and tags. I think possibly you don't know what "revision" means? A commit hash identifies both a patch or a revision, that's my point.

> A commit hash identifies both a patch or a revision, that's my point.

Strictly speaking, no. A commit hash identifies a tree. There is no patch stored, nor is a patch bound into the commit hash in any way. The patch is indirectly implied as the differences between the new commit's tree hash and the preceding commit's tree hash.