Hacker News Reader

I fully agree that the default porcelain has poor UX for managing the staging area, but doesn’t a porcelain without it encourage overly large commits?

All sorts of workflows become substantially more difficult (if not impossible) with kitchen sink commits. Undoing a single-line change, for instance. I dislike large pull requests, let alone commits that introduce a half dozen different changes.

Sure, if you’re really disciplined you can produce small commits without staging, by committing as you go along, but you’re breaking flow every time you commit in this style.

I say all this because I would love a CLI that has half-way sane handling of (e.g.) restoring staged, deleted files; doesn’t conflate restoring files with switching branches; has consistency of flags between commands (such as commit vs stash message); etc., etc. I should try gitless ;)

> porcelain without it encourage overly large commits?

Not for me. When using Mercurial back in the day I would manually split up commit, usually by copying over sets of files into a clean repo and committing there.

In Git tho the staging area is a lie. It encourages you commit half-truths. What I'd really want is to be able to enter a commit mode where the on-disk and staging area roles are flipped.

I want the stuff on disk to be what I commit, I want the "staging area" to be the changes that I've made that are not yet committed. This way I can pick a set of changes, compile, run tests and commit.

With Mercurial you could sorta do this with stashing I think, but I swore off it after losing changes a few times.

You can do the same with git stash, but it's also inadvisable because of how easy it is to lose changes. My workflow in this case is to checkout a new branch and commit the work-in-progress there, then switch back to the previous branch to check the commit. I've seen numerous pre-push scripts that do exactly that.

I wish git didn't use the disk at all! It gets in the way of parallelizing work. For instance, I'd love to be able to make a bunch of trial commits, then in parallel verify that none of them breaks the build. Or while a build/test loop is happening on one branch, switch to another to continue working.

> In Git tho the staging area is a lie. It encourages you commit half-truths. What I'd really want is to be able to enter a commit mode where the on-disk and staging area roles are flipped.

https://github.com/tv42/staged does something like that by writing the staged content to a temp dir.

(It has some smarts for Go GOPATH adjusting on top, but might not do things right with modules, at this time.)

Thinking about it, I guess it should be possible to flip this around by using a temporary local branch. Commit everything there, then cherry-pick into repo dir and commit proper.

Once done delete temp branch and push.

> I fully agree that the default porcelain has poor UX for managing the staging area, but doesn’t a porcelain without it encourage overly large commits?

No, I'd say the opposite. The staging area encourages me to think that I can make my change and split it up into logical commits afterwards, even though I know I'll actually just give up and make it a big commit. When I didn't know about the staging area and just committed whenever I could, I produced better, smaller commits.

> The staging area encourages me to think that I can make my change and split it up into logical commits afterwards, even though I know I'll actually just give up and make it a big commit.

That sounds like a personal discipline problem and not a poor tool.

The whole point of a tool like git is so that I don't have to expend personal discipline.

That's like claiming a gun is just used for shooting other things and that the point of the gun is so you don't have to understand how to handle it. Then when you shoot yourself in the foot you get mad at the gun and not yourself.

Guns are expected to be drop-safe. Some people say "well you shouldn't be so careless with a lethal weapon anyway", and yet most people will want their gun to avoid firing a bullet when dropped.

Compare a Sig P226 to a Type 94 Nambu.

Both are guns. Neither will shoot you if you understand how to handle it. One is much easier to make mistakes with than the other.

The parent is saying that Git is the Nambu of DVCS.

https://en.wikipedia.org/wiki/Type_94_Nambu_pistol#Unintenti...

That's how you get good commits... you do a bunch of changes to understand what you should have done and then you retell the story by carving it into commits. I have been doing this constantly for like a decade now and almost never "give up"... in contrast, Subversion, which doesn't have a staging area, is almost impossible to use as it requires you to somehow code in order the first time, which is ridiculous: no one is that perfect.

> But that flexibility adds an extra cognitive burden when a newbie just wants to save a "backup snapshot of the repo".

Simple needs have simple answers.

    git add .
    git commit -am '2020-11-17'

