On Fri, Mar 20, 2009 at 03:13:19AM -0400, Jeff King wrote: > On Fri, Mar 20, 2009 at 12:08:51AM -0700, Junio C Hamano wrote: > > > > First, commit your changes. Then merge the other developer's changes. :) > > > > We should probably point out to new people that "first commit and then > > worry about merges after your changes are safely committed" is always how > > people would "go about" anything. > > Yes, absolutely. > > Most of the current documentation focuses on being a reference to > particular commands or tasks. But this is more of a "philosophy of > working with git" item. I guess it should go in the user manual > somewhere. Cc'ing Bruce, who may have some comments. I agree, that's kind of an odd hold in the user manual. Maybe it goes without saying, but it might be useful somewhere in ch. 3, maybe when introducing commits, something along the lines of: "note all of these commits are stored only in your local repository, and are visible only to you. With some version control systems, "committing" requires sending the commit to a central server. With git, you are expected to do all your work locally and only merge with others' work when necessary; we'll learn how to do that in <chapter 4>." And then say something similar again at the start of chapter 4? --b. -- 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
