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