Update local tracking refs when pushing- no way to disable

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.

I'm not terribly familiar with GIT internals, so I don't know that I am the best to make a patch for this, but I'll take no response as a answer that I should start coding something up. Please CC me on emails, I'm not on the GIT mailing list.

-Dan

Hi,

[on this list, it is considered polite to not cull the Cc list anyway]

On Thu, 5 Jul 2007, Dan McGee wrote:

You might be interested to look only at the changes to builtin-push.c. I have a hunch that you just need to disable setting the remote if "remote.<name>.skipDefaultUpdate" is set.

Of course, for that to work, you would also need to add a member variable to struct remote in remote.h, and handle it at the end of handle_config() in remote.c.

Then just use remote->skip_default_update in builtin-push.c, to guard around lines 90--93.

As for submitting, please read Documentation/SubmittingPatches first, it is not really long, and most of it is obvious.

Hth, Dscho

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

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.

On Thu, 5 Jul 2007, Dan McGee wrote:

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.

I can't see where git-push would get the names to use if you don't have such an entry, and having the entry isn't useful if you actually don't want those refs. It's probably just a matter of deleting it, since it was probably created for you by some tool trying to be helpful.

(AFAICT, the only additional stuff that -a shows with git branch is the stuff that you're deleting; perhaps qgit should have an option to not show remotes, or not show them by default or only show them if what they point to isn't otherwise marked? Anyway, it shouldn't be necessary to avoid having this information just so that it isn't shown in interfaces you use.)

	-Daniel
*This .sig left intentionally blank*

On 7/6/07, Daniel Barkalow <barkalow@iabervon.org> wrote:

Probably an option "show remote branches" from a popup context menu (right click) is the more natural and predictable solution.

In case someone is interested, please confirm me, I will add that.

Marco

Marco Costalba <mcostalba@gmail.com> wrote:

Recently I was faced with handling a repository that has over 200 local refs/heads and 200+ refs/remotes that the user might be interested in working on. Yea, its fun to look at in gitk. It is not fun to run `git fetch` when on Cygwin.

Anyway, the git-gui `pu` branch now has new UI to handle these sorts of cases rather nicely. The revision selection mega-widget that I recently wrote lets the user select which "class" of ref (head, tracking branch, tag) they want and then filter them using a substring glob filter. The trick works very well to let the user weed the list of 400+ possible refs down to just a couple that they can pick from with the keyboard, or the mouse.

The UI will be in 0.8.0. Which I'm hoping to go into an rc status later this week.

Minor warning: currently the `pu` branch of git-gui probably requires git 1.5.3-rc0 or later. It doesn't test for it and just assumes your git is new enough. I do plan on fixing the couple of spots that might matter to be conditional and fallback gracefully if 1.5.3 isn't available. Just haven't done it yet. Those will be fixed before they merge to `master`.

Hi,

On Thu, 5 Jul 2007, Daniel Barkalow wrote:

Related, but not identical, is the problem illustrated in http://thread.gmane.org/gmane.comp.version-control.git/49888

IMHO there is a bug. IIUC git push first looks for common ref names on the local and remote side (yes, refs/remotes are excluded since v1.5.3-rc0~9, but the underlying problem is still there). Then it pushes them. But here, something seems to have gone wrong: refs/remotes/origin/HEAD is a symref. And the corresponding ref is updated. Should git-push not just _not_ update symrefs?

Ciao, Dscho

On Fri, 6 Jul 2007, Johannes Schindelin wrote:

I believe this actually have nothing to do with git-push; it's actually git-receive-pack and maybe git-send-pack. Probably git-receive-pack shouldn't list symrefs at all, or should somehow report them as links so that they can be compared as links. The only refs that git-push itself updates are tracking refs on the local side for refs on the remote side which were updated. In the report, the reporter had (obviously) not configured any local tracking refs for the remote's tracking refs.

Now, if there are symref heads on the remote (maybe somebody wants to have a "dominus" branch which is a symref to "master" for people who only speak Latin), and this was in tracking refs as a symref as well, and the user pushed to both (with the remote side somehow identifying that the same change is being made to both names, and that's okay), then the tracking refs would need this same logic as well. But that requires an unimplemented and unrequested feature, with fixes in a number of other places first, before it's even possible to have git-push need to worry about it.

	-Daniel
*This .sig left intentionally blank*

Hi,

On Fri, 6 Jul 2007, Daniel Barkalow wrote:

Sorry, I think I did not make myself clear. The updates refs were _local_ refs. And they _were_ symrefs.

Ciao, Dscho

On Fri, 6 Jul 2007, Johannes Schindelin wrote:

No, no local refs were updated. This would have given the message "Also local refs/remotes/origin/HEAD", which wasn't there. What was updated was tracking refs on the remote (which were created as local tracking refs when somebody was running git commands local to the repository which, for the failing command, was remote). The logic for updating local refs on a push was not used at all in this case, according to the output in the message you linked to.

	-Daniel
*This .sig left intentionally blank*

Hi,

On Fri, 6 Jul 2007, Daniel Barkalow wrote:

Okay, I misunderstood, then.

Sorry for the noise, Dscho

On 7/5/07, Daniel Barkalow <barkalow@iabervon.org> wrote:

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