Sure, you can ask "why are there two commands?", but this is not so much an issue of cognitive burden as of typing burden. If you only want one thing, you only have to know how to do one thing. If you don't want to know why the procedure does what it does, you don't have to.

When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it.

This is the mental model 99% of newbies will have for something that basically pledges to save and sync each version of your files.

Deviating from the user's mental model will create roadbumps and should not be done without a very strong rationale. Especially not for a feature that's fundamentally optional.

When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it

So? When you're saving a file, you're also overwriting its entire contents. Good luck reverting back to the file before you saved it.

There is no automatic model for "this change is worth tracking" and "this change is not important enough to annotate". That's the model that git is enabling, and it has nothing to do with the "save" button in an editor. If anything, it has more to do with the "track changes" feature in Word, but more powerful because it allows you to group multiple edits in the same change.

> When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it.

I don't understand the point you're trying to make; this is just as true of the command I gave.

"Simple needs have simple answers."

  zfs snapshot pool/home/git@2020-09-07

> Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet: https://stackoverflow.com/questions/tagged/git?tab=Votes

This was surprising to me, and shows how different people's experiences of git can be. My workplace switched to git from an obsolete centralized VCS earlier this year, and I could easily answer these.

Something like this is probably where the line between those in this thread who agree that git is too hard, and those who think the detractors are just lazy and stupid, runs. Folks, people are more different than you expect!

> I could easily answer these

Maybe you find it easy because you don't see the subtleties. The answer to reverting the last commit for example can't really be that simple because it depends on what the user really wants to do. Do you want to keep the changes in staging? Reset the index but keep the changes in your working copy? Or reset the files to their state at the previous commit?

Maybe what we really need is not a new VCS, just a new CLI frontend for git.

If it was easy to create a frontend that worked seemlessly on a git repo then it would have been done already.

Buzzkill! I think it's more a matter of that those who are in a position to do so are used enough with git-cli that they are happy with the status quo.

It has been. There are numerous such projects; gitless comes to mind since somebody else brought it up in a comment here.

So the problem is solved and the OP blog shouldn't exist?

Your point being?

> Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet

This sounds like you just don't use or need those things much, which is fine if it works for you. Of the top 10, I can answer 9 of them without doing any research because I've used these commands a lot and they've become a part of my workflow. The one I'm missing? I've never renamed a git branch. If I needed to, I'd probably just do git branch --help or google it and figure it out in five seconds.

You don't need to commit every command of the program to memory. Just like anything else in tech, knowing how to find the knowledge you need is good enough.

For snapshots use backups. Git is not a backup.

For the questions, what's bad with quick help on SO? It's maybe less effective than reading the documentation that ships with git itself but for sure much more popular and less to read.

Git truly is a command-line utility, little known is that it ships with more than one gui in the base package out of the box. handling the staging area with git gui for example is straight forward unless you have more than 5000 unstaged files, then the gui informs you about it's limit and mass handling is far easier on the command-line anyway.

I feel the same way, I understand git pretty well but cannot for the life of me use the CLI. Fortunatly there are some pretty good GUI around, I personally use GitExtensions and find it suits my brain nicely. Its windows only though, not a problem for me since my work forces me to use Windows and I don't code at home but surely they are nice git GUI for Linux no ?

Totally agree on the "staging area". I've always thought that the staging area should only activate when you `git add` or otherwise add files to it. If there are no staged files, then git commit should act like git commit -A.

Oh hell no, Visual Studio has this behaviour by default (commit all changes if nothing staged) and what we end up with is that some people keep checking in various experiments and privately modified launch config files (that should not be in the repo anyhow but that's another story related to the tools) that end up causing a lot of unnecessary merge conflicts when you pull in their changes (where you were really only expecting some other part).

We deal with this via code review. Anything with such files is going to get instantly rejected. And people soon learn not to do it.

So with every new hire, you have burden the reviewer again? Wouldn't it be better to make the default so that Visual Studio burdens the primary developer, instead of the reviewer?

We prefer to automate everything that's automatable, and then a bit more, because reviewing is hard work.