Re: [RFC] make --set-upstream work for local branches not in refs/heads

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 4, 2014, 19:44 UTC
Message-ID: <xmqqlhwpkats.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1393942046-11488-1-git-send-email-krzesimir@endocode.com>

Krzesimir Nowak <krzesimir@endocode.com> writes:

Show 24 quoted lines

> It might be possible (in "Gerrited" setups) to have local branches
> outside refs/heads/, like for example in following fetch config:
>
> [remote "origin"]
> 	url = ssh://user@example.com/my-project
> 	fetch = +refs/heads/*:refs/remotes/origin/*
> 	fetch = +refs/wip/*:refs/remotes/origin-wip/*
>
> Let's say that 'test' branch already exist in origin/refs/wip/. If I
> call:
>
> git checkout test
>
> then it will create a new branch and add an entry to .git/config:
>
> [branch "test"]
> 	remote = origin
> 	merge = refs/wip/test
>
> But if I create a branch 'test2' and call:
>
> git push --set-upstream origin test2:refs/wip/test2
>
> then branch is pushed, but no entry in .git config is created.

By definition anything otuside refs/heads/ is not a branch, so do not call things in refs/wip "branches". Retitle it to "work for local refs outside refs/heads" or something.

Having said that, I do not see a major problem if we allowed

	[branch "test2"]
		remote = origin
                merge = refs/wip/test2

to be created when "push --setupstream" is requested, making test2@{upstream} to point at refs/remotes/origin-wip/test2.

I do not know what the correct implementation of such a feature should be, though.