Re: [PATCH v2 6/9] branch: display publish branch
Jeff King wrote:
> On Sat, Apr 12, 2014 at 10:05:15AM -0500, Felipe Contreras wrote:
>
> > As you can see; some branches are published, others are not. The ones that
> > are
> > not published don't have a @{publish}, and `git branch -v` doesn't show
> > them.
> > Why is that hard to understand?
>
> Do you ever push the unpublished branches anywhere at all? If not, then
> you would not have a tracking branch. E.g., git _would_ push to remote
> "gh", branch "refs/heads/topic", but there is no remote tracking branch
> "refs/remotes/gh/topic", because you have never actually pushed there.
> So there is no @{publish} branch.
>
> Or do you have some branches in a state where they are "pushed, but not
> published"? It wasn't clear to me from your example if your "pu" or
> "dev/remote/hg-extra" ever get pushed.
Sometimes I do push these branches, but I don't understand what you mean by
"pushed state". When you push something no states are changed. Say I do:
% git push tmp wip-feature
% git push backup wip-feature
So I pushed a branch to two different repositories, the former one might not
even exist any more. Who cares? No states have changed. The fact that this
branch was pushed doesn't change anything about the nature of the branch.
> I do not use "git branch -v" myself,
Me neither (at least not the upstream version).
> so I don't personally care that much how it behaves. But I do use a separate
> script that does the same thing, and I would want it to show the ahead/behind
> relationship between each branch and where it would be pushed to (and as I
> said, I define mine with refspecs). Right now it uses nasty hackery to guess
> at where things will be pushed, but ideally it would ask git via @{push} or
> some similar mechanism.
Yes, but you can push a branch to many locations, to which one should the
script show the tracking information? IMO it should be the one location you
explicitly configured, and in the case of "wip-feature" is "no location".
> If the former (you do not actually push them), then I think the semantics I
> am looking for and the ones you want would coincide. If not, then I think we
> are really talking about two different things.
I ask again what is so difficult about the notion that there are two kinds of
branches?
A)
% git checkout ready-feature
% git push tmp ready-feature
% git push -p github ready-feature
% git push backup ready-feature
B)
% git checkout wip-feature
% git push tmp wip-feature
% git push backup wip-feature
In a haste these branches might not look very different, but conceptually they
are. One has a location where it is publicly visible, and where you wish to
push regularly, the other one doesn't.
Whether you push a branch or not is not really important, it's whether or not
the branch has a *special* place where you push to.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
On Sat, Apr 12, 2014 at 10:05:15AM -0500, Felipe Contreras wrote:
> As you can see; some branches are published, others are not. The ones that are
> not published don't have a @{publish}, and `git branch -v` doesn't show them.
> Why is that hard to understand?
Do you ever push the unpublished branches anywhere at all? If not, then
you would not have a tracking branch. E.g., git _would_ push to remote
"gh", branch "refs/heads/topic", but there is no remote tracking branch
"refs/remotes/gh/topic", because you have never actually pushed there.
So there is no @{publish} branch.
Or do you have some branches in a state where they are "pushed, but not
published"? It wasn't clear to me from your example if your "pu" or
"dev/remote/hg-extra" ever get pushed.
I do not use "git branch -v" myself, so I don't personally care that
much how it behaves. But I do use a separate script that does the same
thing, and I would want it to show the ahead/behind relationship between
each branch and where it would be pushed to (and as I said, I define
mine with refspecs). Right now it uses nasty hackery to guess at where
things will be pushed, but ideally it would ask git via @{push} or some
similar mechanism.
If the former (you do not actually push them), then I think the
semantics I am looking for and the ones you want would coincide. If not,
then I think we are really talking about two different things.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Jeff King wrote:
> On Fri, Apr 11, 2014 at 12:24:35PM -0700, Junio C Hamano wrote:
>
> > > But the branch.master.push setting does not do
> > > anything to "git push".
> >
> > I am not sure I understand this. I thought that the desire behind
> > the branch.*.push is to allow something like:
> >
> > ... other things in the config ...
> > [remote]
> > pushdefault = foo
> > [remote "foo"]
> > url = ...
> > push = +refs/heads/*:refs/remotes/satellite/*
> > fetch = +refs/heads/*:refs/remotes/foo/*
> > [branch "master"]
> > ; pushremote = foo
> > push = refs/heads/bar
> >
> > so that "git push" on 'master' will override the more generic "all
> > local branches here will go to their remote-tracking hierarchy for
> > this satellite" refspec. And in that sense branch.master.push would
> > do something to "git push".
>
> Ah, I see. If I set "push.default" to "upstream", then the config I
> showed before _does_ affect "git push". But I do not usually do that. I
> have push.default set to "current", and sometimes override it using push
> refspecs on certain repositories.
>
> And that is why I find branch.*.push and Felipe's @{publish} useless for
> my workflow. Pushes already go where I want them to, and I just want a
> way to ask git to perform that config resolution for me. Whereas
> Felipe's workflow is (I think) something like:
>
> # make a new branch...
> git checkout -b topic origin/master
>
> # now publish our branch, and remember our publishing point
> git push -p my-repo topic
>
> # and now further pushes automatically go to my-repo/topic
> git push
>
> I can see there is some value in that override if you do things like:
>
> git push -p my-repo topic:some-other-name
>
> because the "-p" means "remember this other name I gave".
>
> I would think in such a workflow that most of your branches would end up with
> publish config, though. And therefore @{publish} would become equivalent to
> "where you would push".
> But Felipe indicated that he would not want "branch -vv" to match where all
> branches would be pushed, but rather only those that were specifically
> configured. So maybe I do not understand his workflow after all.
It's a pretty typical triangular workflow, with a touch of fork maintainership.
Here are some types of branches I have:
* master [origin/master, gh/master] Git 1.9.1
My main master branch, I use it as a base point for many other branches. I
don't use origin/master because that's a moving target.
* dev/remote/hg-extra [master] remote-hg: store extra hg information in notes
A development branch. I don't publish those, therefore no @{publish}.
* fc/publish [fc/branch/nice-verbose, gh/fc/publish] sha1_name: add support for
@{publish} marks
A branch that is all good. I publish those, and use them for git-fc (my fork).
I think they should be in Git's core, but haven't been merged for some reason
or another.
Notice that the upstream branch is another local branch, not master. Strictly
speaking it's not an "upstream" branch, but I want 'git rebase' to use that as
the base point. Another @{base} concept might be more appropriate, but those
patches are a different story.
* up/publish [master] sha1_name: add support for @{publish} marks
A branch that should be sent upstream. I don't publish those.
Notice up/publish is different from fc/publish because the later depends on
another fc/* branch, which wasn't accepted upstream.
* fc/master [gh/fc/master] prompt: fix missing file errors in zsh
My main branch, used for git-fc. I merge Git's master, and cherry-pick various
fixes, so it has always the latest and greatest stuff.
Notice that 'gh/fc/master' is the publish branch, there is no upstream.
* pu [] Merge branch 'travis-ci' into pu
Similar to Junio's pu, I use `git reintegrate` to generate this branch using
'master' as the baseline, and merging all the fc/* branches. The result should
be identical to fc/master, if not, we are missing something from upstream, or
there's something missing in the fc/* branches.
It's not published, and has no upstream.
As you can see; some branches are published, others are not. The ones that are
not published don't have a @{publish}, and `git branch -v` doesn't show them.
Why is that hard to understand?
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Jeff King wrote:
> On Fri, Apr 11, 2014 at 08:48:01AM -0500, Felipe Contreras wrote:
>
> > I think of @{publish} as "the branch the user has configured to push
> > to"; it overrides all other configurations (push.default and push
> > refspecs). I wouldn't mind having a @{push} *in addition* to @{publish}
> > that would have the behavior you mention, but for @{publish} I'm pretty
> > certain the behavior I want is that it maps *directly* to what the user
> > has configured.
>
> I guess I don't understand why we need "branch.*.push" when we already
> have push refspecs that do the same thing (and are more powerful, as
> they can glob).
Really? I think it's pretty simple.
I have a configuration similar to the following
[remote "gh"]
url = g...@github.com:felipec/git.git
[branch "master"]
pushremote = gh
push = refs/heads/master
[branch "fc/master"]
pushremote = gh
push = refs/heads/fc/master
[branch "up/publish"]
pushremote = gh
push = refs/heads/fc/publish
Now, if I didn't, I could create it easily with something like this:
% git push -p gh master
% git push -p gh fc/master
% git push -p gh up/publish:fc/publish
How would that translate to push refspecs?
[remote "gh"]
url = g...@github.com:felipec/git.git
push = refs/heads/master:refs/heads/master
push = refs/heads/fc/master:refs/heads/fc/master
push = refs/heads/up/master:refs/heads/fc/publish
[branch "master"]
pushremote = gh
[branch "fc/master"]
pushremote = gh
[branch "up/publish"]
pushremote = gh
So in theory it could be possible to make it work without branch.x.push.
If I run `git branch -v`, it would show the publish branch correctly.
master cee0c27 [origin/master, gh/master] Git 1.9.1
However, if I have a configuration like this:
[remote "gh"]
url = g...@github.com:felipec/git.git
push = refs/heads/*:refs/heads/*
Git would still show the same publish branch, even though the user never
explicitely told it do to so (e.g. with `git push -p`). To me this is not OK;
if I haven't specifically set a publish branch, it shouldn't be shown.
And then, what happens when I do:
% git branch --unset-upstream up/publish
Or:
% git branch -d up/publish
Should Git remove the appropriate push refspec? What if that refspec was
manually added by the user before the concept of the publish branch even
existed?
To me using the refspec just adds more complications, and it's not symetric
with @{upstream}. With branch.x.push, the symetry is very much there; the code
is similar to @{upstream}, the configuration as well, and what the user expects
too; it's much simpler. Also, the user can clearly see what are his manually
configured refspecs, as opposed to the ones added by `git push -p`.
It's just neat.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
On Fri, Apr 11, 2014 at 12:24:35PM -0700, Junio C Hamano wrote:
> > But the branch.master.push setting does not do
> > anything to "git push".
>
> I am not sure I understand this. I thought that the desire behind
> the branch.*.push is to allow something like:
>
> ... other things in the config ...
> [remote]
> pushdefault = foo
> [remote "foo"]
> url = ...
> push = +refs/heads/*:refs/remotes/satellite/*
> fetch = +refs/heads/*:refs/remotes/foo/*
> [branch "master"]
> ; pushremote = foo
> push = refs/heads/bar
>
> so that "git push" on 'master' will override the more generic "all
> local branches here will go to their remote-tracking hierarchy for
> this satellite" refspec. And in that sense branch.master.push would
> do something to "git push".
Ah, I see. If I set "push.default" to "upstream", then the config I
showed before _does_ affect "git push". But I do not usually do that. I
have push.default set to "current", and sometimes override it using push
refspecs on certain repositories.
And that is why I find branch.*.push and Felipe's @{publish} useless for
my workflow. Pushes already go where I want them to, and I just want a
way to ask git to perform that config resolution for me. Whereas
Felipe's workflow is (I think) something like:
# make a new branch...
git checkout -b topic origin/master
# now publish our branch, and remember our publishing point
git push -p my-repo topic
# and now further pushes automatically go to my-repo/topic
git push
I can see there is some value in that override if you do things like:
git push -p my-repo topic:some-other-name
because the "-p" means "remember this other name I gave".
I would think in such a workflow that most of your branches would end up
with publish config, though. And therefore @{publish} would become
equivalent to "where you would push". But Felipe indicated that he would
not want "branch -vv" to match where all branches would be pushed, but
rather only those that were specifically configured. So maybe I do not
understand his workflow after all.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
On Fri, Apr 11, 2014 at 08:48:01AM -0500, Felipe Contreras wrote:
> I think of @{publish} as "the branch the user has configured to push
> to"; it overrides all other configurations (push.default and push
> refspecs). I wouldn't mind having a @{push} *in addition* to @{publish}
> that would have the behavior you mention, but for @{publish} I'm pretty
> certain the behavior I want is that it maps *directly* to what the user
> has configured.
I guess I don't understand why we need "branch.*.push" when we already
have push refspecs that do the same thing (and are more powerful, as
they can glob).
The behavior you describe is not useful to me, as it would mean having
to manage branch.*.push as a duplicate of the information that is
already found in "remote.$(git config remote.pushdefault).push". I do
not mind if the two co-exist, but please do not take the short @{p} as
your series does (not only because of @{push}, but also because @{pull}
has been mentioned elsewhere as a possible other name for @{upstream}).
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Junio C Hamano wrote:
> Jeff King writes:
>
> > For instance, it looks like your @{publish} requires config like:
> >
> > [branch "master"]
> > pushremote = foo
> > push = refs/heads/bar
> >
> > to operate. Setting "pushremote" affects what "git push" does; it will
> > go to the "foo" remote.
>
> OK, and the same thing would happen if branch.*.pushremote is not
> set for any branch, but remote.pushdefault is set to 'foo', right?
>
> > But the branch.master.push setting does not do
> > anything to "git push".
>
> I am not sure I understand this. I thought that the desire behind
> the branch.*.push is to allow something like:
>
> ... other things in the config ...
> [remote]
> pushdefault = foo
> [remote "foo"]
> url = ...
> push = +refs/heads/*:refs/remotes/satellite/*
> fetch = +refs/heads/*:refs/remotes/foo/*
> [branch "master"]
> ; pushremote = foo
> push = refs/heads/bar
>
> so that "git push" on 'master' will override the more generic "all
> local branches here will go to their remote-tracking hierarchy for
> this satellite" refspec. And in that sense branch.master.push would
> do something to "git push".
In my patches the above doesn't work; branch.master.push doesn't do anything if
.pushremote isn't there.
I'm always thinking from the common user's point of view, and the common user
doesn't know what branch.master.push is, but he knows he did
`git branch -p foo/bar master` (or something like that), and
`git branch -v` would corroborate that.
So you would have something like this:
[remote "foo"]
url = ...
push = +refs/heads/*:refs/remotes/satellite/*
fetch = +refs/heads/*:refs/remotes/foo/*
[branch "master"]
pushremote = foo
push = refs/heads/bar
> I personally think that kind of override adds any more values than
> it causes confusion, so I think it is OK not to support such uses of
> branch.*.push at all. A configuration without branch.master.push
> may cause "git push" on 'master' to update refs/heads/master at the
> remote,
How? If branch.master.push is not configured, then "git push" would push
'master' to refs/remotes/satellite/master on the remote.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Jeff King writes:
> For instance, it looks like your @{publish} requires config like:
>
> [branch "master"]
> pushremote = foo
> push = refs/heads/bar
>
> to operate. Setting "pushremote" affects what "git push" does; it will
> go to the "foo" remote.
OK, and the same thing would happen if branch.*.pushremote is not
set for any branch, but remote.pushdefault is set to 'foo', right?
> But the branch.master.push setting does not do
> anything to "git push".
I am not sure I understand this. I thought that the desire behind
the branch.*.push is to allow something like:
... other things in the config ...
[remote]
pushdefault = foo
[remote "foo"]
url = ...
push = +refs/heads/*:refs/remotes/satellite/*
fetch = +refs/heads/*:refs/remotes/foo/*
[branch "master"]
; pushremote = foo
push = refs/heads/bar
so that "git push" on 'master' will override the more generic "all
local branches here will go to their remote-tracking hierarchy for
this satellite" refspec. And in that sense branch.master.push would
do something to "git push".
I personally think that kind of override adds any more values than
it causes confusion, so I think it is OK not to support such uses of
branch.*.push at all. A configuration without branch.master.push
may cause "git push" on 'master' to update refs/heads/master at the
remote, and if we fetched from 'foo' immediately after pushing
there, it would come back as refs/remotes/foo/master, and it would
be natural for users to expect that master@{publish} would be
refs/remotes/foo/master in such a case.
If we supported setting branch.master.push to refs/heads/bar, then
master would be pushed as refs/heads/bar over there and it would
come back as refs/remotes/foo/bar here, so I would expect that to be
the value of master@{publish}.
> Only a push refspec (or push.default setting)
> will change that. So the "branch.*.push" must be kept in sync manually
> (perhaps by running "git push -p").
>
> Whereas if @{publish} means "where you would push to", then
> "branch.*.push" does not need to exist at all. The values can be taken
> automatically from the other push settings.
>
> -Peff
>
> PS I first tried just setting "branch.master.pushremote" without setting
>"branch.master.push". This results in a segfault, as branch_get()
>assumes that push_name is always set and tries to xstrdup() it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Jeff King wrote:
> On Thu, Apr 10, 2014 at 05:36:59PM -0500, Felipe Contreras wrote:
>
> > > I noticed that this only picks up a publish-branch if
> > > branch.*.pushremote is configured. What happened to the case when
> > > remote.pushdefault is configured?
> >
> > What happens when branch.*.remote is not configured for @{upstream}? The
> > same
> > thing.
>
> I don't know if that is a good comparison.
I think it is. @{publish} is like @{upstream}. Period.
> In other threads, the discussed meaning of @{publish} was something like
> "the tracking branch of the ref you would push to if you ran 'git push'
> without arguments".
And I disagree.
> That is consistent with @{upstream} being "the tracking branch of the
> ref you would pull from with 'git pull'". But "git pull" without a
> branch.*.remote will do nothing, so "what pull would do" is the same as
> "what you have configured in your branch.*.remote".
>
> Whereas "git push" does not depend on having branch.*.pushremote
> configured. Its behavior is based on push.default and push refspecs, so
> "what push would do" must take that into account.
Yes, but we are not talking about 'git push', we are talking about
@{publish}.
I think of @{publish} as "the branch the user has configured to push
to"; it overrides all other configurations (push.default and push
refspecs). I wouldn't mind having a @{push} *in addition* to @{publish}
that would have the behavior you mention, but for @{publish} I'm pretty
certain the behavior I want is that it maps *directly* to what the user
has configured.
Similarly, I don't want 'git branch -vv' to show @{push}; it would be a
mess to show something on all the branches, probably origin/$branch, and
probably all "ahead/behind". I want it to show @{publish}, so only the
branches the user has *explicitly* configured.
> > It might be useful to visualize what would be the name of the branch when
> > pushing it (without a refspec) even if the publish branch hasn't been
> > configured, but I think the code would be much more coplicated, and it would
> > break symetry with @{upstream}, besides, the user can just do 'git push -p
> > branch', and from that moment on it will be visible.
>
> It is more complicated (see the patches that Junio had at
> jk/branch-at-publish), but I think it is more likely to do what the user
> expects.
>
> For instance, it looks like your @{publish} requires config like:
>
> [branch "master"]
> pushremote = foo
> push = refs/heads/bar
>
> to operate. Setting "pushremote" affects what "git push" does; it will
> go to the "foo" remote. But the branch.master.push setting does not do
> anything to "git push". Only a push refspec (or push.default setting)
> will change that. So the "branch.*.push" must be kept in sync manually
> (perhaps by running "git push -p").
>
> Whereas if @{publish} means "where you would push to"
It doesn't mean that to me.
For the record, I've been thinking about this for a long long time, and
I argued for @{push} and @{publish} long before you discussed this in
January (which apparently you forgot). I implemented this more than half
a year ago, and have been using it since; it works great. The problem of
triangular workflows is pretty much solved for me.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
On Thu, Apr 10, 2014 at 05:36:59PM -0500, Felipe Contreras wrote:
> > I noticed that this only picks up a publish-branch if
> > branch.*.pushremote is configured. What happened to the case when
> > remote.pushdefault is configured?
>
> What happens when branch.*.remote is not configured for @{upstream}? The same
> thing.
I don't know if that is a good comparison.
In other threads, the discussed meaning of @{publish} was something like
"the tracking branch of the ref you would push to if you ran 'git push'
without arguments".
That is consistent with @{upstream} being "the tracking branch of the
ref you would pull from with 'git pull'". But "git pull" without a
branch.*.remote will do nothing, so "what pull would do" is the same as
"what you have configured in your branch.*.remote".
Whereas "git push" does not depend on having branch.*.pushremote
configured. Its behavior is based on push.default and push refspecs, so
"what push would do" must take that into account.
> It might be useful to visualize what would be the name of the branch when
> pushing it (without a refspec) even if the publish branch hasn't been
> configured, but I think the code would be much more coplicated, and it would
> break symetry with @{upstream}, besides, the user can just do 'git push -p
> branch', and from that moment on it will be visible.
It is more complicated (see the patches that Junio had at
jk/branch-at-publish), but I think it is more likely to do what the user
expects.
For instance, it looks like your @{publish} requires config like:
[branch "master"]
pushremote = foo
push = refs/heads/bar
to operate. Setting "pushremote" affects what "git push" does; it will
go to the "foo" remote. But the branch.master.push setting does not do
anything to "git push". Only a push refspec (or push.default setting)
will change that. So the "branch.*.push" must be kept in sync manually
(perhaps by running "git push -p").
Whereas if @{publish} means "where you would push to", then
"branch.*.push" does not need to exist at all. The values can be taken
automatically from the other push settings.
-Peff
PS I first tried just setting "branch.master.pushremote" without setting
"branch.master.push". This results in a segfault, as branch_get()
assumes that push_name is always set and tries to xstrdup() it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
> > Signed-off-by: Felipe Contreras
>
> Please write a commit message, preferably showing the new git-branch output.
Yeah... this has been sitting in git-fc for quite a while, I wasn't expecting
to send this patch series again given that nobody commented on v1.
> I noticed that this only picks up a publish-branch if
> branch.*.pushremote is configured. What happened to the case when
> remote.pushdefault is configured?
What happens when branch.*.remote is not configured for @{upstream}? The same
thing.
It might be useful to visualize what would be the name of the branch when
pushing it (without a refspec) even if the publish branch hasn't been
configured, but I think the code would be much more coplicated, and it would
break symetry with @{upstream}, besides, the user can just do 'git push -p
branch', and from that moment on it will be visible.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/9] branch: display publish branch
Felipe Contreras wrote: > Signed-off-by: Felipe Contreras Please write a commit message, preferably showing the new git-branch output. I noticed that this only picks up a publish-branch if branch.*.pushremote is configured. What happened to the case when remote.pushdefault is configured? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
