Hacker News Reader

Comment by xedrac | Hacker News Reader

I personally think Git's staging concept is one of its best features. Yes it is different and increases the learning curve somewhat, but it also provides a lot of flexibility in what you commit. For anyone that thinks Git is too complicated, consider using Mercurial.

View on HN

Agreed. One of the common things I use is git add --patch <file>. This allows me to commit changes in a file under different commits, by staging only the parts of the file that I consider as relevant for that commit. A lot of times I have different conceptual ideas in the same file, and I would have either forgotten to commit them during the day, and only realize it in the evening when it's time to push the code upstream; or those features would have been developed in parallel, because they are codependent, but are not necessarily the same from a conceptual point of view to the project. Either way I would want them under different commits so that my commit log is clean, and each commit can stand on it's own. This is where the --patch flag and the staging area are really useful. It might be a little trickier than just committing all tracked files with changes, but I appreciate the control. However, I do sympathize and agree with some of the points raised in the article, and I think there's definitely a scope for better interface design in git. For example, the stash is something that regularly confuses me, and the solution in the article seems like a better interface.

> A lot of times I have different conceptual ideas in the same file

Or debugging code. You're right, git add -p is a lifesaver.

The alternative could be `git stash -p`. Stash away the changes you don't want to commit, then commit everything still in the working tree.

The idea to remove the concept of the staging area to simplify git is worthwhile. I heavily use `add -p` myself, but newbies certainly struggle with it and teaching `commit -a` is not the solution.

> The alternative could be `git stash -p`

No, because I don't run `git add -p` before committing (I would run `git commit --patch` for that). I run `git add -p` during the development cycle. To emulate this with `git stash` would require a very annoying dance with stash and rebase.

> newbies certainly struggle with it

Newbies don't even know about `git add -p`. Newbies struggle with git because commands are not orthogonal (as the article mentions), and because documentation sucks. There is nothing inherently difficult about the staging area, it's just that it's not very visible what object a command would use or affect (index/tree/working directory) and it's hard to learn this.

The problem is with the implementation, not with the model.

Another problem is that in most cases people don't really want git, they want svn with local commits and better merging capabilities. Git is very popular, for some reason people use it even if it's clearly not what they want or need. To these people I suggest they should use the DVCS features of Perforce.

I never ever use commit -a these days, but as a newbie I did. These days, my go-tos are indeed add (-p) and/or commit -vp, so as far as the staging area goes, it become rather essential to me.

Not having a staging area (or using git add . && git commit -a to bypass it) has it's drawbacks too; I think most of the "garbage" files like "main.o" and ".test.py.swp", and secret API keys in public repos, can be explained that way.

To me, the answer is not abandoning the staging area, but improving the UI for handling it and/or directing users that don't want to deal with the git UI to things like GitUp. The git UI is horrible in a lot of places, admittedly. Even now, considering myself an advanced user, my workflow still is "git branch ... uhmmm... ^H^H... git checkout -b topic".

Fixing the (most annoying issues of the) UI might require some breaking changes sometimes, but so be it.

In particular, the staging area goes hand-in-hand with making small, consistent commits containing one logical semantic change each. I find it much harder to do that without the staging area. (I attempted to follow that practice all the way back to CVS and SVN, but found it challenging to do so.)

I second using Mercurial as they've also got selective commits in both simpler and more flexible way: https://www.mercurial-scm.org/wiki/CrecordExtension#For_Merc...

If my repo contains modifications I don't want to commit, I git-stash those modifications. I find it to be a lot safer: at least I can run the build + testsuite on what I'm actually going to commit, allowing the prevention of an incomplete commit (which means in practice, I nearly always use "git commit -a", and I find the index pretty annoying).

Haw can you partially stash a file?

git stash -p

It'd be nice if there was a way to run a build + test cycle on the staging tree.

You can use

  git stash -k

Which will create the stash with your changes (both staged and unstaged), but keep the staged ones in the staging area and in the working tree.

https://github.com/git/git/blob/659889482ac63411daea38b2c3d1...

For anyone that thinks Git is too complicated, consider using Mercurial.

Anyone that wants to use TYOOL 2016 age DVCS features should also switch. Like changing history yet still keeping a record of the original one (hg evolve).

Git completely owned all other DVCS with good branching. 10 years ago. But now it's time to move on to better tools.

The usefulness of hg evolve is debatable. It can be useful locally, as much as the reflog can be useful in git, but as soon as you push to the upstream repository, you lose that precious history if you haven't pushed it priorly. Worse yet, the reference to that history is still there in what you pushed, despite being nowhere to be found except in your local clone, making it useless to others.

That's true in case you've created some changesets, played with them locally and pushed them upstream. But, say you've played with changesets already available upstream, the unmodified changesets do not go away.

At RhodeCode (https://rhodecode.com) we believe it's up to a team to decide, which version control better fits their needs and preferences.

Some companies even have Git, Mercurial, and SVN, working all together under centralized repository management.

I, personally, believe it's up to a user to decide which version control system works best for them.

Both git and mercurial can talk to "non-native" remote servers.

IIRC mercurial can talk to subversion and git (with hg-git).

Git can talk to subversion, cvs, perforce, mercurial (there are multiple tools for the latter, and I'm the author of one of them), bzr, and maybe others.

If things don't work smoothly in any of those cross-VCS configurations, my belief is that issues should be filed and fixed.

Agree. However, large enterprises usually have common compliance/access control policies, something not easily implemented across multiple VCS (unless there's a full-fledged internal development team dedicated to that).

Working in a big firm adds overhead, yet has certain benefits (resources, etc.). That's a whole different topic though.

Reply on news.ycombinator.com