Hi, On Fri, 30 Jan 2009, Jay Soffian wrote: > On Thu, Jan 29, 2009 at 7:34 PM, Johannes Schindelin > <johannes.schindelin@xxxxxx> wrote: > > Many, many users set up non-bare repositories on their server, and are > > confused that the working directory is not updated. > > This comes up on the list from time-to-time and is even in the FAQ. So much so that it is high time we admitted that we have a design bug there. > It has even been suggested that HEAD be detached when pushing into a > non-bare repository, but I am not suggesting that again. No, because that would be as wrong as trying to update the working directory in any other way. (Not only is it possible that you are a git-shell user, in which case you have no business meddling with the working directory -- or the symbolic ref HEAD -- to begin with, but you also run into the problem that you might not know where the working directory is at all, let alone if there is one.) So it is a good thing you are not suggesting it again. > I wonder if it might be helpful to teach clone to setup a push line in > the cloned repo. i.e.: > > [remote "origin"] > url = ... > fetch = +refs/heads/*:refs/remotes/origin/* > push = refs/heads/*:refs/remotes/origin/* > > This could be a configurable default behavior when cloning from a > non-bare repo (can that be determined?) and/or as a switch > (--satellite perhaps?). As Peff commented, this would be horribly wrong if the remote has a different "origin" remote. Not forcing the push does not help either, it is still wrong. But I think there is an even more fundamental problem: You do not want that default push. We have "push only those refs the remote and the local repository share" rule for a reason. It is way too easy to publish something you did not mean to publish otherwise. Ciao, Dscho -- 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
