Re: [BUG] Possible bug in `remote set-url --add --push`

2013-01-16 Thread Michael J Gruber 
Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:
 Michael J Gruber g...@drmicha.warpmail.net writes:
 
 Also there is a conceptual confusion: pushurl is meant to push to the
 same repo using a different url, e.g. something authenticated
 (https/ssh) for push and something faster/easier for fetch.
 
 That is not necessarily true, depending on the definition of your
 same.  Having multiple URLs/PushURLs that refer to physically
 different locations, as long as git push there immediately
 followed by git fetch here should work with the repositories that
 are conceptually equivalent, is a supported mode of operation. In

That is my definition of same, in the sense of object-and-ref-same
when in-sync (at least regarding all pushed refs; there may be more
there).

 fact, they being physically different _was_ the original motivation
 of the feature. See 755225d (git builtin push, 2006-04-29).

I thought it was about unauthenticated git-protocol vs. git+ssh but was
wrong.

 The definition of the immediate above also depends on your use; it
 could be tens of minutes (you may be fetching from git.k.org that
 can be reached from the general public, which may be a cname for
 multiple machines mirroring a single master.k.org that k.org account
 holders push to, and there may be propagation delays).  In such a
 scenario, your URL may point at the public git.k.org, pushURL may
 point at master.k.org, and you may have other pushURLs that point at
 other places you use as back-up locations (e.g. git.or.cz or
 github.com).

Yes. That is also why we fetch from one fetch URL only, because we
assume they point at the same repo and don't need to check.

 As long as you _mean_ to maintain their contents the same, you can
 call them conceptually the same repo and your statement becomes
 true.
 
 It never was meant to push to several repos.
 
 This is false.  It _was_ designed to be used that way from day one.

It is very true with me definition of same ;)

 (I am not saying using it in other ways is an abuse---I am merely
 saying that pushing to multiple physically different repositories is
 within its scope).
 
 That being said, I don't mind changing the behaviour of set-url.
 
 I do not think we want to change the behaviour of set-url.  What
 needs to be fixed is the output from remote -v.  It should:
 
  * When there is no pushURL but there is a URL, then show it as
(fetch/push), and you are done;
 
  * When there is one or more pushURLs and a URL, then show the URL
as (fetch), and show pushURLs as (push), and you are done;
 
  * When there are more than one URLs, and there is no pushURL, then
show the first URL as (fetch/push), and the remainder in a
notation that says it is used only for push, but it shouldn't be
the same (push); the user has to be able to distinguish it from
the pushURLs in a repository that also has URLs.

Maybe (fetch fallback/push) if we do use it as a fallback? If we don't
we probably should?

  * When there are more than one URLs, and there are one or more
pushURLs, then show the first URL as (fetch), the other URLs
as (unused), and the pushURLs as (push).
 
 Strictly speaking, the last one could be a misconfiguration.  If you
 have:
 
   [remote origin]
   url = one
 url = two
 pushurl = three
 pushurl = four
 
 then your git fetch will go to one, and git push will go to
 three and four, and two is never used.

Do we fall back to two if one is unavailable? In any case, people may
use a configuration like that to keep track of mirrors and shuffle
around the fetch lines (rather than commenting/uncommenting) when one
goes offline.

 It should also be stressed that the third one a supported
 configuration.  With
 
   [remote origin]
   url = one
 url = two
 
 your git fetch goes to one, and your git push will go to one and
 two.  This is the originally intended use case of 755225d.  It is to
 push to and fetch from master.k.org (think of one above) and in
 addition to push to backup.github.com (two).

Michael
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-16 Thread Junio C Hamano 
Michael J Gruber g...@drmicha.warpmail.net writes:

 Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:
 ...
  * When there are more than one URLs, and there is no pushURL, then
show the first URL as (fetch/push), and the remainder in a
notation that says it is used only for push, but it shouldn't be
the same (push); the user has to be able to distinguish it from
the pushURLs in a repository that also has URLs.

 Maybe (fetch fallback/push) if we do use it as a fallback? If we don't
 we probably should?

I actually think my earlier it shouldn't be the same (push) is not
needed and probably is actively wrong.  Just like you can tell
between

(only one .url) (both .url and .pushurl)

origin there (fetch/push)   origin there (fetch)
origin there (push)

even when the value of the URL/PushURL, i.e. there, is the same
between .url and .pushurl, you should be able to tell between

(two .url, no .pushurl) (one .url and one .pushurl)

origin there (fetch/push)   origin there (fetch)
origin another (push)   origin another (push)

So let's not make it too complex and forget about the different kind
of (push).

A case that is a potential misconfiguration would look like:

(two .url, one .pushurl)

origin there (fetch)
origin some  (unused)
origin another (push)

I think.
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-16 Thread Phil Hord 
On Tue, Jan 15, 2013 at 10:53 AM, Junio C Hamano gits...@pobox.com wrote:
 Michael J Gruber g...@drmicha.warpmail.net writes:

 That being said, I don't mind changing the behaviour of set-url.

 I do not think we want to change the behaviour of set-url.

I agree with Michael that changing the set-url behavior would be
appropriate here.  If I say --add this pushUrl, don't I mean to
create an additional url which is pushed to?

I agree that it makes the config situation messy; this is currently a
clean sequence, in that it leaves the config unchanged after both
steps are completed:

  git remote set-url --add --push origin /tmp/foo
  git remote set-url --delete --push origin /tmp/foo

If the behavior is changed like Michael suggested, it would not leave
the config clean (unless heroic steps were taken to keep track).  But
I'm not sure that's such a bad thing.  In simple command sequences,
the results would be clean and the only behavior change is that the
initial --add really acts like add and not replace.  But more
complex sequences could be devised which were affected by this change.

