I agree with the initial two bullet points. The git data structures are good, the git CLI is bad.
However, the issue with these attempts to create a user-friendly wrapper over the git data-structures, is that that’s what the git CLI already is. The ideal form of git that you explain to beginners is `git switch -c branch-name`, `git commit`, `git push`. This is not any more complicated than OP’s `sg create`, `sg save`, `sg submit`.
The issue with the git CLI is that it doesn’t expose commands for working with raw git data structures. This prohibits people developing an understanding of what the git commands are actually doing.
I’m at the point where I understand git well enough that I’m very rarely in the situation that OP describes, of guessing whether a git command will work, or asking ChatGTP for help. However I’ve gotten here by slowly memorizing what every git CLI command does to the underlying git data structures.
`git commit` creates a commit and updates the current branch pointer. `git commit --amend` created a new commit with a parent that is the commit before the commit at the HEAD pointer and updates the branch pointer. `git reset --hard` updates the current branch pointer and the files to match. `git push` runs `git fetch` and then `git merge`. `git merge` creates a new commit with two (or more) parent commits and then updates both branch pointers (if applicable) to point to the new commit. etc. etc. etc.
So I hate the git CLI because it tries to be beginner friendly by supporting a ‘normal coding workflow’ and it ends up being more complicated than just understanding the raw git data-structures.
Agreed with the sadness. My pragmatic take is that any improvement here needs to be incrementally adoptable and therefore compatible with the existing data structures - otherwise it'll be too hard to migrate.
Unfortunately the git model has intrinsic limitations. Pijul is an example of something that breaks free—it has a history agnostic data structure where the order of changes doesn’t matter. Applying changeset A then B results in the same state as B then A. In git these would be different trees.
I personally waste so much time on git rebases that shouldn’t even be a thing.
> In a modern, closed-source development environment, you can throw out 90% of Git’s complexity. At the end of the day, what does a beginner really need?
> That’s basically it. The rest—merge commits, complicated branches, rebasing, staging areas, and intricate commit histories—just aren’t necessary for most everyday workflows.
yes, agree.
but the takeaway should not be that you need another tool - you can accomplish what is required with a single sheet of paper (or webpage). a table of simple tasks and the commands to accomplish them, tuned to new developers, students, etc. there's literally no reason to make a wrapper just for that.
there's 10,000 things more complicated and fiddly than git that devs need to learn and become expert at.
7 comments
[ 3.4 ms ] story [ 32.0 ms ] threadHowever, the issue with these attempts to create a user-friendly wrapper over the git data-structures, is that that’s what the git CLI already is. The ideal form of git that you explain to beginners is `git switch -c branch-name`, `git commit`, `git push`. This is not any more complicated than OP’s `sg create`, `sg save`, `sg submit`.
The issue with the git CLI is that it doesn’t expose commands for working with raw git data structures. This prohibits people developing an understanding of what the git commands are actually doing.
I’m at the point where I understand git well enough that I’m very rarely in the situation that OP describes, of guessing whether a git command will work, or asking ChatGTP for help. However I’ve gotten here by slowly memorizing what every git CLI command does to the underlying git data structures.
`git commit` creates a commit and updates the current branch pointer. `git commit --amend` created a new commit with a parent that is the commit before the commit at the HEAD pointer and updates the branch pointer. `git reset --hard` updates the current branch pointer and the files to match. `git push` runs `git fetch` and then `git merge`. `git merge` creates a new commit with two (or more) parent commits and then updates both branch pointers (if applicable) to point to the new commit. etc. etc. etc.
So I hate the git CLI because it tries to be beginner friendly by supporting a ‘normal coding workflow’ and it ends up being more complicated than just understanding the raw git data-structures.
We can do better than the limited model that git provides.
I personally waste so much time on git rebases that shouldn’t even be a thing.
> That’s basically it. The rest—merge commits, complicated branches, rebasing, staging areas, and intricate commit histories—just aren’t necessary for most everyday workflows.
yes, agree.
but the takeaway should not be that you need another tool - you can accomplish what is required with a single sheet of paper (or webpage). a table of simple tasks and the commands to accomplish them, tuned to new developers, students, etc. there's literally no reason to make a wrapper just for that.
there's 10,000 things more complicated and fiddly than git that devs need to learn and become expert at.