Re: [RFC] New kind of upstream branch: base branch

Felipe Contreras <felipe.contreras@gmail.com> writes:

You set

	[branch 'foobar']
        	base = refs/heads/master

then 'git pull [--rebase]' will go to 'origin' due to the default, but then what branch from the 'origin' are you integrating with?

Do you mean you are also setting both remote and upstream, perhaps like this, for all of your branches?

	[remote "origin"]
		url = github.com:maintainer/hisproject
                fetch = +refs/heads/*:refs/remotes/origin/*

	[remote "github"]
        	url = github.com:felipec/myproject
                fetch = +refs/heads/*:refs/remotes/github/*

	[branch 'foobar']
        	base = refs/heads/master
		remote = github ;# or is it origin???
                upstream = refs/heads/foobar

Then your 'git pull' will fetch from remote 'origin' and integrate with its 'foobar' and 'push' may go to update 'foobar' at 'github'.

Perhaps that is what you meant.

I agree it shouldn't have anything to do with pushing, but given that 'git pull [--rebase]' is a way to do a 'merge' or 'rebase' with what you 'git fetch', introducing something that 'merge' or 'rebase' pays attention to that does not have anything to do with 'pull' sounds like it breaks existing end user expectation.

But that does not mean it is a bad idea. The behaviour changes only when you have branch.$name.base, so I suspect that we do not need to worry about "what if the user has both?" case you mentioned in your first message.

I think I misunderstood what you meant. If it is the norm to have both base and upstream/remote in branch.$name (as opposed to "have only branch.$name.base and not branch.$name.remote to force fetch to go to the default 'origin'), then 'git pull' will not break and I can see how many things would work naturally (admittedly I can only say 'many things', not 'everything', at this point, as I haven't thought things through).