From: "Dan McGee" <dpmcgee@gmail.com>
To: git@vger.kernel.org
Subject: Re: Update local tracking refs when pushing- no way to disable
Date: Fri, 6 Jul 2007 09:20:02 -0400 [thread overview]
Message-ID: <449c10960707060620t3538b6d7w3e9cba50eaa0e369@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0707052320090.14638@iabervon.org>
On 7/5/07, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Thu, 5 Jul 2007, Dan McGee wrote:
>
> > In this commit:
> > b516968ff62ec153e008d033c153affd7ba9ddc6
> >
> > I don't know if anyone else has the same way of working as I do, but I
> > tend to set the "remote.<name>.skipDefaultUpdate" property to true for
> > my publicly visible repository, just so I don't have duplicate branch
> > heads lying around in my local repository. Call this peculiar, but I
> > like it that way. However, git-push does not respect this property,
> > meaning I know have these branches whether I want them or not. In a
> > tool such as qgit or even 'git branch -a' output, it starts to get
> > awful cluttered.
>
> What git-fetch and git-push care about is whether you have an entry
> "remote.<name>.fetch" with a colon and stuff on the right of it. If so,
> this is a pattern that is used to generate the duplicate branch heads that
> you don't want. git clone sets it up to a default pattern
> (refs/remotes/origin/*), and I don't think there's any way to make it not
> do that, but you can just reconfigure it afterwards if you don't like it.
Wow, my bad here on this one. Didn't even think about the default config line:
[remote "toofishes.net"]
url = toofishes.net:~/gitprojects/shoepolish.git/
fetch = +refs/heads/*:refs/remotes/toofishes.net/*
push = +refs/heads/*:refs/heads/*
Getting rid of that fetch line makes it work as intended. And not to
hijack my own thread, but did behavior change between 1.5.2.3 and
1.5.3 wrt non-subset pushes?
$ git push toofishes.net
error: remote 'refs/heads/alpm_list_speed' is not a strict subset of
local ref 'refs/heads/alpm_list_speed'. maybe you are not up-to-date
and need to pull first?
error: remote 'refs/heads/asciidoc' is not a strict subset of local
ref 'refs/heads/asciidoc'. maybe you are not up-to-date and need to
pull first?
error: remote 'refs/heads/color' is not a strict subset of local ref
'refs/heads/color'. maybe you are not up-to-date and need to pull
first?
error: remote 'refs/heads/permissions' is not a strict subset of local
ref 'refs/heads/permissions'. maybe you are not up-to-date and need to
pull first?
error: remote 'refs/heads/pkgname_check' is not a strict subset of
local ref 'refs/heads/pkgname_check'. maybe you are not up-to-date and
need to pull first?
updating 'refs/heads/working'
from 59d9ccf48d84fd1e59f78cb4dcf428e53d1c6911
to 6b7b9743181078aa7152daffdfc1eaeb46304c0f
Generating pack...
Done counting 0 objects.
Writing 0 objects...
Total 0 (delta 0), reused 0 (delta 0)
refs/heads/working: 59d9ccf48d84fd1e59f78cb4dcf428e53d1c6911 ->
6b7b9743181078aa7152daffdfc1eaeb46304c0f
I thought the '+' sign in the push refspec would supress these errors,
but it doesn't seem to. Running 'git push -f' works but that was never
necessary before after doing some rebasing of these branches.
-Dan
prev parent reply other threads:[~2007-07-06 13:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-06 0:22 Update local tracking refs when pushing- no way to disable Dan McGee
2007-07-06 1:17 ` Johannes Schindelin
2007-07-06 1:31 ` Junio C Hamano
2007-07-06 3:37 ` Daniel Barkalow
2007-07-06 8:26 ` Marco Costalba
2007-07-06 8:42 ` Shawn O. Pearce
2007-07-06 12:46 ` Johannes Schindelin
2007-07-06 18:56 ` Daniel Barkalow
2007-07-06 18:59 ` Johannes Schindelin
2007-07-06 19:20 ` Daniel Barkalow
2007-07-06 19:46 ` Johannes Schindelin
2007-07-06 13:20 ` Dan McGee [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=449c10960707060620t3538b6d7w3e9cba50eaa0e369@mail.gmail.com \
--to=dpmcgee@gmail.com \
--cc=git@vger.kernel.org \
/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).