On Sun, Jan 24, 2010 at 06:59:10PM -0500, Jay Soffian wrote: > > http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch > > Aside, and I think we've discussed this before, but I wonder if it > would make sense to: > > a) Add an option to clone such as "-p [<name>] | --push-as[=<name>]" > where <name> defaults to $(uname -n | cut -f1 -d.) This would setup > the cloned repo with a push refspec > "+refs/heads/*:refs/remotes/<name>/*". e.g.: > > $ git clone -o host1 -p host2 ssh://host1/~/repo.git > $ cat repo/.git/config > ... > [remote "host1"] > url = ssh://host1/~/repo.git > fetch = +refs/heads/*:refs/remotes/host1/* > push = +refs/heads/*:refs/remotes/host2/* One problem with this scheme is that it actually does two things: 1. Tells git to push into the refs/remotes/host2/ hierarchy instead of refs/heads/. 2. Overrides matching behavior to push all heads. Point (2) is less of a problem than it is without (1) in the sense that you are pushing to a unique namespace, so you don't have to worry as much about your crappy half-finished branches filling up the main branch namespace. But you might not want them publicized at all, either because they are embarrassingly bad or simply because it is cruft that you will encounter later and wonder "is this branch, which is missing from my local repositor (presumably from a long-ago deletion) but present upstream of any value at all?" I can't think offhand of a way to get the behavior of (1) without (2). I know we have a shorthand refspec for "matching", but this would not strictly be matching. It is "convert refs/heads/X into refs/remotes/blah/X, and _then_ match". If we had a refspec that worked in that manner, I would think it's a pretty good idea (even to turn it on by default for non-bare repos). > b) The controversial part: make this option the default the default > when cloning from a non-bare repo. There would need to be some way to > turn it off. Hmm. Do we reliably know from the client side whether a remote is bare or not? > Of course, I'm not sure this would be any less confusing for users. > Would they wonder why they have to merge to see their pushed changes > reflected on the pushed-to repo? Yes, I think we would still have the FAQ of "I pushed my changes, where did they go?" but at least the answer would be "git merge foo" and not "what you are doing is confusing to git and you need to figure out what kind of workflow you want, redo your push, and then git merge foo". Which seems like an improvement to me. ;) -Peff -- 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