Hacker News new | ask | show | jobs
by Certhas 1757 days ago
Did you actually look at the page the list is from? THis isn't some sketch, it's a fully implemented way of working with git repos that supports everything you ask for. Committing just specific files is done in gitless via

    gl commit a.foo b.bar
committing all but some files is done with

    gl commit -e a.foo b.bar
gl commit -p allows you to interactively commit parts of files.

gl doesn't take any abilities away (it's just git under the hood after all), it just exposes the abilities in sane ways.

If you actually look at the homepage of gitless you will also immediately see what fuse does:

https://gitless.com/#gl-fuse

I believe that by reading that one, not very long page, most people (including non-programmers) can use gl correctly most of the time. This is not the case for git.

BTW, gl branch is for creating/deleting branches, gl switch is for switching your working tree from one branch to another. These are very different things, why should they be under the same command?

For git, the last paragraph is a necessary but in no way sufficient step towards using it proficiently. Gitless is actually much closer to realizing that vision.

Seriously, people need to go back and teach beginners git to realize how bad it is. We have internalized so much of the bad design decisions in git that we don't notice them anymore.

1 comments

No I did specifically not go to the gitless site because apparently I was supposed to understand it just from the list given in the post. Which isn't true.

I understand what gl branch "is supposed to do" but I don't see why gl switch is its own command given the other reasoning presented for why gl "is better".

I would say it is different. Probably very workable. Completely intuitive and the only reasonable way to do version control? Definitely not.

To me it's very very natural that git checkout will check out any commit I give it. How I specify that commit is up to me. It could be the commit hash. It could be a text label. That text label might on a logical level be a branch. Or a tag. Why do I need to switch branches with a special switch command when checkout handles this perfectly well?

Everything is perfectly logical after you get used to it enough.

And no, my post did not say that you will understand the details of every command in the list from just looking at the list. It only said that the list demonstrates that a much more coherent, less stateful, simply better UI is possible. That you can not fully explain the difference of fuse and merge in one sentence summaries is not a counterexample to that.

I said you will have an accurate mental model of what's going on. From the summaries you can tell all state you interact with: Working Tree, Commits, Track/Untrack status. That's it. That mental model is perfectly sufficient to accurately predict what most anything will do. And crucially the explanations and mechanisms to achieve all the workflows people asked for in this comment thread can be achieved with these ingredients just fine.

It's what the "Git is easy! You just need to understand that it's a DAG!" crowd pretends git already is.