I'm curious, Junio.  Do you think the set-url behavior is correct
as-is, or that changing it will cause breakage for some workflows, or
that it complicates the operation too much for people who are already
used to the config layout?

Phil
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-16 Thread Michael J Gruber 
Junio C Hamano venit, vidit, dixit 16.01.2013 16:50:
 Michael J Gruber g...@drmicha.warpmail.net writes:
 
 Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:
 ...
  * When there are more than one URLs, and there is no pushURL, then
show the first URL as (fetch/push), and the remainder in a
notation that says it is used only for push, but it shouldn't be
the same (push); the user has to be able to distinguish it from
the pushURLs in a repository that also has URLs.

 Maybe (fetch fallback/push) if we do use it as a fallback? If we don't
 we probably should?
 
 I actually think my earlier it shouldn't be the same (push) is not
 needed and probably is actively wrong.  Just like you can tell
 between
 
 (only one .url) (both .url and .pushurl)
 
 origin there (fetch/push)   origin there (fetch)
 origin there (push)
 
 even when the value of the URL/PushURL, i.e. there, is the same
 between .url and .pushurl, you should be able to tell between
 
 (two .url, no .pushurl) (one .url and one .pushurl)
 
 origin there (fetch/push)   origin there (fetch)
 origin another (push)   origin another (push)
 
 So let's not make it too complex and forget about the different kind
 of (push).
 
 A case that is a potential misconfiguration would look like:
 
 (two .url, one .pushurl)
 
 origin there (fetch)
 origin some  (unused)
 origin another (push)
 
 I think.

I'm sorry but E_NOPARSE. I can't grok the above at all. But I'll try
again tomorrow ;)

In any case, the issue with (push)instead of that John mentions bothers
me: there are two specified URLs but one URL in config only; my patch
doesn't make that case clearer at all. My early attempts at amending
struct remote produced too many segfaults to continue today...

Michael
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-16 Thread Michael J Gruber 
Phil Hord venit, vidit, dixit 16.01.2013 17:15:
 On Tue, Jan 15, 2013 at 10:53 AM, Junio C Hamano gits...@pobox.com wrote:
 Michael J Gruber g...@drmicha.warpmail.net writes:

 That being said, I don't mind changing the behaviour of set-url.

 I do not think we want to change the behaviour of set-url.
 
 I agree with Michael that changing the set-url behavior would be
 appropriate here.  If I say --add this pushUrl, don't I mean to
 create an additional url which is pushed to?

I said I wouldn't mind, I didn't vote for it.

 I agree that it makes the config situation messy; this is currently a
 clean sequence, in that it leaves the config unchanged after both
 steps are completed:
 
   git remote set-url --add --push origin /tmp/foo
   git remote set-url --delete --push origin /tmp/foo
 
 If the behavior is changed like Michael suggested, it would not leave
 the config clean (unless heroic steps were taken to keep track).  But
 I'm not sure that's such a bad thing.  In simple command sequences,
 the results would be clean and the only behavior change is that the
 initial --add really acts like add and not replace.  But more
 complex sequences could be devised which were affected by this change.
 
 I'm curious, Junio.  Do you think the set-url behavior is correct
 as-is, or that changing it will cause breakage for some workflows, or
 that it complicates the operation too much for people who are already
 used to the config layout?

For set url --add --push on top of a push url only being defaulted
from a fetch url, both behaviours (replace or add, i.e. current or new)
make sense to me. So the questions are:

- Is it worth and possible changing?
- How to best describe it in remote -v and remote show output?

My patch answered to no to the first question and answers the second
one in cases where (push)insteadof is not used to transform one fetch
config into two different urls for fetch and push. I think :)

Michael
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-16 Thread Andreas Schwab 
Junio C Hamano gits...@pobox.com writes:

 I actually think my earlier it shouldn't be the same (push) is not
 needed and probably is actively wrong.  Just like you can tell
 between

 (only one .url) (both .url and .pushurl)

 origin there (fetch/push)   origin there (fetch)
 origin there (push)

What should happen when you have a .pushinsteadof configured that
modifies .url for pushing?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-16 Thread Junio C Hamano 
Andreas Schwab sch...@linux-m68k.org writes:

 Junio C Hamano gits...@pobox.com writes:

 I actually think my earlier it shouldn't be the same (push) is not
 needed and probably is actively wrong.  Just like you can tell
 between

 (only one .url) (both .url and .pushurl)

 origin there (fetch/push)   origin there (fetch)
 origin there (push)

 What should happen when you have a .pushinsteadof configured that
 modifies .url for pushing?

