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