Steffen Prohaska <prohaska@xxxxxx> writes: > On Nov 22, 2007, at 2:48 AM, Junio C Hamano wrote: > ... >> An alternative could be to split [remote "name"] url into two >> variants, fetch-url and push-url. While fetching by default >> from two places without telling from which one does not make any >> sense, pushing by default to two different places is quite a >> normal thing to do, and we already do support more than one url >> entries in [remote "name"] section used for pushing. >> >> If we were to do this, it might also make sense to rename the >> word 'origin' we use for the default remote name to 'default' or >> something. People with shared repository workflow would fetch >> from one repository and push back to the same repository, so the >> distinction would not matter, but for others who need something >> like you suggest, the default repository for fetching and >> pushing are different, and while you may still consider where >> you fetch from your 'origin', where you push into is not your >> 'origin' anymore. > > I like this idea. > > But in addition, we should have a branch.$name.push line that > can contain a remote head to push to. Yes, but. At that point, I think you would introduce a mismatch between the traditional semantics of refspec and what you are trying to do, unless you are careful. The traditional semantics of refspecs-tied-to-remote is strongly based on the assumption: "I will push to this remote when these local branches are all ready to be pushed out, and they will all go there together as an atomic update. When I am _that_ ready to push, it does not matter which local branch I am on. The branches that matter are all in good shape when I push." You are making the behaviour of push dependent on which branch you are on. During such a push, it is safe to assume that the current branch is ready to be pushed out, but other ones can be very much un-ready. The user needs a safety valve to prevent other branches from being pushed out. Otherwise the user would not be adding branch.$name.push to begin with. It would probably need to become a target ref or a list of <URL, target ref>, not a list of general refspecs like the value for remote.$there.push variable. For example, you would want to say "while on master, push it to repository A as refs/heads/master and to repository B as refs/remotes/satellite/master", which would be a typical arrangement if you are working on a satellite machine, A is the shared central repository and B is mothership to your satellite machine. The specification would talk only about the target ref (not just "'can contain' a remote head to push to"), and the source ref would always be the current branch. I guess you could use general refspec on branch.$name.push and implement the safety by requiring (1) only one refspec appears for such a variable, and (2) the LHS of the refspec matches the $name of the branch, in order to make the parsing easier and to keep the syntax uniform. Or maybe I am being overly cautious again not to introduce any more unnecessary user confusion, and just should give them even longer rope to hang themselves. I dunno. - 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
