git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzesimir Nowak <krzesimir@endocode.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC] make --set-upstream work for local branches not in refs/heads
Date: Thu, 06 Mar 2014 10:27:28 +0100	[thread overview]
Message-ID: <1394098048.2050.19.camel@localhost.localdomain> (raw)
In-Reply-To: <xmqqlhwpkats.fsf@gitster.dls.corp.google.com>

On Tue, 2014-03-04 at 11:44 -0800, Junio C Hamano wrote:
> Krzesimir Nowak <krzesimir@endocode.com> writes:
> 
> > 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.

I always have problems with proper use of git's terminology. Sorry.

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

Hm, have some idea about it, though I will leave its sanity to judge to
you.

Given the following config snippet:
[remote "origin"]
	url = ssh://user@example.com/my-project
	fetch = +refs/heads/*:refs/remotes/origin/*
	fetch = +refs/wip/*:refs/remotes/origin-wip/*

We could have get_local_ref_hierarchies function defined somewhat as
follows (memory management details are left out):

char **get_local_ref_hierarchies(char *remote)
{
	char **refspecs = get_fetch_refspecs_for_remote (remote);
	char **iter;
	char **local = NULL;

	for (iter = refspecs; iter && *iter; ++iter) {
		char *src = get_src_refspec_part (*iter);
		push (&local, src);
	}

	/* maybe filter dups and make refs/heads/ first */
	return local;
}

I'm sure that there are some corner-cases this code does not handle.

Also, maybe it would be good to add some information when --set-upstream
does nothing. Something like after doing "git push --set-upstream origin
test:refs/wip/test":

"""
Could not set temp to track refs/wip/test. Either call:
git config branch.test.remote origin
git config branch.test.merge refs/wip/test

or (this part would appear if this solution in patch is accepted)

git config --add remote.origin.fetch \
"+refs/wip/*:refs/remotes/origin-wip/*
"""

Cheers,
-- 
Krzesimir Nowak
Software Developer
Endocode AG

krzesimir@endocode.com

------
Endocode AG, Johannisstraße 20, 10117 Berlin
info@endocode.com | www.endocode.com

Vorstandsvorsitzender: Mirko Boehm
Vorstände: Dr. Karl Beecher, Chris Kühl, Sebastian Sucker
Aufsichtsratsvorsitzende: Jennifer Beecher

Registergericht: Amtsgericht Charlottenburg - HRB 150748 B

      reply	other threads:[~2014-03-06  9:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-04 14:07 [RFC] make --set-upstream work for local branches not in refs/heads Krzesimir Nowak
2014-03-04 14:07 ` [PATCH] RFC: make --set-upstream work for branches not in refs/heads/ Krzesimir Nowak
2014-03-04 19:44 ` [RFC] make --set-upstream work for local branches not in refs/heads Junio C Hamano
2014-03-06  9:27   ` Krzesimir Nowak [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1394098048.2050.19.camel@localhost.localdomain \
    --to=krzesimir@endocode.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).