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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:

> Exactly the same as 'git pull' does right now.

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.

> 'base' has absolutely nothing to do with pulling or pushing.

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).
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]