Re: [ANNOUNCE] Git v2.0.0
On Mon, 2 Jun 2014 19:59:53 -0700 Linus Torvalds wrote: > On Mon, Jun 2, 2014 at 7:08 PM, NeilBrown 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 Mon, Jun 2, 2014 at 7:08 PM, NeilBrown 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
On Wed, 28 May 2014 15:31:13 -0700 Junio C Hamano 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
Jeff King writes: > 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. I am reading more than one list through Gmane/nntp, and in the last years it was not infrequent that delivery paused for even days and/or spurious old messages from the last day or even more were getting redelivered. > 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. Quite so. In particular when other mirrors got the messages timely. -- 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 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 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
Felipe Contreras 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 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
Jeff King 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 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
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
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 Subject: Re: [PATCH] remote-helpers: point at their upstream repositories To: Junio C Hamano , Felipe Contreras Cc: Jeff King , git@vger.kernel.org Date: Tue, 20 May 2014 15:39:08 -0500 --- text/plain --- Junio C Hamano wrote: > Felipe Contreras 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-
Re: [ANNOUNCE] Git v2.0.0
Junio C Hamano 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-rc4
Junio C Hamano wrote: > Felipe Contreras 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
Richard Hansen 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
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
Felipe Contreras 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
Martin Erik Werner 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
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 -- 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 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 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 -- 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-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-rc0
Johan Herland 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=;; > 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 Wed, Apr 23, 2014 at 12:47 AM, Junio C Hamano wrote: > "brian m. carlson" 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=;; When passed to 'init' or 'clone' this regular expression will ...Johan -- Johan Herland, 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
"brian m. carlson" 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
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. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [ANNOUNCE] Git v2.0.0-rc0
Junio C Hamano wrote: > Jonathan Nieder writes: >> The documentation says >> >> --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 # 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
Jonathan Nieder writes: > Junio C Hamano wrote: >> Jonathan Nieder 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= > > ... > > 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 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= ... 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 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
"Kyle J. McKay" 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 > --- > 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="" 2>warning && > + git svn init -s "$svnrepo"/project project --prefix "" 2>warning && > 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="" 2>warning && > + git svn clone -s "$svnrepo"/project --prefix "" 2>warning && > 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
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
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 --- 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="" 2>warning && + git svn init -s "$svnrepo"/project project --prefix "" 2>warning && 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="" 2>warning && + git svn clone -s "$svnrepo"/project --prefix "" 2>warning && 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
Felipe Contreras writes: > 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? Yikes, no. This was me mischaracterizingg the merge at 90e6255a6d01 (Merge branch 'fc/transport-helper-fixes', 2014-03-18). It was about letting the transport respond to 'force', and not about ref mapping, I think. Thanks for spotting. Will remove that section from the release notes in the meantime. As to the resurrection of the series, that will have to cook outside 'master' at least for the remainder of this cycle. -- 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 writes: > On Fri, Apr 18, 2014 at 9:37 PM, Junio C Hamano 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 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, 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