Update local tracking refs when pushing- no way to disable

Update local tracking refs when pushing- no way to disable

[Dan McGee]

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

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

[Johannes Schindelin]

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

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

[Junio C Hamano]

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

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

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

[Daniel Barkalow]

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*

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

[Marco Costalba]

On 7/6/07, Daniel Barkalow <barkalow@iabervon.org> 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

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

[Shawn O. Pearce]

Marco Costalba <mcostalba@gmail.com> wrote:
> On 7/6/07, Daniel Barkalow <barkalow@iabervon.org> 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.

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.

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

[Johannes Schindelin]

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

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

[Daniel Barkalow]

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*

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

[Johannes Schindelin]

Hi,

On Fri, 6 Jul 2007, Daniel Barkalow wrote:

> On Fri, 6 Jul 2007, Johannes Schindelin 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?
> 
> 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

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

[Daniel Barkalow]

On Fri, 6 Jul 2007, Johannes Schindelin wrote:

> Hi,
> 
> On Fri, 6 Jul 2007, Daniel Barkalow wrote:
> 
> > On Fri, 6 Jul 2007, Johannes Schindelin 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?
> > 
> > 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*

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

[Johannes Schindelin]

Hi,

On Fri, 6 Jul 2007, Daniel Barkalow wrote:

> On Fri, 6 Jul 2007, Johannes Schindelin wrote:
> 
> > On Fri, 6 Jul 2007, Daniel Barkalow wrote:
> > 
> > > On Fri, 6 Jul 2007, Johannes Schindelin 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?
> > > 
> > > 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

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

[Dan McGee]

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