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
[ANNOUNCE] Git v2.0.0-rc4
A release candidate Git v2.0.0-rc4, hopefully the final one before
the real thing, is now available for testing at the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the 'v2.0.0-rc4'
tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v2.0 Release Notes (draft)
==
Backward compatibility notes
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). In Git 2.0, the default is now the "simple" semantics,
which pushes:
- only the current branch to the branch with the same name, and only
when the current branch is set to integrate with that remote
branch, if you are pushing to the same remote as you fetch from; or
- only the current branch to the branch with the same name, if you
are pushing to a remote that is not where you usually fetch from.
You can use the configuration variable "push.default" to change
this. If you are an old-timer who wants to keep using the
"matching" semantics, you can set the variable to "matching", for
example. Read the documentation for other possibilities.
When "git add -u" and "git add -A" are run inside a subdirectory
without specifying which paths to add on the command line, they
operate on the entire tree for consistency with "git commit -a" and
other commands (these commands used to operate only on the current
subdirectory). Say "git add -u ." or "git add -A ." if you want to
limit the operation to the current directory.
"git add " is the same as "git add -A " now, so that
"git add dir/" will notice paths you removed from the directory and
record the removal. In older versions of Git, "git add " used
to ignore removals. You can say "git add --ignore-removal " to
add only added or modified paths in , if you really want to.
The "-q" option to "git diff-files", which does *NOT* mean "quiet",
has been removed (it told Git to ignore deletion, which you can do
with "git diff-files --diff-filter=d").
"git request-pull" lost a few "heuristics" that often led to mistakes.
The default prefix for "git svn" has changed in Git 2.0. For a long
time, "git svn" created its remote-tracking branches directly under
refs/remotes, but it now places them under refs/remotes/origin/ unless
it is told otherwise with its "--prefix" option.
Updates since v1.9 series
-
UI, Workflows & Features
* The "multi-mail" post-receive hook (in contrib/) has been updated
to a more recent version from upstream.
* The "remote-hg/bzr" remote-helper interfaces (in contrib/) are
now maintained separately as a third-party plug-in.
* "git gc --aggressive" learned "--depth" option and
"gc.aggressiveDepth" configuration variable to allow use of a less
insane depth than the built-in default value of 250.
* "git log" learned the "--show-linear-break" option to show where a
single strand-of-pearls is broken in its output.
* The "rev-parse --parseopt" mechanism used by scripted Porcelains to
parse command-line options and to give help text learned to take
the argv-help (the placeholder string for an option parameter,
e.g. "key-id" in "--gpg-sign=").
* The pattern to find where the function begins in C/C++ used in
"diff" and "grep -p" has been updated to improve viewing C++
sources.
* "git rebase" learned to interpret a lone "-" as "@{-1}", the
branch that we were previously on.
* "git commit --cleanup=" learned a new mode, scissors.
* "git tag --list" output can be sorted using "version sort" with
"--sort=version:refname".
* Discard the accumulated "heuristics" to guess from which branch the
result wants to be pulled from and make sure that what the end user
specified is not second-guessed by "git request-pull", to avoid
mistakes. When you pushed out your 'master' branch to your public
repository as 'for-linus', use the new "master:for-linus" syntax to
denote the branch to be pulled.
* "git grep" learned to behave in a way similar to native grep when
"-h" (no header) and "-c" (count) options are given.
* "git push" via transport-helper interface has been updated to
allow forced ref updates in a way similar to the natively
supported transports.
* The "simple" mode is the default for "git push".
* "git add -u" and "git add -A", when run without any pathspec, is a
tree-wide operation even when run inside a subdirectory of a
working tree.
* "git add " is the
