Re: Update local tracking refs when pushing- no way to disable

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 6, 2007, 01:31 UTC
Message-ID: <7v8x9uiai0.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <449c10960707051722q6650ec7dq6012695acdfba4af@mail.gmail.com>

"Dan McGee" <dpmcgee@gmail.com> writes:

Show 11 quoted lines

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

Actually I do not think git-push nor git-fetch are related to what that configuration variable tries to control at all. The variable controls what "git remote update" does.

Do you fetch from your 'publicly visible repository', and do you use tracking branches for it when you do "git fetch" from there?

    $ git push my-public

is supposed to pretend that immediately after the push you did "git fetch my-public" _if_and_only_if_ your "git fetch my-public" would fetch the branches you pushed, and you have configured to store them in .git/refs/remotes/my-public/ (i.e. your tracking branches). So if you do not fetch from your remote and do not have configuration to use tracking branches when you fetch from there, and if you still see that your push updates your tracking branches, then you found a bug.

But if you do have configuration to use tracking branches when you fetch from there, that is a different story. I do not think there currently is a way to disable that "pretend we have fetched back immediately" behaviour. There could be valid reasons that you may _want_ to keep your existing tracking branches stale after a push, in which case we may want to make it overridable, but at the time that change was accepted, nobody had such a convincing use scenario.