Hacker News Reader

Comment by gcp | Hacker News Reader

So you can't selectively stage hunks and discard others?

As other people have pointed out, most new version control tools can do this without a staging area.

This eliminates the possibility of quickly putting away work in progress to do an impromptu demo at your desk,

No it doesn't, and they explain how. With combined branches + stashes, you'd do a checkout of a new branch from the commit before your stashed changes.

So...like Subversion? ... putting training wheels (or guardrails) on a product meant for an expert user seems...counter-productive to me.

Did you even read the article or the original paper?

View on HN

The latests iteration of hg crecord which is an interactive selection tool for chunks (see it in action here: http://g.recordit.co/BfbSa7cMXn.gif) Is far far better than git staging area. Intuitive to use, i can submit hours of code in few nice selective chunks really easy.

This sole function built in is a game-changer in mercurial for me.

It strikes me there's nothing inherently mercurial specific to this tool. This could very well be ported as a UI for git add -p.

I think GIT staging area wouldn't make it so nice to use in the end. Unless the whole thing is abstracted more, but then we get into the gitless discussion again.

I think it already exists as a graphical tool for Git, check out `git gui`.

You can get very similar functionality for git with "magit", which is an emacs package for managing git.

That said: Partially commiting files is indeed very handy and it would be great if it was available to more people.

If you don't have a stage then you don't get to edit/stage/edit/stage/fix/commit, right? I use that workflow a lot. I generally like incrementally building and refining my next commit. The stage/index is one of Git's most innovative features IMHO.

The same workflow can be accomplished by amending commits in git, without a whole new set of semantics needed for managing the staging area (or needing to stash changes when switching branches).

Your gif results in a 403, so I can't compare directly, but I get the impression that more people need to learn about `git gui` ;)

> As other people have pointed out, most new version control tools can do this without a staging area.

Fair enough.

> No it doesn't, and they explain how. With combined branches + stashes, you'd do a checkout of a new branch from the commit before your stashed changes.

Ah, OK. However, I still maintain that I have other uses for stash that don't easily conform to git stash --all; git co new-branch.

I read the article (though it appears not closely enough). I will admit to not reading the original paper (until now), but I did skim gitless's documentation a few weeks back when it appeared on HN. Even then I was struck with a touch of "What is all this new s&%# I like how my git is right now stop messing with it"

Like I said, I'm willing to admit that because I already know all of git's sharp edges, gitless may simply not appeal to me. However, it's totally possible that gitless really does make git simpler for new users and it's the future of git.

Stashing gets done the way we did it in the bzr days:

scm stash <filename> # Stash a whole file

scm stash -p <filename> # Stash a part of a file

scm stash -p # Stash parts of the whole project

Works as well as a staging area (because it's just the complementary operation) without needing a staging area, and without all the cognitive burden. Saying "you can put changes aside for later" is much easier than explaining the different states of a file in the staging area.

Reply on news.ycombinator.com