Hacker News Reader

Comment by gorgoiler | Hacker News Reader

I’ve yet to inflict git on my pupils, but I think that:

(a) there’s definitely a route into learning how it works without getting confused. For example, use of analogy to explain the staging area and the commit process, then drawing on the analogy at the end of the process to reference the git jargon.

(b) I haven’t done the full research but I feel that there’s a good ecosystem of porcelain for git, even though the era of plumbing+porcelain is far behind us. I’d appreciate any hints in the right direction on this front. If your answer is “hg” then so be it hah.

View on HN

I've found the ecosystem of porcelain for git to be pretty terrible. I usually point learners to

- http://rogerdudler.github.io/git-guide/ - http://think-like-a-git.net/ - and https://www.sublimemerge.com/

Sublime merge is much better than most GUIs in that it doesn't try to paper over the git concepts. It's just a UI for executing the standard commands.

I think the key features of a CLI porcelain, other than simply renaming some commands (e.g. `git branch new` rather than `git checkout -b`) would be:

- Making staging optional. Committing with no staged files would be equivalent to `git commit -A`. If you do stage files, then it would only commit staged files.

- Auto-stashing. Such that you could switch between branches, and your in-progress changes would disappear and magically pop back when you switched back to that branch. It would be as if there was an additional "working commit" that was associated with a branch without actually being part of it.

How would the auto stashing work if you were to checkout in an irregular pattern? Say I:

- Make changes to branch A

- Checkout B (A changes are auto stashed)

- Make changes to B

- Checkout C (B changes are auto stashed)

- Checkout A again

As far as I know git stashes are FIFO, so it wouldn't be that easy to pop my stash for branch A at this point.

I think stashes are tagged with the branch name somehow? When I do a `git stash push && git stash list`, I get something like `stash@{0}: WIP on {branch}: {hash} {commit message...}`.

The message you get is an automatic message filled by Git when you don't provide one with the -m option.

Stashes are kind of sort of like branches themselves [1], but they are usually seen as a list, from which you can (cherry-?) pick arbitrary stashes with the apply or pop command, just name it [2]

[1] https://stackoverflow.com/questions/18527171/how-does-stashi...

[2] https://www.git-scm.com/docs/git-stash

> As far as I know git stashes are FIFO

This is an aspect of the mechanism that I would like to change. That it isn't easy to pop your stashes once you have more than one going is precisely the problem! It'd probably need to be a separate kind of ref.

Gitless seems to check your boxes. I haven’t tried it myself as nowadays I end up doing most of my git operations through VSCode keybindings. But it has always seemed interesting and I’ve considered bringing it into Code as an alternative git interface.

https://gitless.com/

For moving past referring to a cheat sheet, I've found https://learngitbranching.js.org to be a great help with learning on how to work with a tree.

FWIW, `git branch newbranchname` does create a new branch. Run `git checkout newbranchname` after to switch to the newly created branch. Or run `git commit -b newbranchname` to do both at once.

The staging thing has to do with git's origin as being used for kernel development. Each patch is (ideally) meticulously constructed, and stands on its own. In order for that to be possible, git has the staging area in order to assemble pieces of a commit until it's perfect (aka `git add -i`). That large areas of software development doesn't have (and doesn't need) that level of attention to detail to each individual commit, is a function that most project don't look like Linux kernel development. For better or worse, Mercurial/hg does not have a staging area.

Unfortunately, I know git too well to reason if auto-stashing would help, rather than hurt (beginning) users. Personally I'll often commit my in-progress work (dumping plenty of mental state into the commit message to make it easier to pick up when I get back to it) and then then edit that WIP commit before submitting the PR. Your tools are there to support you, and one of git's strength is that it'll support pretty much any workflow due to all the low level plumbing available. Unfortunately, the cost of that flexibility it's learning curve.

Reply on news.ycombinator.com