Hi, On Thu, 20 Apr 2006, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > However, this all depends on my (rejected) patch to move the remotes > > information into the config file. > > You seem to keep saying rejected, but IIRC you did not finish it I had another impression: people seemed less than enthusiastic about it. But maybe I misunderstood, and only the automatic rewriting part was disliked. I'll try to find time to clean the patch and resend it... > While we are talking about per branch property, some issues > raised on the list (and #git) recently would be helped by a > convention (and perhaps some core side support) for per-branch > property. Here is a short list. > > + When I am on branch X, I would want "git pull" to pull > (i.e. fetch and merge) from repository Y, not always "origin". > > + When I am on branch X, I would want "git push" to push to > repository Y (we do not even use "origin" as the default for > push). > > + This branch is not to be rebased (you could do this using > custom pre-rebase hook but having a standard "branch property" > would make it easy for such a hook to decide. > > - Do not merge and base your work on this branch -- this is > "view only" and unstable (e.g. "pu" in git.git). > > If we were to do a remote to config reorganization (for that we > need a migration plan and a period that we support both), the > per-branch configuration should be designed to support at least > the commonly asked ones. Hmm. ATM the syntax I use is [remote.company] url = company.com:gits/daproject pull = origin push = master Some bits of your wishes could be written as [branch.pu] rebase = no pull = company Ciao, Dscho - : 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