Comment by jogjayr | Hacker News Reader

Comment by jogjayr | Hacker News Reader

Parent Full thread

> the elimination of staged versions;

So you can't selectively stage hunks and discard others? Or stash them after making a commit of the ones you staged?

> the elimination of the concept of Stash, and stashed versions;

This eliminates the possibility of quickly putting away work in progress to do an impromptu demo at your desk, or answer a co-worker's question about the current master, or (for git newbies) working effectively with git-svn (in companies where SVN is used) without needing to learn about local branching or rebasing.

> Thus, it is as if there are multiple working directories (one for each branch),

So...like Subversion? Ew.

Does git have sharp edges? Absolutely. It's a tool meant to be used by professionals (or skilled hobbyists) to do work and build things.

I'm all for making things simpler to use, but putting training wheels (or guardrails) on a product meant for an expert user seems...counter-productive to me. To me it's like saying "Gee that cockpit has an awful lot of dials and instruments and things, we could probably take out a lot of the complexity if we assume that pilots will never have to deal with a stall" (I know nothing about planes)

I am also willing to admit that perhaps I'm too wedded to the time investment I've put into learning git and therefore assume that anything that attempts to make git simpler is flawed in some way. Maybe gitless really is the future of git.

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?

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.

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.

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`.

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