On Fri, Jun 27, 2008 at 11:31:24PM -0700, Robert Anderson wrote: > On Fri, Jun 27, 2008 at 9:03 PM, Dmitry Potapov <dpotapov@xxxxxxxxx> wrote: > > Do you think commit only tested changes is a common policy among > > Git users? > > I think there are various flavors of "tested" for which the answer is > certainly yes. I think that a line of development which always > builds, for example, is very, very common. Well, I don't think it is very common. Almost always builds, yes. As I said before, with Git commit means more like saving your changes in logical steps. Making sure that they are good enough to be publish is done later, and it usually includes testing and may include something else like code review, and code review is much easier if your work is recorded in small logical steps, and when you can share these changes easily and continue your normal work while your changes are reviewed. > >> 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. > > > > I don't see it is a problem. > > Fine, you like doing extra work for no benefit. Enjoy yourself. I don't see where you find this extra work. Maybe, pressing a button to save the file is also extra work? As to benefit, they are real for me as it saves a lot of time and allows me to work more natural, in the same way as you edit document. Your first version of document does not have to be perfect, you can review and improve it later, instead you focus on main ideas you want to express, and later, you will proofread and rearrange things, but it is very important to being able to save your changes even if they are not perfect yet. Extra work like pressing the save button is negligible comparing to everything else. > > You have your working directory let's say on Linux, and you have to > > test your changes on Windows. So what do you do? > > I rebuild on about a dozen platforms simultaneously on a cross-mounted disk. Does it work for MS Visual Studio? The last time I tried, it did not allow to build the project on a shared disk. Anyway, your compilation time is going to be worse due to network latency, and simultaneously building on different platforms will be more difficult to organize. With Git, you get everything for free. You committed your changes and they immediately available everywhere, and when all tests passed you can push changes to the main branch, or send to the integrator a request to pull, or to send a request to code review. It all depends on your policy... > > I don't see why git should know it. > > Clearly not. Example 1: is it ok to publish? If temporary commits > exist, git should stop you. But git has no idea if temporary commits > exist or not. There are no such thing as temporary commits in Git. There are changes that are ready to be accepted to the main branch and those that are not. It could be different reasons why these changes cannot be integrated to the main branch now. Maybe, you should receive feedback from someone who does code review your changes. Maybe, these changes deem too risky to be integrated now. Maybe, they will clash with someone else's work, which has a higher priority, maybe something else. So, I don't see how you expect Git to know all of that. It is like to expect that your word processor to know what whether your document is good work publication or not, and don't let you to send the document out if it is not. Dmitry -- 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
