On Sat, Jun 28, 2008 at 10:12 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > "Robert Anderson" <rwa000@xxxxxxxxx> writes: > >> On Sat, Jun 28, 2008 at 7:34 AM, Stephen Sinclair <radarsat1@xxxxxxxxx> wrote: >> > The answer is simple: you should not be making partial commits to a >> > repo that has been cloned. You should instead be working somewhere >> > else and then pushing to it. So this whole sentence is just a moot >> > point itself. >> >> Let me amplify my objection to this. >> >> Who has 100% foresight that what they are doing is going to end up in >> a state where they'd like to make partial commits? To take a quote >> from a blog post, 'Git means never having to say, "you should have"'. >> And mostly it doesn't, and that's big improvement over other systems. >> But, that is what you are saying here. I "should have" realized that >> I should have pulled and fiddled with my changes there, and then >> pushed. >> >> Well, Dmitri and others will now say, why not just always pull and >> work somewhere else? And the reason is that because this creates >> extra, unnecessary steps the vast majority of the time when I do >> create a commit that I like and want to keep as-is in the first try. >> Why should I have to pull, commit, hack, and push, when hack and >> commit is all I need to do the vast majority of the time? It is >> redundant, unnecessary work and complexity that I should not have to >> pay for when I don't need it. > > I think that in most cases the setup looks like the following: there > is private non-bare repository, ehere you can use topic branches, > and change and rewrite those changes at will, be it using plain rebase, > rebase --interactive, or some patch management interface like StGit > or Guilt. That is where you clean up your commits till they all fill > some standards / convention, like compiling (at least), or pass the > testsuite. In my opinion it looks like that because git has poor support for creating good partial commits the first time around. I also think all of this rebase -i style approach is fine for an experienced power user if they like that approach, but that splitting the changes in a working tree is a very basic usage that should be a part of a "Git in 20 minutes" tutorial. StGit, rebase -i, etc., should not. In my experience this is pretty much the *first* thing a developer faces when they decide that having a good incremental change history is a good practice they want to follow. They usually shrug, commit the hairball, and resolve to do better next time. But this is an unavoidable scenario in real world development, and a good SCM manager should have convenient facilities for dealing with it, that don't reach into the power user toolbox like rebase -i (and let's face it, that is an absurdly counterintuitive command for the job at hand), or require auxilliary tools like StGit. The index is a start. But, IMO, it isn't sufficient. Stay tuned for some proposals about improving partial commit support. Thanks, Bob -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
