On Mon, 28 Nov 2005, Junio C Hamano wrote: > Daniel Barkalow <barkalow@iabervon.org> writes: > > > the two-way merge. That is, what I want to have work is: > > > > server$ git checkout production > > work$ git push server:production > > server$ git checkout > > > > and this should leave the working tree on server with the changes pushed > > from work. > > I think the approach Linus was suggesting before he suggested > the funny refs/heads/../.. symlink idea (honestly, I think he > was half joking) is cleaner, easier to understand, easier to > implement and generally makes more sense. Your work cycle would > become like this: > > server$ git checkout production > work$ git checkout master > work$ git pull server production ;# merge into work's master > work$ git push server master:receive_from_work > server$ git pull . receive_from_work ;# merge into server's production > > and you make sure receive_from_work is not checked out on server > (or production is never pushed into) and always do fast forward > and nothing else. That's what I'm doing currently, actually (with work pushing to "production", but server having checked out "deploy"), and I find it annoying to have to do the pull each time and have a separate head. It also means that, if the stuff on the server is set up as a hook, it'll have to do the locking against concurrent changes to the working tree in pull, which is much more complicated than checkout. It's also somewhat non-intuitive, and leaves a surprising way for the user to confuse the system in a way that it can't detect. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Tue Nov 29 17:58:30 2005
This archive was generated by hypermail 2.1.8 : 2005-11-29 17:58:36 EST