Matthieu Moy <Matthieu.Moy@xxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Having said that, I am not sympathetic to "I have to remember". > > That's definitely not an important point, but I find it conveinient, > for example in hg, to be able to just "hg update" to get to the tip of > a branch. > > A use-case (which joins the one of Salikh actually) is to publish both > a repository and a working tree (I do that for my collegues which may > or (usually) may not use git). Making a hook to update the working > tree after a push is a terrible hack in git, and just "hg update" in > Mercurial. That's a different issue. The reason push-into-a-live-tree works that way in Hg is because they have this implicit notion of unmerged heads that is merged with the next "hg update". We don't. Instead, we are more explicit. If you want to emulate that workflow in git, you would prepare a reception branch, and have people push into it (see gitfaq and look for "sync out of a firewalled host". In the FAQ entry, pretend as if machineA is such a live work tree you are working in, and allow people to push into --- that B/master is the reception branch, although the FAQ entry is about your private use and written as if only you from a satellite machine can push into it, it can easily be a shared branch). Instead of saying "hg update", you (the person working in such a live work tree that allows others to push into) merge that reception branch. - 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
