On Fri, Sep 28, 2007 at 06:52:47AM +0000, Steffen Prohaska wrote: > > On Sep 27, 2007, at 9:22 PM, Junio C Hamano wrote: > > > > >So what's the desired semantics? > > > >The current semantics is: > > > > "git push" says "you do not say to which repository?" and > > consults "branch..remote" but defaults to 'origin' > > if unconfigured. > > > > "git push " (or using the determined as above) > > says "you do not say which branches?" and consults > > "remote..push" to find branches to push out, but > > defaults to 'matching branches' if unconfigured. > > > >What you would want to change is the fallback behaviour for > >unconfigured "remote..push". I think it is sensible to > >have an option to make it push only the current branch. > > I'm not sure that changing the fallback behaviour for unconfigured > "remote..push" is sufficient. > > When "remote..push" is set I'd expect "git push" to > choose only the 'right' remote..push lines, that is > the lines that have the current branch as the local ref. > "git push" would only push the current branch, which could be pushed > to 0 or more branches on the remote side. If no "remote..push" > contains the current branch as a local ref nothing would happen > (maybe a warning?). If several "remote..push" have the current > branch as the local ref the branch would be pushed to several > remote branches. But other branches than the current branch > would _never_ be pushed if no argument is given to 'git push'. I'm not really sure that it makes sense, as by default, git push won't create a new remote ref. So unless you have a branch that matches some remote ref, but that you never want to push, even when on it and typing git push... there is nothing that could happen by mistake. So if you don't want to push such a branch, ever, then you should IMHO not name it in a way that it matches a refspec in the first place, and be safe. So I do not believe we need that extra complexity. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org