I think push should work like this:

 * the user gives us a nickname;

 * we look at remote.$nickname.pushurl (and if there isn't,
   remote.$nickname.url) to decide the logical URLs to push to;

 * for each logical URL we decided to push, we look at
   url.*.pushInsteadOf to see if there is one that match the $URL
   (and if there isn't url.*.insteadOf), and map the logical URL to
   the final destination.

So that we can instruct push to push, when pushing into a
repository that logically resides at git://git.k.org/pub/,
to instead push into the repository via git-over-ssh, e.g.

[remote korg]
url = git://git.k.org/pub/scm/git/git.git/

[url git.k.org:/pub/]
pushInsteadOf = git://git.k.org/pub/

without affecting the fetching side.

As I said in a separate message, the above fetch/push vs fetch
and push distinction is not descriptive enough to express the post
rewriting that is done with insteadOf; it only helps debugging
misconfiguration between .url vs .pushurl, which may be better than
the status quo but is not ideal.
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-15 Thread Michael J Gruber 
Junio C Hamano venit, vidit, dixit 15.01.2013 07:39:
 Junio C Hamano gits...@pobox.com writes:
 
 Jardel Weyrich jweyr...@gmail.com writes:

 If you allow me, I'd like you to forget about the concepts for a minute, 
 and focus on the user experience.
 Imagine a simple hypothetical scenario in which the user wants to push to 2 
 distinct repositories. He already has cloned the repo from the 1st 
 repository, thus (theoretically) all he needs to do, is to add a new 
 repository for push. He then uses `remote set-url --add --push 2nd-repo` 
 (which I personally thought would suffice). However, if he tries to push a 
 new commit to this remote, it would be pushed _only_ to the 2nd-repo.

 The primary reason behind push-url was that

  (1) usually you push to and fetch from the same, so no pushUrl is
  ever needed, just a single Url will do (this is often true for
  cvs/svn style shared repository workflow); and

  (2) sometimes you want to fetch from one place and push to another
  (this is often true for fetch from upstream, push to my own
  and ask upstream to pull from it workflow), and in that case
  you want pushUrl in addition to Url.  Most importantly, in this
  case, you do *NOT* want to push to Url.  You only push to
  pushUrl.

 Setting *one* pushURL is a way to say That URL I fetch from is
 *not* the place I want to push (I may not even be able to push
 there); when I say 'push', push there instead.  Your proposed
 semantics will make it impossible to arrange such an asymmetric
 setting.
 
 Now I think I finally see where that misunderstanding comes from.
 It is remote -v that is misdesigned.
 
 $ git clone ../there here
 $ cd here
 $ git remote -v
 origin /var/tmp/there (fetch)
 origin /var/tmp/there (push)
 
 This is totally bogus.  It should report something like this:
 
 $ git remote -v
 origin /var/tmp/there (fetch/push)
 
 Then after running git remote set-url --push origin ../another we
 should see
 
 $ git remote -v
 origin /var/tmp/there (fetch)
 origin /var/tmp/another (push)
 
 which would make it clear that the original fetch/push came from the
 (1) usuall you push and fetch from the same place so there is only
 one setting, and the two lines came from the (2) sometimes you need
 a separate places to fetch from and push to.

Yes, that is one big source of misunderstanding. Cleaning up remote -v
would help, along with the man page.

Also there is a conceptual confusion: pushurl is meant to push to the
same repo using a different url, e.g. something authenticated
(https/ssh) for push and something faster/easier for fetch.

It never was meant to push to several repos. That is what remotes are
for, and it would help if we could push to a remote group (which is
difficult because of refspecs etc.) easily.

That being said, I don't mind changing the behaviour of set-url.

 At this point, if you say set-url --push origin ../third, then
 another will disappear and gets replaced by third; if you
 instead say set-url --add --push origin ../third, then we will see
 two (push) lines, in addition to one (fetch), making it clear that
 you are still in (2) above, fetching from and pushing to different
 places, and having two places to push to.
 
 I misread your response
 
 From: Jardel Weyrich jweyr...@gmail.com
 Subject: Re: [BUG] Possible bug in `remote set-url --add --push`
 Date: Sat, 12 Jan 2013 06:09:35 -0200
 Message-ID: 
 can8taovp_hx6bek86ayox-kvqwdmsbyptxtt2nk+fx+ut1t...@mail.gmail.com
 
 where you showed that there was only remote.origin.url (and no
 pushurl) in the first step, and somehow thought you had a
 remote.origin.pushurl in the first place.
 
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-14 Thread Michael J Gruber 
Jardel Weyrich venit, vidit, dixit 12.01.2013 10:33:
 On Sat, Jan 12, 2013 at 6:44 AM, Sascha Cunz sascha...@babbelbox.org wrote:
 Am Freitag, 11. Januar 2013, 23:10:36 schrieb Junio C Hamano:
 Jardel Weyrich jweyr...@gmail.com writes:
 I believe `remote set-url --add --push` has a bug. Performed tests
 with v1.8.0.1 and v1.8.1 (Mac OS X).

 Quoting the relevant part of the documentation:
 set-url

 Changes URL remote points to. Sets first URL remote points to
 matching regex oldurl (first URL if no oldurl is given) to
 newurl. If oldurl doesn’t match any URL, error occurs and
 nothing is changed.

 With --push, push URLs are manipulated instead of fetch URLs.
 With --add, instead of changing some URL, new URL is added.
 With --delete, instead of changing some URL, all URLs matching regex
 url are deleted. Trying to delete all non-push URLs is an error.
 Here are some steps to reproduce:

 1. Show the remote URLs

 jweyrich@pharao:test_clone1 [* master]$ git remote -v
 origin  /Volumes/sandbox/test (fetch)
 origin  /Volumes/sandbox/test (push)

 2. Add a new push URL for origin

 jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push
 origin \
 /Volumes/sandbox/test_clone2

 3. Check what happened

 jweyrich@pharao:test_clone1 [* master]$ git remote -v
 origin  /Volumes/sandbox/test (fetch)
 origin  /Volumes/sandbox/test_clone2 (push)

 The original pushurl was replaced with the additional one, instead
 of being left and the new one getting added.  That looks certainly
 wrong.

 However, the result of applying the attached patch (either to
 v1.7.12 or v1.8.1) still passes the test and I do not think it is
 doing anything differently from what you described above.

 What do you get from

   git config -l | grep '^remote\.origin'

 in steps 1. and 3. in your procedure?  This question is trying to
 tell if your bug is in git remote -v or in git remote set-url.

 I'm not sure, if there is a bug at all. According to man git-push:

 The pushurl is used for pushes only. It is optional and defaults to
url.
 (From the section REMOTES - Named remote in configuration file)

 the command:
 git remote add foo g...@foo-fetch.org/some.git

 will set remote.foo.url to g...@foo-fetch.org. Subsequently, fetch and 
 push
 will use g...@foo-fetch.org as url.
 Fetch will use this url, because remote.foo.url explicitly sets this. push
 will use it in absence of a remote.foo.pushurl.

 Now, we're adding a push-url:
 git remote set-url --add --push foo g...@foo-push.org/some.git

 Relevant parts of config are now looking like:
 [remote foo]
 url = g...@foo-fetch.org/some.git
 pushurl = g...@foo-push.org/some.git

 Since, pushurl is now given explicitly, git push will use that one (and only
 that one).

 If we add another push-url now,
 git remote set-url --add --push foo g...@foo-push-also.org/some.git

 the next git-push will push to foo-push.org and foo-push-also.org.

 Now, using --set-url --delete on both of these urls restores the original
 state: only remote.foo.url is set; meaning implicitly pushurl defaults to
 url again.

 To me this is exactly what Jardel was observing:

 In step 2, Git replaced the original push URL instead of adding a new
 one. But it seems to happen only the first time I use `remote set-url
 --add --push`. Re-adding the original URL using the same command seems
 to work properly.

 And FWIW, if I delete (with set-url --delete) both URLs push, Git
 restores the original URL.

 Or am I missing something here?
 
 You're right. However, as I quoted earlier, the git-remote man-page states:
 
set-url
Changes URL remote points to. suppressed
With --push, push URLs are manipulated instead of fetch URLs.
With --add, instead of changing some URL, new URL is added.
 
 It explicitly mentions that it should **add a new URL**.
 So when I do `git remote set-url --add --push origin
 git://another/repo.git`, I expect git-push to use both the default
 push URL and the new one. Or am I misinterpreting the man-page?
 

 Might be that the bug actually is that the expectation was

 git remote add foo g...@foo-fetch.org/some.git

 should have created a config like:

 [remote foo]
 url = g...@foo-fetch.org/some.git
 pushurl = g...@foo-fetch.org/some.git

 since that is what git remote -v reports.

 If that is the case, we might want to amend the output of 'git remote -v' 
 with
 the information that a pushurl is not explicitly given and thus defaults to
 url.
 
 Correct. Adding a remote doesn't automatically generate a pushurl for it.
 
 To me, it seems that git-push checks for the existence of pushurl's in
 the config, and if it finds any, it ignores the defaul push URL during
 the actual push. In better words, it pushes only to pushurls, if it
 finds any, otherwise it pushes to the default URL.
 
 To comply with the statements in the

Re: [BUG] Possible bug in `remote set-url --add --push`

2013-01-14 Thread Junio C Hamano 
Michael J Gruber g...@drmicha.warpmail.net writes:

 It seems to me that everything works as designed, and that the man page
 talk about push URLs can be read in two ways,...

Hmph, but I had an impression that Jardel's original report was that
one of the --add --pushurl was not adding but was replacing.  If
that was a false alarm, everything you said makes sense to me.

Thanks.
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-14 Thread Jardel Weyrich 
On 14/01/2013, at 17:09, Junio C Hamano gits...@pobox.com wrote:

 Michael J Gruber g...@drmicha.warpmail.net writes:
 
 It seems to me that everything works as designed, and that the man page
 talk about push URLs can be read in two ways,...
 
 Hmph, but I had an impression that Jardel's original report was that
 one of the --add --pushurl was not adding but was replacing.  If
 that was a false alarm, everything you said makes sense to me.
 
 Thanks.

I failed to explain my reasoning. But I learned quite a bit from this 
discussion. I understood that the defaul push url is not used by git-push when 
there's at least one pushurl for a given remote.

If that's by design, I still fail to comprehend the exact reason.
If you allow me, I'd like you to forget about the concepts for a minute, and 
focus on the user experience.
Imagine a simple hypothetical scenario in which the user wants to push to 2 
distinct repositories. He already has cloned the repo from the 1st repository, 
thus (theoretically) all he needs to do, is to add a new repository for push. 
He then uses `remote set-url --add --push 2nd-repo` (which I personally 
thought would suffice). However, if he tries to push a new commit to this 
remote, it would be pushed _only_ to the 2nd-repo.

This is exactly what I thought to be a bug. If it's intended to work the way I 
described in the previous scenario, I'll have to ask and/or research to 
understand the reason behind this -- Why does having a pushurl make git-push 
_not_ to push to the default push location (the 1st repo in my scenario) as 
well? Could you describe a scenario in which that behavior is useful and/or 
better than the behavior I expected?

Please, pardon me for not being as clear as needed. I appreciate your time on 
this. Thank you all.

Sent from my mobile.--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-14 Thread Junio C Hamano 
Jardel Weyrich jweyr...@gmail.com writes:

 If you allow me, I'd like you to forget about the concepts for a minute, and 
 focus on the user experience.
 Imagine a simple hypothetical scenario in which the user wants to push to 2 
 distinct repositories. He already has cloned the repo from the 1st 
 repository, thus (theoretically) all he needs to do, is to add a new 
 repository for push. He then uses `remote set-url --add --push 2nd-repo` 
 (which I personally thought would suffice). However, if he tries to push a 
 new commit to this remote, it would be pushed _only_ to the 2nd-repo.

The primary reason behind push-url was that

 (1) usually you push to and fetch from the same, so no pushUrl is
 ever needed, just a single Url will do (this is often true for
 cvs/svn style shared repository workflow); and

 (2) sometimes you want to fetch from one place and push to another
 (this is often true for fetch from upstream, push to my own
 and ask upstream to pull from it workflow), and in that case
 you want pushUrl in addition to Url.  Most importantly, in this
 case, you do *NOT* want to push to Url.  You only push to
 pushUrl.

Setting *one* pushURL is a way to say That URL I fetch from is
*not* the place I want to push (I may not even be able to push
there); when I say 'push', push there instead.  Your proposed
semantics will make it impossible to arrange such an asymmetric
setting.
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-14 Thread Junio C Hamano 
Junio C Hamano gits...@pobox.com writes:

 Jardel Weyrich jweyr...@gmail.com writes:

 If you allow me, I'd like you to forget about the concepts for a minute, and 
 focus on the user experience.
 Imagine a simple hypothetical scenario in which the user wants to push to 2 
 distinct repositories. He already has cloned the repo from the 1st 
 repository, thus (theoretically) all he needs to do, is to add a new 
 repository for push. He then uses `remote set-url --add --push 2nd-repo` 
 (which I personally thought would suffice). However, if he tries to push a 
 new commit to this remote, it would be pushed _only_ to the 2nd-repo.

 The primary reason behind push-url was that

  (1) usually you push to and fetch from the same, so no pushUrl is
  ever needed, just a single Url will do (this is often true for
  cvs/svn style shared repository workflow); and

  (2) sometimes you want to fetch from one place and push to another
  (this is often true for fetch from upstream, push to my own
  and ask upstream to pull from it workflow), and in that case
  you want pushUrl in addition to Url.  Most importantly, in this
  case, you do *NOT* want to push to Url.  You only push to
  pushUrl.

 Setting *one* pushURL is a way to say That URL I fetch from is
 *not* the place I want to push (I may not even be able to push
 there); when I say 'push', push there instead.  Your proposed
 semantics will make it impossible to arrange such an asymmetric
 setting.

Now I think I finally see where that misunderstanding comes from.
It is remote -v that is misdesigned.

$ git clone ../there here
$ cd here
$ git remote -v
origin /var/tmp/there (fetch)
origin /var/tmp/there (push)

This is totally bogus.  It should report something like this:

$ git remote -v
origin /var/tmp/there (fetch/push)

Then after running git remote set-url --push origin ../another we
should see

$ git remote -v
origin /var/tmp/there (fetch)
origin /var/tmp/another (push)

which would make it clear that the original fetch/push came from the
(1) usuall you push and fetch from the same place so there is only
one setting, and the two lines came from the (2) sometimes you need
a separate places to fetch from and push to.

At this point, if you say set-url --push origin ../third, then
another will disappear and gets replaced by third; if you
instead say set-url --add --push origin ../third, then we will see
two (push) lines, in addition to one (fetch), making it clear that
you are still in (2) above, fetching from and pushing to different
places, and having two places to push to.

I misread your response

From: Jardel Weyrich jweyr...@gmail.com
Subject: Re: [BUG] Possible bug in `remote set-url --add --push`
Date: Sat, 12 Jan 2013 06:09:35 -0200
Message-ID: 
can8taovp_hx6bek86ayox-kvqwdmsbyptxtt2nk+fx+ut1t...@mail.gmail.com

where you showed that there was only remote.origin.url (and no
pushurl) in the first step, and somehow thought you had a
remote.origin.pushurl in the first place.

--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-12 Thread Jardel Weyrich 
Step 1:

jweyrich@pharao:test_clone1 [* master]$ git remote -v
origin /Volumes/sandbox/test (fetch)
origin /Volumes/sandbox/test (push)

jweyrich@pharao:test_clone1 [* master]$ git config -l | grep '^remote\.origin'
remote.origin.url=/Volumes/sandbox/test
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

Step 3:

jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add
--push origin /Volumes/sandbox/test_clone2
origin /Volumes/sandbox/test (fetch)
origin /Volumes/sandbox/test_clone2/ (push)

jweyrich@pharao:test_clone1 [* master]$ git config -l | grep '^remote\.origin'
remote.origin.url=/Volumes/sandbox/test
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.pushurl=/Volumes/sandbox/test_clone2/


After that, if I do a commit in test_clone1 and try to push to origin,
it pushes only to the test_clone2 rather than pushing to both test and
test_clone2 (it's a bare repo, sorry for using a misleading name).

Is `remote.remote_name.pushurl` required for the primary URL as
well? If not, then git-push is not handling that information as it
should.

On Sat, Jan 12, 2013 at 5:10 AM, Junio C Hamano gits...@pobox.com wrote:
 Jardel Weyrich jweyr...@gmail.com writes:

 I believe `remote set-url --add --push` has a bug. Performed tests
 with v1.8.0.1 and v1.8.1 (Mac OS X).

 Quoting the relevant part of the documentation:

 set-url
 Changes URL remote points to. Sets first URL remote points to matching 
 regex oldurl (first URL if no oldurl is given) to newurl. If oldurl 
 doesn’t match any URL, error occurs and nothing is changed.

 With --push, push URLs are manipulated instead of fetch URLs.
 With --add, instead of changing some URL, new URL is added.
 With --delete, instead of changing some URL, all URLs matching regex 
 url are deleted. Trying to delete all non-push URLs is an error.

 Here are some steps to reproduce:

 1. Show the remote URLs

 jweyrich@pharao:test_clone1 [* master]$ git remote -v
 origin  /Volumes/sandbox/test (fetch)
 origin  /Volumes/sandbox/test (push)

 2. Add a new push URL for origin

 jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push 
 origin \
 /Volumes/sandbox/test_clone2

 3. Check what happened

 jweyrich@pharao:test_clone1 [* master]$ git remote -v
 origin  /Volumes/sandbox/test (fetch)
 origin  /Volumes/sandbox/test_clone2 (push)

 The original pushurl was replaced with the additional one, instead
 of being left and the new one getting added.  That looks certainly
 wrong.

 However, the result of applying the attached patch (either to
 v1.7.12 or v1.8.1) still passes the test and I do not think it is
 doing anything differently from what you described above.

 What do you get from

 git config -l | grep '^remote\.origin'

 in steps 1. and 3. in your procedure?  This question is trying to
 tell if your bug is in git remote -v or in git remote set-url.

 -- 8 --
 From 0f6cbc67db926e97707ae732b02e790b4604508e Mon Sep 17 00:00:00 2001
 From: Junio C Hamano gits...@pobox.com
 Date: Fri, 11 Jan 2013 23:04:16 -0800
 Subject: [PATCH] t5505: adding one pushurl from jweyrich

 Signed-off-by: Junio C Hamano gits...@pobox.com
 ---
  t/t5505-remote.sh | 19 +++
  1 file changed, 19 insertions(+)

 diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
 index c03ffdd..b31c5bb 100755
 --- a/t/t5505-remote.sh
 +++ b/t/t5505-remote.sh
 @@ -901,6 +901,25 @@ test_expect_success 'remote set-url --push --add aaa' '
 cmp expect actual
  '

 +test_expect_success 'remote set-url --push --add' '
 +   git config remote.jweyrich.url /Volumes/sandbox/test 
 +   git config remote.jweyrich.pushurl /Volumes/sandbox/test 
 +   git config remote.jweyrich.fetch 
 refs/heads/*:refs/remotes/jweyrich/* 
 +
 +   added=/Volumes/sandbox/test_clone2 
 +   {
 +   git config -l | grep ^remote\.jweyrich\. 
 +   echo remote.jweyrich.pushurl=$added
 +   } | sort expect 
 +
 +   git remote set-url --add --push jweyrich $added 
 +   git config -l | grep ^remote\.jweyrich\. | sort actual 
 +
 +   test_cmp expect actual 
 +
 +   git remote -v | grep ^jweyrich # this is just for debugging
 +'
 +
  test_expect_success 'remote set-url --push bar aaa' '
 git remote set-url --push someremote bar aaa 
 echo foo expect 
 --
 1.8.1.421.g6236851
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-12 Thread Junio C Hamano 
Jardel Weyrich jweyr...@gmail.com writes:

 Step 1:

 jweyrich@pharao:test_clone1 [* master]$ git remote -v
 origin /Volumes/sandbox/test (fetch)
 origin /Volumes/sandbox/test (push)

 jweyrich@pharao:test_clone1 [* master]$ git config -l | grep '^remote\.origin'
 remote.origin.url=/Volumes/sandbox/test
 remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

 Step 3:

 jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add
 --push origin /Volumes/sandbox/test_clone2
 origin /Volumes/sandbox/test (fetch)
 origin /Volumes/sandbox/test_clone2/ (push)

 jweyrich@pharao:test_clone1 [* master]$ git config -l | grep '^remote\.origin'
 remote.origin.url=/Volumes/sandbox/test
 remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
 remote.origin.pushurl=/Volumes/sandbox/test_clone2/

So remote -v is not lying (we only see one pushurl after Step 3
above) and set-url is not working correctly on your box in a way
that I cannot reproduce X-.

 ...
 Is `remote.remote_name.pushurl` required for the primary URL as
 well?

What do you mean by primary URL?
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-12 Thread Sascha Cunz 
Am Freitag, 11. Januar 2013, 23:10:36 schrieb Junio C Hamano:
 Jardel Weyrich jweyr...@gmail.com writes:
  I believe `remote set-url --add --push` has a bug. Performed tests
  with v1.8.0.1 and v1.8.1 (Mac OS X).
  
  Quoting the relevant part of the documentation:
  set-url
  
  Changes URL remote points to. Sets first URL remote points to
  matching regex oldurl (first URL if no oldurl is given) to
  newurl. If oldurl doesn’t match any URL, error occurs and
  nothing is changed.
  
  With --push, push URLs are manipulated instead of fetch URLs.
  With --add, instead of changing some URL, new URL is added.
  With --delete, instead of changing some URL, all URLs matching regex
  url are deleted. Trying to delete all non-push URLs is an error. 
  Here are some steps to reproduce:
  
  1. Show the remote URLs
  
  jweyrich@pharao:test_clone1 [* master]$ git remote -v
  origin  /Volumes/sandbox/test (fetch)
  origin  /Volumes/sandbox/test (push)
  
  2. Add a new push URL for origin
  
  jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push
  origin \ 
  /Volumes/sandbox/test_clone2
  
  3. Check what happened
  
  jweyrich@pharao:test_clone1 [* master]$ git remote -v
  origin  /Volumes/sandbox/test (fetch)
  origin  /Volumes/sandbox/test_clone2 (push)
 
 The original pushurl was replaced with the additional one, instead
 of being left and the new one getting added.  That looks certainly
 wrong.
 
 However, the result of applying the attached patch (either to
 v1.7.12 or v1.8.1) still passes the test and I do not think it is
 doing anything differently from what you described above.
 
 What do you get from
 
   git config -l | grep '^remote\.origin'
 
 in steps 1. and 3. in your procedure?  This question is trying to
 tell if your bug is in git remote -v or in git remote set-url.

I'm not sure, if there is a bug at all. According to man git-push:

The pushurl is used for pushes only. It is optional and defaults to
   url.
(From the section REMOTES - Named remote in configuration file)

the command:
git remote add foo g...@foo-fetch.org/some.git

will set remote.foo.url to g...@foo-fetch.org. Subsequently, fetch and push 
will use g...@foo-fetch.org as url.
Fetch will use this url, because remote.foo.url explicitly sets this. push 
will use it in absence of a remote.foo.pushurl.

Now, we're adding a push-url:
git remote set-url --add --push foo g...@foo-push.org/some.git

Relevant parts of config are now looking like:
[remote foo]
url = g...@foo-fetch.org/some.git
pushurl = g...@foo-push.org/some.git

Since, pushurl is now given explicitly, git push will use that one (and only 
that one).

If we add another push-url now,
git remote set-url --add --push foo g...@foo-push-also.org/some.git

the next git-push will push to foo-push.org and foo-push-also.org.

Now, using --set-url --delete on both of these urls restores the original 
state: only remote.foo.url is set; meaning implicitly pushurl defaults to 
url again.

To me this is exactly what Jardel was observing:

 In step 2, Git replaced the original push URL instead of adding a new
 one. But it seems to happen only the first time I use `remote set-url
 --add --push`. Re-adding the original URL using the same command seems
 to work properly.

 And FWIW, if I delete (with set-url --delete) both URLs push, Git
 restores the original URL.

Or am I missing something here?

Might be that the bug actually is that the expectation was

git remote add foo g...@foo-fetch.org/some.git

should have created a config like:

[remote foo]
url = g...@foo-fetch.org/some.git
pushurl = g...@foo-fetch.org/some.git

since that is what git remote -v reports.

If that is the case, we might want to amend the output of 'git remote -v' with 
the information that a pushurl is not explicitly given and thus defaults to 
url.

Sascha
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-12 Thread Jardel Weyrich 
On Sat, Jan 12, 2013 at 6:44 AM, Sascha Cunz sascha...@babbelbox.org wrote:
 Am Freitag, 11. Januar 2013, 23:10:36 schrieb Junio C Hamano:
 Jardel Weyrich jweyr...@gmail.com writes:
  I believe `remote set-url --add --push` has a bug. Performed tests
  with v1.8.0.1 and v1.8.1 (Mac OS X).
 
  Quoting the relevant part of the documentation:
  set-url
 
  Changes URL remote points to. Sets first URL remote points to
  matching regex oldurl (first URL if no oldurl is given) to
  newurl. If oldurl doesn’t match any URL, error occurs and
  nothing is changed.
 
  With --push, push URLs are manipulated instead of fetch URLs.
  With --add, instead of changing some URL, new URL is added.
  With --delete, instead of changing some URL, all URLs matching regex
  url are deleted. Trying to delete all non-push URLs is an error.
  Here are some steps to reproduce:
 
  1. Show the remote URLs
 
  jweyrich@pharao:test_clone1 [* master]$ git remote -v
  origin  /Volumes/sandbox/test (fetch)
  origin  /Volumes/sandbox/test (push)
 
  2. Add a new push URL for origin
 
  jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push
  origin \
  /Volumes/sandbox/test_clone2
 
  3. Check what happened
 
  jweyrich@pharao:test_clone1 [* master]$ git remote -v
  origin  /Volumes/sandbox/test (fetch)
  origin  /Volumes/sandbox/test_clone2 (push)

 The original pushurl was replaced with the additional one, instead
 of being left and the new one getting added.  That looks certainly
 wrong.

 However, the result of applying the attached patch (either to
 v1.7.12 or v1.8.1) still passes the test and I do not think it is
 doing anything differently from what you described above.

 What do you get from

   git config -l | grep '^remote\.origin'

 in steps 1. and 3. in your procedure?  This question is trying to
 tell if your bug is in git remote -v or in git remote set-url.

 I'm not sure, if there is a bug at all. According to man git-push:

 The pushurl is used for pushes only. It is optional and defaults to
url.
 (From the section REMOTES - Named remote in configuration file)

 the command:
 git remote add foo g...@foo-fetch.org/some.git

 will set remote.foo.url to g...@foo-fetch.org. Subsequently, fetch and 
 push
 will use g...@foo-fetch.org as url.
 Fetch will use this url, because remote.foo.url explicitly sets this. push
 will use it in absence of a remote.foo.pushurl.

 Now, we're adding a push-url:
 git remote set-url --add --push foo g...@foo-push.org/some.git

 Relevant parts of config are now looking like:
 [remote foo]
 url = g...@foo-fetch.org/some.git
 pushurl = g...@foo-push.org/some.git

 Since, pushurl is now given explicitly, git push will use that one (and only
 that one).

 If we add another push-url now,
 git remote set-url --add --push foo g...@foo-push-also.org/some.git

 the next git-push will push to foo-push.org and foo-push-also.org.

 Now, using --set-url --delete on both of these urls restores the original
 state: only remote.foo.url is set; meaning implicitly pushurl defaults to
 url again.

 To me this is exactly what Jardel was observing:

 In step 2, Git replaced the original push URL instead of adding a new
 one. But it seems to happen only the first time I use `remote set-url
 --add --push`. Re-adding the original URL using the same command seems
 to work properly.

 And FWIW, if I delete (with set-url --delete) both URLs push, Git
 restores the original URL.

 Or am I missing something here?

You're right. However, as I quoted earlier, the git-remote man-page states:

   set-url
   Changes URL remote points to. suppressed
   With --push, push URLs are manipulated instead of fetch URLs.
   With --add, instead of changing some URL, new URL is added.

It explicitly mentions that it should **add a new URL**.
So when I do `git remote set-url --add --push origin
git://another/repo.git`, I expect git-push to use both the default
push URL and the new one. Or am I misinterpreting the man-page?


 Might be that the bug actually is that the expectation was

 git remote add foo g...@foo-fetch.org/some.git

 should have created a config like:

 [remote foo]
 url = g...@foo-fetch.org/some.git
 pushurl = g...@foo-fetch.org/some.git

 since that is what git remote -v reports.

 If that is the case, we might want to amend the output of 'git remote -v' with
 the information that a pushurl is not explicitly given and thus defaults to
 url.

Correct. Adding a remote doesn't automatically generate a pushurl for it.

To me, it seems that git-push checks for the existence of pushurl's in
the config, and if it finds any, it ignores the defaul push URL during
the actual push. In better words, it pushes only to pushurls, if it
finds any, otherwise it pushes to the default URL.

To comply with the statements in the git-remote man-page, git-remote
should add a

[BUG] Possible bug in `remote set-url --add --push`

2013-01-11 Thread Jardel Weyrich 
Hi,

I believe `remote set-url --add --push` has a bug. Performed tests
with v1.8.0.1 and v1.8.1 (Mac OS X).

Quoting the relevant part of the documentation:

 set-url
 Changes URL remote points to. Sets first URL remote points to matching 
 regex oldurl (first URL if no oldurl is given) to newurl. If oldurl 
 doesn’t match any URL, error occurs and nothing is changed.

 With --push, push URLs are manipulated instead of fetch URLs.
 With --add, instead of changing some URL, new URL is added.
 With --delete, instead of changing some URL, all URLs matching regex 
 url are deleted. Trying to delete all non-push URLs is an error.

Here are some steps to reproduce:

1. Show the remote URLs

jweyrich@pharao:test_clone1 [* master]$ git remote -v
origin  /Volumes/sandbox/test (fetch)
origin  /Volumes/sandbox/test (push)

2. Add a new push URL for origin

jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push origin \
/Volumes/sandbox/test_clone2

3. Check what happened

jweyrich@pharao:test_clone1 [* master]$ git remote -v
origin  /Volumes/sandbox/test (fetch)
origin  /Volumes/sandbox/test_clone2 (push)

4. Missing an URL? Re-add the original one

jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push origin \
/Volumes/sandbox/test

5. Check what happened, again

jweyrich@pharao:test_clone1 [* master]$ git remote -v
origin  /Volumes/sandbox/test (fetch)
origin  /Volumes/sandbox/test_clone2 (push)
origin  /Volumes/sandbox/test (push)

In step 2, Git replaced the original push URL instead of adding a new
one. But it seems to happen only the first time I use `remote set-url
--add --push`. Re-adding the original URL using the same command seems
to work properly.
And FWIW, if I delete (with set-url --delete) both URLs push, Git
restores the original URL.

Please, could someone try to reproduce?

- jw
--
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: [BUG] Possible bug in `remote set-url --add --push`

2013-01-11 Thread Junio C Hamano 
Jardel Weyrich jweyr...@gmail.com writes:

 I believe `remote set-url --add --push` has a bug. Performed tests
 with v1.8.0.1 and v1.8.1 (Mac OS X).

 Quoting the relevant part of the documentation:

 set-url
 Changes URL remote points to. Sets first URL remote points to matching 
 regex oldurl (first URL if no oldurl is given) to newurl. If oldurl 
 doesn’t match any URL, error occurs and nothing is changed.

 With --push, push URLs are manipulated instead of fetch URLs.
 With --add, instead of changing some URL, new URL is added.
 With --delete, instead of changing some URL, all URLs matching regex 
 url are deleted. Trying to delete all non-push URLs is an error.

 Here are some steps to reproduce:

 1. Show the remote URLs

 jweyrich@pharao:test_clone1 [* master]$ git remote -v
 origin  /Volumes/sandbox/test (fetch)
 origin  /Volumes/sandbox/test (push)

 2. Add a new push URL for origin

 jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push 
 origin \
 /Volumes/sandbox/test_clone2

 3. Check what happened

 jweyrich@pharao:test_clone1 [* master]$ git remote -v
 origin  /Volumes/sandbox/test (fetch)
 origin  /Volumes/sandbox/test_clone2 (push)

The original pushurl was replaced with the additional one, instead
of being left and the new one getting added.  That looks certainly
wrong.

However, the result of applying the attached patch (either to
v1.7.12 or v1.8.1) still passes the test and I do not think it is
doing anything differently from what you described above.

What do you get from

git config -l | grep '^remote\.origin'

in steps 1. and 3. in your procedure?  This question is trying to
tell if your bug is in git remote -v or in git remote set-url.

-- 8 --
From 0f6cbc67db926e97707ae732b02e790b4604508e Mon Sep 17 00:00:00 2001
From: Junio C Hamano gits...@pobox.com
Date: Fri, 11 Jan 2013 23:04:16 -0800
Subject: [PATCH] t5505: adding one pushurl from jweyrich

Signed-off-by: Junio C Hamano gits...@pobox.com
---
 t/t5505-remote.sh | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index c03ffdd..b31c5bb 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -901,6 +901,25 @@ test_expect_success 'remote set-url --push --add aaa' '
cmp expect actual
 '
 
+test_expect_success 'remote set-url --push --add' '
+   git config remote.jweyrich.url /Volumes/sandbox/test 
+   git config remote.jweyrich.pushurl /Volumes/sandbox/test 
+   git config remote.jweyrich.fetch refs/heads/*:refs/remotes/jweyrich/* 

+
+   added=/Volumes/sandbox/test_clone2 
+   {
+   git config -l | grep ^remote\.jweyrich\. 
+   echo remote.jweyrich.pushurl=$added
+   } | sort expect 
+
+   git remote set-url --add --push jweyrich $added 
+   git config -l | grep ^remote\.jweyrich\. | sort actual 
+
+   test_cmp expect actual 
+
+   git remote -v | grep ^jweyrich # this is just for debugging
+'
+
 test_expect_success 'remote set-url --push bar aaa' '
git remote set-url --push someremote bar aaa 
echo foo expect 
-- 
1.8.1.421.g6236851
--
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