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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.