On Fri, Jun 27, 2008 at 7:14 PM, Dmitry Potapov <dpotapov@xxxxxxxxx> wrote: > On Fri, Jun 27, 2008 at 10:14:05AM -0700, Robert Anderson wrote: >> >> It is too subtle. That the index state - which becomes the next >> committed state - is not available for building or testing before >> committing is a deep flaw. > > And why is that? It is like saying that any editor that does not allow > you to compile the file without saving it first has a deep flaw. I don't believe it is like that. It would be like that if you intended for your on-tree disk to have a policy to always compile (for example). That is not a common use-case. > In Git, commits are not the same as in CVS. I have not suggested they were. > You can commit any changes > and amend them any time later before you publish your changes. This is enforcing a two-step process where there only need be one the vast majority of the time, to require that commit and publish be separate operations. > Those who care about quality should have a review process, and the > review process works best when all changes are slit in a small logical > steps. How do you propose to that without committing changes first? I don't understand the question. The entire point of the facility I am proposing is to facilitate creating small clean changesets. Go back and read my original proposal, or Junio's statement of more or less the same idea, to see how it is proposed to do this. > You can verify it, but you do that _after_ you committed changes but > before you publish them. Again, this is requiring two steps when it is otherwise not required, creating an inefficient workflow that is error prone. > BTW, policy may include that it should be > compiled and tested on a few platforms, so you cannot do that in > your working directory anyway. Huh? I have done that every day for 15+ years. > I think the source of your confusion is that you consider git commit > as cvs commit No. I have experience with a wide array of source control systems. CVS fits my mental model the least well. git is pretty close, but it is not there yet. The current partial commit facility is the biggest misfire, in my view. I like that git's philosophy does not include a draconian policy of not changing history. That's fine, it's practical, and it's useful, to cover common scenarios in which you'd like to quickly recover from a mistake. However, I am afraid that these facilities have been abused and turned into something that they are not well-suited for, i.e., the use of lines of development as both keepers of history and of scratch spaces where you scribble around with temporary things, all the while git having no clue which is intended. That these ideas are conflated is a mistake. That's my opinion. These activities ought to occur in separate, logically distinct spaces in which they occur, because they have different requirements and common use-cases. 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
