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:

In this commit:
b516968ff62ec153e008d033c153affd7ba9ddc6

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

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.

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 [off-list ref] wrote:

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

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 [off-list ref] wrote:

On 7/6/07, Daniel Barkalow [off-list ref] wrote:

quoted

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

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

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

-- 
Shawn.

Hi,

On Thu, 5 Jul 2007, Daniel Barkalow 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.

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 7/5/07, Daniel Barkalow [off-list ref] wrote:

On Thu, 5 Jul 2007, Dan McGee wrote:

quoted

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

On Fri, 6 Jul 2007, Johannes Schindelin wrote:

Hi,

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?

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:

On Fri, 6 Jul 2007, Johannes Schindelin wrote:

quoted

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?

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.

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:

Hi,

On Fri, 6 Jul 2007, Daniel Barkalow wrote:

quoted

On Fri, 6 Jul 2007, Johannes Schindelin wrote:

quoted

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?

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.

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

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:

On Fri, 6 Jul 2007, Johannes Schindelin wrote:

quoted

On Fri, 6 Jul 2007, Daniel Barkalow wrote:

quoted

On Fri, 6 Jul 2007, Johannes Schindelin wrote:

quoted

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?

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.

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

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.

Okay, I misunderstood, then.

Sorry for the noise,
Dscho