> If anything I would call it "incomplete," Well, if you're asking the user to keep track of anything more than the SHA1 of a commit and all of the commands av

> If anything I would call it "incomplete," Well, if you're asking the user to keep track of anything more than the SHA1 of a commit and all of the commands available to you, then that's asking a lot (because of all the commands that git has) > it requires discipline that is not fundamentally necessary If you don't proactively make branches, then you're like me. In that case, I make liberal use of git add -p, git stash, and git reset --hard (but only when everything is stashed or committed, to move branch pointers around). And then I always make a mental note, that next time I'm going to make risky changes, make the branch first (I don't get to use git often enough for my habits to change, though). But in my case, it's usually because I start working on one thing, and then mid-course, decide to work on something else. Because I came from svn, I forget how cheap commits are as well, and that it's possible to commit non-working code. It's definitely more desirable than creating commits that do too much. So, I disagree with both parts of your claim. It doesn't require significantly more discipline, provided you don't make the mistake of committing too much (e.g. always be sure to start working on an idea from a clean checkout). And the discipline required for the smoothest workflow _is_ fundamentally necessary regardless of what VCS you use, because no VCS can know what idea you're working on unless you tell it. If you're often committing to the wrong place, I suggest adding the current branch name to your shell prompt, or getting familiar with `git cherry-pick`. If you can't keep track of what's been merged with what, gitk and various git-log options are your friend. Do you at least agree that git has the history pruning options you were asking for? > Suppose I'm right and some of this branching/merging busywork could be avoided. Wouldn't we be in a better place than we are today? Isn't it worth exploring this possibility? First of all, my proposed solutions can be followed _now_, regardless of the pursuit of yours. Second, what you're describing sounds to me exactly like submodules, which require their own discipline, and have their own set of problems (hence the recent inclusion of the git-subtrees project). And if you think that maybe git can automatically decide what files go in each submodule, then good luck, because I think you're at a point where nothing can convince you otherwise. Edit: I take back all I said about your idea being unconditionally too complicated. It seems like it's already being done by the darcs/camp projects. I'll have to check those out eventually.