Re: [ANNOUNCE] Git v2.0.0
On Mon, 2 Jun 2014 19:59:53 -0700 Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Jun 2, 2014 at 7:08 PM, NeilBrown ne...@suse.de wrote: git request-pull master git://neil.brown.name/md after tagging the current commit as md/3.15-fixes and pushing out the tag You should *tell* git request-pull what you're actually requesting to pull. The old let's guess based on the commit at the top of your tree may have worked for you (because you only ever had one matching thing), but it did not work in general. So the new git request-pull does not guess. If you want to request a tag to be pulled, you name it. Because if you don't name it, it now defaults to HEAD (like all other git log commands) rather than guessing. So please write it as git request-pull master git://neil.brown.name/md md/3.15-fixes I guess the man-page should be made more explicit about this too. Linus OK, thanks. I guess I can live with being a bit more explicit. NeilBrown signature.asc Description: PGP signature
Re: [ANNOUNCE] Git v2.0.0
On Sat, May 31, 2014 at 11:52:24AM +0200, David Kastrup wrote: Some mailing list filters and/or spam filters flag mails with too many recipients so that they need to pass through moderation first. The typical threads on this list are short and have few recipients while longer threads, due to the list policy of adding every participants to the Cc, will tend to have more recipients. AFAIK, vger does not do anything like this. They block HTML, messages lacking a message-id, messages over 100K, and certain taboo phrases: http://vger.kernel.org/majordomo-info.html#taboo And anyway, I do not think vger is responsible here. The messages were delivered through the list, and other archives have them. This looks like a gmane problem. According to gmane.org, their admins will look manually at messages flagged as spam, but I find it unlikely that they flagged several days worth of git traffic (and when they do, I think they cross-post them to a spam group in NNTP, and the messages do not seem to be marked as such). So I think this really is just a bug. And frankly, if I were a list moderator and software asked me through this sort of coincidence whether a mail should be delivered or not and a glance at it shows nothing but insults, wild accusations, threats and so on for the umpteenth time, I'd consider twice clicking Accept. Whether or not I ultimately did so, this would likely contribute to the delay. I do not disagree, but please let's not rehash all of that again. -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: [ANNOUNCE] Git v2.0.0
Jeff King wrote: On Sat, May 31, 2014 at 11:52:24AM +0200, David Kastrup wrote: And frankly, if I were a list moderator and software asked me through this sort of coincidence whether a mail should be delivered or not and a glance at it shows nothing but insults, wild accusations, threats and so on for the umpteenth time, I'd consider twice clicking Accept. Whether or not I ultimately did so, this would likely contribute to the delay. I do not disagree, but please let's not rehash all of that again. FTR. I haven't insulted anybody, I on the other hand have been insulted plenty of times, included by Junio. -- 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: [ANNOUNCE] Git v2.0.0
On Wed, 28 May 2014 15:31:13 -0700 Junio C Hamano gits...@pobox.com wrote:
The latest feature release Git v2.0.0 is now available at the
usual places.
git request-pull lost a few heuristics that often led to mistakes.
I've installed git 2.0.0 and now when I
git request-pull master git://neil.brown.name/md
after tagging the current commit as md/3.15-fixes and pushing out the tag,
I get
warn: No match for commit 2ac295a544dcae9299cba13ce250419117ae7fd1 found at
git://neil.brown.name/md
warn: Are you sure you pushed 'HEAD' there?
Yet
git ls-remote git://neil.brown.name/md | grep 2ac29
shows
2ac295a544dcae9299cba13ce250419117ae7fd1refs/tags/md/3.15-fixes^{}
Which seems clear and unambiguous.
Does this mean that the 'end' arg to 'git request-pull' is no longer optional
(i.e. the man page is wrong), or that too many heuristics were removed?
Looking through the change log a bit, it seems that if the 'end' arg is
omitted, then the current 'branch' name is used and must match the same name
at the git URL. Could it also check the current 'tag' name? As we are
encouraged to used signed tags, this seems sensible.
In fact, I would suggest checking for a tag first, and only considering the
branch name if there is no tag on the current commit.
Thanks,
NeilBrown
signature.asc
Description: PGP signature
Re: [ANNOUNCE] Git v2.0.0
On Mon, Jun 2, 2014 at 7:08 PM, NeilBrown ne...@suse.de wrote: git request-pull master git://neil.brown.name/md after tagging the current commit as md/3.15-fixes and pushing out the tag You should *tell* git request-pull what you're actually requesting to pull. The old let's guess based on the commit at the top of your tree may have worked for you (because you only ever had one matching thing), but it did not work in general. So the new git request-pull does not guess. If you want to request a tag to be pulled, you name it. Because if you don't name it, it now defaults to HEAD (like all other git log commands) rather than guessing. So please write it as git request-pull master git://neil.brown.name/md md/3.15-fixes I guess the man-page should be made more explicit about this too. Linus -- 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: [ANNOUNCE] Git v2.0.0
Felipe Contreras felipe.contre...@gmail.com writes: Jeff King wrote: On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote: This is the last mail I sent to you, because you ignore them anyway, and remove them from the mailing list. [...] [2], a mail you conveniently removed from the tracked record. [...] You also conveniently removed this mail from the archives. I see you already noticed the changes in v2.0, but I wanted to address these points, because I consider silent censorship to be a serious accusation. Yes, I also think silent censorship is a very seriours matter, and I was very dissapointed that this mailing list would engage in that. I've reported the bug to gmane.discuss (no link yet, as I'm waiting for the message to go through, but it is not a high traffic group, so it should be easy to find the thread once it is there). Thanks. At first I thought that was the reason, but then I noticed it was always my mails that seemed to get this bug, so I decided it was too much of a coincidence. Some mailing list filters and/or spam filters flag mails with too many recipients so that they need to pass through moderation first. The typical threads on this list are short and have few recipients while longer threads, due to the list policy of adding every participants to the Cc, will tend to have more recipients. So there may a bias against long-running threads with multiple participants with regard to timely delivery. And frankly, if I were a list moderator and software asked me through this sort of coincidence whether a mail should be delivered or not and a glance at it shows nothing but insults, wild accusations, threats and so on for the umpteenth time, I'd consider twice clicking Accept. Whether or not I ultimately did so, this would likely contribute to the delay. -- David Kastrup -- 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: [ANNOUNCE] Git v2.0.0
Jeff King wrote: On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote: This is the last mail I sent to you, because you ignore them anyway, and remove them from the mailing list. [...] [2], a mail you conveniently removed from the tracked record. [...] You also conveniently removed this mail from the archives. I see you already noticed the changes in v2.0, but I wanted to address these points, because I consider silent censorship to be a serious accusation. Yes, I also think silent censorship is a very seriours matter, and I was very dissapointed that this mailing list would engage in that. I've reported the bug to gmane.discuss (no link yet, as I'm waiting for the message to go through, but it is not a high traffic group, so it should be easy to find the thread once it is there). Thanks. At first I thought that was the reason, but then I noticed it was always my mails that seemed to get this bug, so I decided it was too much of a coincidence. Hopefully it's indeed a bug. -- 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: [ANNOUNCE] Git v2.0.0
On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote: This is the last mail I sent to you, because you ignore them anyway, and remove them from the mailing list. [...] [2], a mail you conveniently removed from the tracked record. [...] You also conveniently removed this mail from the archives. I see you already noticed the changes in v2.0, but I wanted to address these points, because I consider silent censorship to be a serious accusation. I do not think Junio or anyone else has the technical ability to remove messages from the archive. There is not one archive, but rather several that get messages straight from vger.kernel.org and keep their own database (e.g., gmane, marc, spinics, nabble). E.g., here is the deleted message on nabble: http://git.661346.n2.nabble.com/PATCH-remote-helpers-point-at-their-upstream-repositories-td7610799i20.html#a7611324 Here it is on gmane: http://permalink.gmane.org/gmane.comp.version-control.git/249741 However, I had to pull that link from the NNTP interface. If you look at the non-threaded web interface for gmane here: http://blog.gmane.org/gmane.comp.version-control.git/day=20140520 and here: http://blog.gmane.org/gmane.comp.version-control.git/day=20140521 you will see that there is a huge gap in the list coverage from about midnight on the 20th until the 24th (but these messages are available via nntp). So this seems much more like a gmane bug than anything else. I've reported the bug to gmane.discuss (no link yet, as I'm waiting for the message to go through, but it is not a high traffic group, so it should be easy to find the thread once it is there). -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: [ANNOUNCE] Git v2.0.0
Jeff King p...@peff.net writes: On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote: This is the last mail I sent to you, because you ignore them anyway, and remove them from the mailing list. [...] [2], a mail you conveniently removed from the tracked record. [...] You also conveniently removed this mail from the archives. I see you already noticed the changes in v2.0, but I wanted to address these points, because I consider silent censorship to be a serious accusation. I do not think Junio or anyone else has the technical ability to remove messages from the archive. You can post self-destructing messages by adding X-no-archive: yes if I am not mistaken. But that only concerns stuff you post yourself. There is not one archive, but rather several that get messages straight from vger.kernel.org and keep their own database (e.g., gmane, marc, spinics, nabble). Frankly, I find it weird that vger.kernel.org does not have an archive of its own. But yes, that makes it unlikely that silent censorship is much of a thing. A list moderator may put a particular sender on silent moderation, where postings will only appear once he has acknowledged them. However, that is a manual and burdensome process and requires an up-front decision to do so. Once a message made it to the list, the various archives will pick it up. -- David Kastrup -- 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: [ANNOUNCE] Git v2.0.0
On Thu, May 29, 2014 at 09:23:06PM +0200, David Kastrup wrote: I do not think Junio or anyone else has the technical ability to remove messages from the archive. You can post self-destructing messages by adding X-no-archive: yes if I am not mistaken. But that only concerns stuff you post yourself. Right, I was thinking specifically of deleting somebody else's message. The other obvious choke point is to convince vger to silently drop messages from somebody, but: 1. That is different than deleting already-posted messages. 2. vger is maintained by kernel.org folks, none of whom is a regular on the git list. So it would involve some collusion with those admins. That is pretty clearly not what happened here (the messages did go out to the list). Frankly, I find it weird that vger.kernel.org does not have an archive of its own. I don't think there is much need, as gmane is pretty featureful (and if you disagree, there are other competitors, or you can set up your own). I assume the current situation grew organically (somebody wanted an archive, so they set it up, and then vger saw no need to compete). -Peff PS My gmane bug report posted here: http://article.gmane.org/gmane.discuss/16175 -- 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: [ANNOUNCE] Git v2.0.0
Junio C Hamano gits...@pobox.com writes: The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ Heh, I do not know how this slipped in, but the real release tarball is not in git/testing/ but found at: https://www.kernel.org/pub/software/scm/git/ -- 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: [ANNOUNCE] Git v2.0.0
This is the last mail I sent to you, because you ignore them anyway, and
remove them from the mailing list.
I'm am cc'ing the git-fc mailing list so there's a public track record
of this, so you can't claim it didn't happen.
Junio C Hamano wrote:
* The remote-hg/bzr remote-helper interfaces (used to be in
contrib/) are no more. They are now maintained separately as
third-party plug-ins in their own repositories.
This is a lie. You are saying they don't exist any more, but they do
exist, they graduated according to your same words.
Also, in mail [1] Jeff said:
But that being said, this is Felipe's code. While we have a legal
right to distribute it in v2.0, if he would really prefer it out for
v2.0, I would respect that.
To which you agreed, however, after you fucked up v2.0 and removed an
important patch, I said I changed my wish that I didn't want to disturb
v2.0 in mail [2], a mail you conveniently removed from the tracked
record.
In mail [3] you acknowledged my wish, and you said you were going to put
stubs for v2.0, and you didn't. You also conveniently removed this mail
from the archives.
Your rhetoric to make it appear as if the code is gone, your repeated
failures to accomplish my wish, even you said you would, and your
deliberate removal of the relevant discussion gives me no choice.
I threat all this as deliberate acts of aggression, and I will respond
as I said I would, and bring as much public attention to what you are
doing as possible.
[1] 20140516084126.gb21...@sigill.intra.peff.net
[2] 537bbd6c1daf_a6f166b308b0@nysa.notmuch
[3] xmqqlhtwrufq@gitster.dls.corp.google.com
For reference, here's the full content of mail [2]:
From: Felipe Contreras felipe.contre...@gmail.com
Subject: Re: [PATCH] remote-helpers: point at their upstream repositories
To: Junio C Hamano gits...@pobox.com, Felipe Contreras
felipe.contre...@gmail.com
Cc: Jeff King p...@peff.net, git@vger.kernel.org
Date: Tue, 20 May 2014 15:39:08 -0500
--- text/plain ---
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
2. add warning that is given every time the scripts are run and
give the same instruction as in README.
3. (optional) cripple the script to make them always fail after
showing the same warning as above.
This is what I want, and I already sent the patches for; the scripts
will be stubs. At this point you would have effectively removed the
code, which what I want.
4. Keep README and retire everything else.
After you've removed the code, I don't care what you do, but I'd say you
should remove the stubs after a long period of time.
Let's try this in a different way, as I sense there is a
misunderstanding somewhere about your wish.
that does not refer to remove them at v2.0 (unconditional). It
refers to If Felipe really wants for the removal for v2.0, I would
respect that. And I saw you said you did not want to disrupt v2.0.
If the options I listed all meant removal at v2.0, then I would
understand your complaints, but that is not the case, so I am not
sure what to make of that.
It is a weird choice of semantics then. You said you would respect my
wish, but your proposals did not follow my wish.
I understand you do not want to disrupt v2.0. My assumption of that
not disrupting v2.0 has been there still are git-remote-{hg,bzr}
that work just like what they had in v1.9.x, perhaps with some
enhancements and regressions you added in the meantime, and I
understood Peff's comment If Felipe wants the removal to mean that
kind of disruption, i.e. there is no git-remote-{hg,bzr} that
work., which would be either step 3 or 4.
But your After you've removed the code comment above makes me
wonder that perhaps your definition of not disrupting was
different from ours (which is not good or bad, just different) and
you consider that step 3. is removal but not distupting v2.0?
If that is what you want in v2.0, then please say so, and I already
said I am fine with that.
No, I already said I do not want the code removed from v2.0, that's why
I sent patches that simply added a warning, and I specifically said
those were for 2.0.
However, after seeing this commit:
10e1fee (Revert Merge branch 'fc/transport-helper-sync-error-fix')
Which is:
1) Inaccurate
2) A lie (*you* broke 2.0, not me)
3) A disservice to users
I therefore change my wish for you to remove all the remote helpers code
and a replace them with stubs (the patches I originally sent for
post-2.0).
It was a mistake from me to believe you would do the sensible thing for
2.0.
So to make it clear, I now request that you do:
1) Remove all the code.
Since my patches were removed from the list, here's an updated patch
that applies on top of 'master'
https://github.com/felipec/git/commits/up/remote/remove
2) Reapply d508e4a (Merge branch 'fc/transport-helper-sync-error-fix')
RE: [ANNOUNCE] Git v2.0.0
Felipe Contreras wrote: In mail [3] you acknowledged my wish, and you said you were going to put stubs for v2.0, and you didn't. You also conveniently removed this mail from the archives. My bad. You actually did it. I missed it because the commit is named 'Revert Merge branch 'jc/graduate-remote-hg-bzr' (early part)', which is not at all what it is doing. So it's just the release notes that are misleading. -- 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: [ANNOUNCE] Git v2.0.0-rc4
On Tue, May 20, 2014 at 05:24:50PM -0700, Junio C Hamano wrote: (...) * git reset learned the -N option, which does not reset the index fully for paths the index knows about but the tree-ish the command resets to does not (these paths are kept as intend-to-add entries). I find it quite hard to parse this sentance. Maybe something like: which keeps paths as intent-to-add entries if they are currently staged, but not present in the tree-ish being reset to. would be clearer (I hope I've actually managed to understand it..)? (...) * Commands that take pathspecs on the command line misbehaved when the pathspec is given as an absolute pathname (which is a practice not particularly encouraged) that points at a symbolic link in the working tree. (merge later 655ee9e mw/symlinks to maint.) In order to include the latest cleanup to this patchset: setup: fix windows path buffer over-stepping this should be 6127ff6 instead. Sorry if it's unneeded to note, but just wanted to make sure :) -- Martin Erik Werner martinerikwer...@gmail.com -- 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: [ANNOUNCE] Git v2.0.0-rc4
Martin Erik Werner martinerikwer...@gmail.com writes: * Commands that take pathspecs on the command line misbehaved when the pathspec is given as an absolute pathname (which is a practice not particularly encouraged) that points at a symbolic link in the working tree. (merge later 655ee9e mw/symlinks to maint.) In order to include the latest cleanup to this patchset: setup: fix windows path buffer over-stepping this should be 6127ff6 instead. Sorry if it's unneeded to note, but just wanted to make sure :) Yeah, that commit is more like fix to a not-quite-right fix rather than cleanup, and is indeed sitting at the tip of mw/symlinks topic I still hold onto, so that it can be later merged to 'maint'. And I agree that it is necessary to merge to 6127ff6 when the topic is merged to 'maint'. The entries in the release notes are fed to the ML (stands for Merge Later) script found on my 'todo' branch from its standard input to remind me of bugfix topics that need to go to 'maint', and the process should have caught it (i.e. the topic has grown and its tip no longer points at the named commit since the entry was written), but somehow I missed it. Will fix it up. Thanks for noticing. -- 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: [ANNOUNCE] Git v2.0.0-rc4
Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: * The remote-helper interface to fast-import/fast-export via the transport-helper has been tightened to avoid leaving the import marks file from a failed/crashed run, as such a file that is out-of- sync with reality confuses a later invocation of itself. Really? Where are the patches for that? I think it's fair to say the way the remote-helpers and transport-helper has been handled for v2.0 has been a total disaster. Thanks for noticing. The last-minute change of plans in the morning on the -rc release day did not help. Will remove. Anything else I missed? -- 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: [ANNOUNCE] Git v2.0.0-rc4
On 2014-05-20 20:24, Junio C Hamano wrote:
Fixes since v1.9 series
---
Unless otherwise noted, all the fixes since v1.9 in the maintenance
track are contained in this release (see the maintenance releases'
notes for details).
[...]
* The shell prompt script (in contrib/), when using the PROMPT_COMMAND
interface, used an unsafe construct when showing the branch name in
$PS1.
(merge 8976500 rh/prompt-pcmode-avoid-eval-on-refname later to maint).
That commit has been merged to maint and is in v1.9.3.
Also, 1e4119c (git-prompt.sh: don't assume the shell expands the value
of PS1) is a fix that is in v2.0.0-rc4 but not v1.9.x. Maybe add
something like:
* The shell prompt script (in contrib/), when using Zsh and the
precmd() interface, printed ${__git_ps1_branch_name} in the prompt
instead of the branch name (regression in v1.9.3).
(merge 1e4119c rh/prompt-pcmode-avoid-eval-on-refname later to
maint).
-Richard
--
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: [ANNOUNCE] Git v2.0.0-rc4
Richard Hansen rhan...@bbn.com writes:
* The shell prompt script (in contrib/), when using the PROMPT_COMMAND
interface, used an unsafe construct when showing the branch name in
$PS1.
(merge 8976500 rh/prompt-pcmode-avoid-eval-on-refname later to maint).
That commit has been merged to maint and is in v1.9.3.
Also, 1e4119c (git-prompt.sh: don't assume the shell expands the value
of PS1) is a fix that is in v2.0.0-rc4 but not v1.9.x. Maybe add
something like:
* The shell prompt script (in contrib/), when using Zsh and the
precmd() interface, printed ${__git_ps1_branch_name} in the prompt
instead of the branch name (regression in v1.9.3).
(merge 1e4119c rh/prompt-pcmode-avoid-eval-on-refname later to
maint).
Yes, already done this morning but not yet ready to be pushed out.
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: [ANNOUNCE] Git v2.0.0-rc4
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: * The remote-helper interface to fast-import/fast-export via the transport-helper has been tightened to avoid leaving the import marks file from a failed/crashed run, as such a file that is out-of- sync with reality confuses a later invocation of itself. Really? Where are the patches for that? I think it's fair to say the way the remote-helpers and transport-helper has been handled for v2.0 has been a total disaster. Thanks for noticing. The last-minute change of plans in the morning on the -rc release day did not help. Will remove. But this changed before that. Anything else I missed? Not as far as I can see. -- 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: [ANNOUNCE] Git v2.0.0-rc4
Junio C Hamano wrote: * The remote-helper interface to fast-import/fast-export via the transport-helper has been tightened to avoid leaving the import marks file from a failed/crashed run, as such a file that is out-of- sync with reality confuses a later invocation of itself. Really? Where are the patches for that? I think it's fair to say the way the remote-helpers and transport-helper has been handled for v2.0 has been a total disaster. -- 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: [ANNOUNCE] Git v2.0.0-rc4
Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: * The remote-helper interface to fast-import/fast-export via the transport-helper has been tightened to avoid leaving the import marks file from a failed/crashed run, as such a file that is out-of- sync with reality confuses a later invocation of itself. Really? Where are the patches for that? The following seems related: commit 10e1feebb454d99eb6644cc53b94255f40e6fe9c Author: Junio C Hamano gits...@pobox.com Date: Wed May 14 12:06:35 2014 -0700 Revert Merge branch 'fc/transport-helper-sync-error-fix' This reverts commit d508e4a8e2391ae2596403b6478d01cf3d5f928f, reversing changes made to e42552135a2a396f37053a89f44952ea907870b2. The author of the original topic says he broke the upcoming 2.0 release with something that relates to synchronization crash regression while refusing to give further specifics, so this would unfortunately be the safest option for the upcoming release. Signed-off-by: Junio C Hamano gits...@pobox.com -- David Kastrup -- 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: [ANNOUNCE] Git v2.0.0-rc0
On Wed, Apr 23, 2014 at 12:47 AM, Junio C Hamano gits...@pobox.com wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
What we could do instead is simply require a newer version of
Getopt::Long, which would let people continue using their ancient OSes
and install a newer version from CPAN if necessary. It's also the
proper way to specify the dependency.
Yes, but if its inability to properly grok --option= is the only
reason we want to add a dependency, wouldn't it suffice to simply
state in the documentation (1) how to recognise the symptom to see
if the version the user has is too old, e.g. if you see this error
message, run 'perl -v' to see if your perl is older than X,
etc. and (2) how to work it around, i.e. instead of giving an empty
value with --option='', say --option ''?
FWIW, the least intrusive approach is what I find most agreeable:
- Fix the tests to use --prefix instead of --prefix=
- Update the documentation like Junio suggests above.
- Reformat an example using --prefix
I.e. use Kyle's patch to t9117, plus something like this:
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 5b3c38d..9f579e0 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -91,6 +91,9 @@ COMMANDS
NOTE: Before Git v2.0, the default prefix was (no prefix). This
meant that SVN-tracking refs were put at refs/remotes/*, which is
incompatible with how Git's own remote-tracking refs are organized.
+If you still want the old default, you can get it by passing
+'--prefix ' on the command line ('--prefix=' may not work if
+your Perl's Getopt::Long is v2.37).
--ignore-paths=regex;;
When passed to 'init' or 'clone' this regular expression will
...Johan
--
Johan Herland, jo...@herland.net
www.herland.net
--
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: [ANNOUNCE] Git v2.0.0-rc0
Johan Herland jo...@herland.net writes:
I.e. use Kyle's patch to t9117, plus something like this:
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 5b3c38d..9f579e0 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -91,6 +91,9 @@ COMMANDS
NOTE: Before Git v2.0, the default prefix was (no prefix). This
meant that SVN-tracking refs were put at refs/remotes/*, which is
incompatible with how Git's own remote-tracking refs are organized.
+If you still want the old default, you can get it by passing
+'--prefix ' on the command line ('--prefix=' may not work if
+your Perl's Getopt::Long is v2.37).
--ignore-paths=regex;;
When passed to 'init' or 'clone' this regular expression will
Thanks, will squash in.
--
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: [ANNOUNCE] Git v2.0.0-rc0
On Apr 18, 2014, at 12:37, Junio C Hamano wrote:
An early preview release Git v2.0.0-rc0 is now available for
testing at the usual places.
I have run into the following test failures with v2.0.0-rc0:
Test Summary Report
---
t9117-git-svn-init-clone.sh (Wstat: 256 Tests: 11 Failed: 2)
Failed tests: 10-11
Non-zero exit status: 1
Files=658, Tests=11878, 3684 wallclock secs
Result: FAIL
The cause of the failure in both tests is this:
$ git svn init -s $svnrepo/project project --prefix=
Option prefix requires an argument
The problem with --prefix= is this (from the Getopt::Long CHANGES file):
Changes in version 2.37
---
* Bugfix: With gnu_compat, --foo= will no longer trigger Option
requires an argument but return the empty string.
The system I ran the tests on happens to have Getopt::Long version 2.35.
The --prefix= option can be rewritten --prefix in both tests and then
they pass.
Alternatively this change can be made in git-svn.perl:
|diff --git a/git-svn.perl b/git-svn.perl
|index 7349ffea..284f458a 100755
|--- a/git-svn.perl
|+++ b/git-svn.perl
|@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_stdlayout);
my %icv;
my %init_opts = ( 'template=s' = \$_template, 'shared:s' = \$_shared,
'trunk|T=s' = \$_trunk, 'tags|t=s@' = \@_tags,
- 'branches|b=s@' = \@_branches, 'prefix=s' = \$_prefix,
+ 'branches|b=s@' = \@_branches, 'prefix:s' = \$_prefix,
'stdlayout|s' = \$_stdlayout,
'minimize-url|m!' = \$Git::SVN::_minimize_url,
'no-metadata' = sub { $icv{noMetadata} = 1 },
Which makes the argument to --prefix optional (in which case it is set
to ).
I'm not really sure what the best thing to do here is. I thought the
documentation talked somewhere about using --prefix= (or just --prefix=)
to get the old behavior, but now I can't find that. In that
case I think probably just changing the tests to use --prefix
instead of --prefix= should take care of it especially since the log
message for fe191fca (which actually changes the default) talks about
using --prefix and not --prefix=. I have attached a patch below
(against master) to make that change to the two affected subtests of t9117.
--Kyle
8
Subject: [PATCH] t9117: use --prefix instead of --prefix=
Versions of Perl's Getopt::Long module before 2.37 do not contain
this fix that first appeared in Getopt::Long version 2.37:
* Bugfix: With gnu_compat, --foo= will no longer trigger Option
requires an argument but return the empty string.
Instead of using --prefix= use --prefix when testing an
explictly empty prefix string in order to work with older versions
of Perl's Getopt::Long module.
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
t/t9117-git-svn-init-clone.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t9117-git-svn-init-clone.sh b/t/t9117-git-svn-init-clone.sh
index dfed76fe..a66f43c6 100755
--- a/t/t9117-git-svn-init-clone.sh
+++ b/t/t9117-git-svn-init-clone.sh
@@ -101,18 +101,18 @@ test_expect_success 'clone with -s/-T/-b/-t assumes
--prefix=origin/' '
rm -f warning
'
-test_expect_success 'init with -s/-T/-b/-t and --prefix= still works' '
+test_expect_success 'init with -s/-T/-b/-t and --prefix still works' '
test ! -d project
- git svn init -s $svnrepo/project project --prefix= 2warning
+ git svn init -s $svnrepo/project project --prefix 2warning
test_must_fail grep -q prefix warning
test_svn_configured_prefix
rm -rf project
rm -f warning
'
-test_expect_success 'clone with -s/-T/-b/-t and --prefix= still works' '
+test_expect_success 'clone with -s/-T/-b/-t and --prefix still works' '
test ! -d project
- git svn clone -s $svnrepo/project --prefix= 2warning
+ git svn clone -s $svnrepo/project --prefix 2warning
test_must_fail grep -q prefix warning
test_svn_configured_prefix
rm -rf project
--
1.8.5
--
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: [ANNOUNCE] Git v2.0.0-rc0
Kyle J. McKay wrote:
The problem with --prefix= is this (from the Getopt::Long CHANGES file):
Changes in version 2.37
---
* Bugfix: With gnu_compat, --foo= will no longer trigger Option
requires an argument but return the empty string.
The system I ran the tests on happens to have Getopt::Long version 2.35.
Thanks for catching it.
Getopt::Long was updated to 2.37 in perl 5.8.9 (in 5.8.8 it was
updated to 2.35). INSTALL still only recommends Perl 5.8 so that's an
issue.
The --prefix= option can be rewritten --prefix in both tests and then
they pass.
Hm, perhaps we should introduce a 'no-prefix' option to work around
this.
|diff --git a/git-svn.perl b/git-svn.perl
|index 7349ffea..284f458a 100755
|--- a/git-svn.perl
|+++ b/git-svn.perl
|@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_stdlayout);
my %icv;
my %init_opts = ( 'template=s' = \$_template, 'shared:s' = \$_shared,
'trunk|T=s' = \$_trunk, 'tags|t=s@' = \@_tags,
'branches|b=s@' = \@_branches, 'prefix=s' = \$_prefix,
+ 'no-prefix' = sub { $_prefix = },
'stdlayout|s' = \$_stdlayout,
'minimize-url|m!' = \$Git::SVN::_minimize_url,
'no-metadata' = sub { $icv{noMetadata} = 1 },
That way, normal usage of --prefix would still be consistent with
other git commands that prefer the form with argument attached
(--prefix=foo, not --prefix foo; see gitcli(7)).
Thoughts?
Jonathan
--
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: [ANNOUNCE] Git v2.0.0-rc0
Kyle J. McKay mack...@gmail.com writes:
Alternatively this change can be made in git-svn.perl:
|diff --git a/git-svn.perl b/git-svn.perl
|index 7349ffea..284f458a 100755
|--- a/git-svn.perl
|+++ b/git-svn.perl
|@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_stdlayout);
my %icv;
my %init_opts = ( 'template=s' = \$_template, 'shared:s' = \$_shared,
'trunk|T=s' = \$_trunk, 'tags|t=s@' = \@_tags,
- 'branches|b=s@' = \@_branches, 'prefix=s' = \$_prefix,
+ 'branches|b=s@' = \@_branches, 'prefix:s' = \$_prefix,
'stdlayout|s' = \$_stdlayout,
'minimize-url|m!' = \$Git::SVN::_minimize_url,
'no-metadata' = sub { $icv{noMetadata} = 1 },
Which makes the argument to --prefix optional (in which case it is set
to ).
We do want to learn what prefix the user wants to use when they
start their command line with git svn --prefix. Stopping the
command line right there and expecting it to default to whatever
built-in prefix is simply strange; the user could have omitted that
--prefix that lacks the argument. If the user did want us to use
the default by passing an empty string as its argument, both forms,
i.e. --prefix '' and --prefix='', ought to be usable, but if
older Getopt::Long() does not allow the latter form, at least the
former is the right way for the user to tell us that.
So I think your fix (workaround for a bug in older Getopt::Long) in
the patch is the right one. Johan may want to help me by pointing
out if I am missing something.
Thanks.
I'm not really sure what the best thing to do here is. I thought the
documentation talked somewhere about using --prefix= (or just --prefix=)
to get the old behavior, but now I can't find that. In that
case I think probably just changing the tests to use --prefix
instead of --prefix= should take care of it especially since the log
message for fe191fca (which actually changes the default) talks about
using --prefix and not --prefix=. I have attached a patch below
(against master) to make that change to the two affected subtests of t9117.
--Kyle
8
Subject: [PATCH] t9117: use --prefix instead of --prefix=
Versions of Perl's Getopt::Long module before 2.37 do not contain
this fix that first appeared in Getopt::Long version 2.37:
* Bugfix: With gnu_compat, --foo= will no longer trigger Option
requires an argument but return the empty string.
Instead of using --prefix= use --prefix when testing an
explictly empty prefix string in order to work with older versions
of Perl's Getopt::Long module.
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
t/t9117-git-svn-init-clone.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t9117-git-svn-init-clone.sh b/t/t9117-git-svn-init-clone.sh
index dfed76fe..a66f43c6 100755
--- a/t/t9117-git-svn-init-clone.sh
+++ b/t/t9117-git-svn-init-clone.sh
@@ -101,18 +101,18 @@ test_expect_success 'clone with -s/-T/-b/-t assumes
--prefix=origin/' '
rm -f warning
'
-test_expect_success 'init with -s/-T/-b/-t and --prefix= still works' '
+test_expect_success 'init with -s/-T/-b/-t and --prefix still works' '
test ! -d project
- git svn init -s $svnrepo/project project --prefix= 2warning
+ git svn init -s $svnrepo/project project --prefix 2warning
test_must_fail grep -q prefix warning
test_svn_configured_prefix
rm -rf project
rm -f warning
'
-test_expect_success 'clone with -s/-T/-b/-t and --prefix= still works' '
+test_expect_success 'clone with -s/-T/-b/-t and --prefix still works' '
test ! -d project
- git svn clone -s $svnrepo/project --prefix= 2warning
+ git svn clone -s $svnrepo/project --prefix 2warning
test_must_fail grep -q prefix warning
test_svn_configured_prefix
rm -rf project
--
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: [ANNOUNCE] Git v2.0.0-rc0
Jonathan Nieder jrnie...@gmail.com writes:
Hm, perhaps we should introduce a 'no-prefix' option to work around
this.
...
|diff --git a/git-svn.perl b/git-svn.perl
|index 7349ffea..284f458a 100755
|--- a/git-svn.perl
|+++ b/git-svn.perl
|@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_stdlayout);
my %icv;
my %init_opts = ( 'template=s' = \$_template, 'shared:s' = \$_shared,
'trunk|T=s' = \$_trunk, 'tags|t=s@' = \@_tags,
'branches|b=s@' = \@_branches, 'prefix=s' = \$_prefix,
+ 'no-prefix' = sub { $_prefix = },
'stdlayout|s' = \$_stdlayout,
'minimize-url|m!' = \$Git::SVN::_minimize_url,
'no-metadata' = sub { $icv{noMetadata} = 1 },
That way, normal usage of --prefix would still be consistent with
other git commands that prefer the form with argument attached
(--prefix=foo, not --prefix foo; see gitcli(7)).
Thoughts?
I do not think that it is a good idea to use --no-anything for
something that is not a boolean.
I can buy --old-default-prefix, or --empty-prefix, but running
git svn --prefix '' (or --prefix='') would be OK and logically
consistent anyway (i.e. the option tells us what string to add after
refs/remotes/, and the old default that everybody hated were to
use an empty string), so...
--
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: [ANNOUNCE] Git v2.0.0-rc0
Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: Hm, perhaps we should introduce a 'no-prefix' option to work around this. [...] That way, normal usage of --prefix would still be consistent with other git commands that prefer the form with argument attached (--prefix=foo, not --prefix foo; see gitcli(7)). Thoughts? I do not think that it is a good idea to use --no-anything for something that is not a boolean. Do you mean it is a bad idea to support or a bad idea to make use of such support? I suggested --no- for consistency with current git commands that use parseopt. But on second thought, I agree that it be confusing for --prefix=foo --no-prefix to mean something different from no --prefix parameter at all. The documentation says --prefix=prefix ... Before Git 2.0, the default prefix was (no prefix). This meant that ... which suggests that I can use --prefix= to mean no prefix. Perhaps it needs a note to suggest using '--prefix ' instead? Thanks, Jonathan -- 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: [ANNOUNCE] Git v2.0.0-rc0
Jonathan Nieder jrnie...@gmail.com writes: Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: Hm, perhaps we should introduce a 'no-prefix' option to work around this. [...] That way, normal usage of --prefix would still be consistent with other git commands that prefer the form with argument attached (--prefix=foo, not --prefix foo; see gitcli(7)). Thoughts? I do not think that it is a good idea to use --no-anything for something that is not a boolean. Do you mean it is a bad idea to support or a bad idea to make use of such support? I suggested --no- for consistency with current git commands that use parseopt. But on second thought, I agree that it be confusing for --prefix=foo --no-prefix to mean something different from no --prefix parameter at all. The documentation says --prefix=prefix ... Before Git 2.0, the default prefix was (no prefix). This meant that ... which suggests that I can use --prefix= to mean no prefix. Perhaps it needs a note to suggest using '--prefix ' instead? Is there another --option that takes an arbitrary user string that could be an empty string (or will there be one in the future)? If that is the case, a better alternative might be to add an comment to say that those with older Getopt::Long may have to use --option instead of the --option= form for any option whose value happens to be an empty string to work around the command parser bug. -- 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: [ANNOUNCE] Git v2.0.0-rc0
Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: The documentation says --prefix=prefix ... Before Git 2.0, the default prefix was (no prefix). This meant that ... which suggests that I can use --prefix= to mean no prefix. Perhaps it needs a note to suggest using '--prefix ' instead? Is there another --option that takes an arbitrary user string that could be an empty string (or will there be one in the future)? In git in general, yes --- for example, 'git diff --src-prefix= HEAD^' tells git diff to leave off the usual c/ prefix in the src filename it prints. In git-svn, --trunk= or --message= might be meaningful, but not nearly as much as --prefix=. If that is the case, a better alternative might be to add an comment to say that those with older Getopt::Long may have to use --option instead of the --option= form for any option whose value happens to be an empty string to work around the command parser bug. Another possibility would be to require Perl 5.8.9 or newer. It was released in 2008. diff --git i/git-svn.perl w/git-svn.perl index 0a32372..ec7910d 100755 --- i/git-svn.perl +++ w/git-svn.perl @@ -1,7 +1,7 @@ #!/usr/bin/perl # Copyright (C) 2006, Eric Wong normalper...@yhbt.net # License: GPL v2 or later -use 5.008; +use 5.008_009; use warnings; use strict; use vars qw/ $AUTHOR $VERSION -- 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: [ANNOUNCE] Git v2.0.0-rc0
brian m. carlson sand...@crustytoothpaste.net writes: On Tue, Apr 22, 2014 at 03:11:48PM -0700, Jonathan Nieder wrote: Another possibility would be to require Perl 5.8.9 or newer. It was released in 2008. RHEL 5 and CentOS 5 are still shipping with 5.8.8. They are still security-supported until 2017, and believe it or not people still develop on them. I am personally fine with this change, though. What we could do instead is simply require a newer version of Getopt::Long, which would let people continue using their ancient OSes and install a newer version from CPAN if necessary. It's also the proper way to specify the dependency. Yes, but if its inability to properly grok --option= is the only reason we want to add a dependency, wouldn't it suffice to simply state in the documentation (1) how to recognise the symptom to see if the version the user has is too old, e.g. if you see this error message, run 'perl -v' to see if your perl is older than X, etc. and (2) how to work it around, i.e. instead of giving an empty value with --option='', say --option ''? -- 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: [ANNOUNCE] Git v2.0.0-rc0
Junio C Hamano wrote: * transport-helper, fast-import and fast-export have been updated to allow the ref mapping and ref deletion in a way similar to the natively supported transports. Have they? % git --version git version 2.0.0.rc0 % git push origin origin master:foo /tmp/test[master] nysa searching for changes no changes found fatal: remote-helpers do not support old:new syntax ERROR: unhandled export command: I think you are missing the patches which I just resent[1]. [1] http://article.gmane.org/gmane.comp.version-control.git/246558 -- 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: [ANNOUNCE] Git v2.0.0-rc0
Johan Herland jo...@herland.net writes: On Fri, Apr 18, 2014 at 9:37 PM, Junio C Hamano gits...@pobox.com wrote: An early preview release Git v2.0.0-rc0 is now available for testing at the usual places. This is supposed to have _all_ the v2.0 topics, correct? I'm unable to find the commit that actually _changes_ the default prefix for git svn (as announced in Documentation/git-svn.txt and the release notes for v1.8.5 and v1.9.0). Yes, I noticed that the topic has been in the release notes for a few cycles but the changes never came to my tree (perhaps review of the patch series never concluded?) at the beginning of this cycle, so dropped it from the release notes. For reference, it was posted as patch 3/3 back in October: http://thread.gmane.org/gmane.comp.version-control.git/232761/focus=235900 Very sorry for not discovering this earlier. Well, things happen X-. I see the other two contained in the merge from Eric at 1668b7d78f81 (Merge git://git.bogomips.org/git-svn, 2013-10-16). Is the last one still viable? From my point of view, it would be best if Eric can take another look on it and throw me a pull request (and I have to remember to resurrect the entry in the release notes). Alternatively I could revert the Warn about changing the default for now and defer the topic to v2.1. Eric, what do you think? My preference is not to revert but at the same time I am hesitant to take a patch that was posted as RFC this late in the cycle without input from the area expert, so... -- 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: [ANNOUNCE] Git v2.0.0-rc0
On Fri, Apr 18, 2014 at 9:37 PM, Junio C Hamano gits...@pobox.com wrote: An early preview release Git v2.0.0-rc0 is now available for testing at the usual places. This is supposed to have _all_ the v2.0 topics, correct? I'm unable to find the commit that actually _changes_ the default prefix for git svn (as announced in Documentation/git-svn.txt and the release notes for v1.8.5 and v1.9.0). For reference, it was posted as patch 3/3 back in October: http://thread.gmane.org/gmane.comp.version-control.git/232761/focus=235900 Very sorry for not discovering this earlier. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- 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
