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
[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 path is the same as git add -A path 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 path used
to ignore removals. You can say git add --ignore-removal path to
add only added or modified paths in path, 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=key-id).
* 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=mode 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 path is the same as git add -A path now.
* core.statinfo configuration variable, which
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
