* [PATCHv2 00/21] completion: various __gitdir()-related improvements
From: SZEDER Gábor @ 2017-02-03 2:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor
This is a long overdue reroll of a bunch of bugfixes, cleanups and
optimizations related to how the completion script finds the path to
the repository and how it uses that path. Most importantly this
series adds support for completion following 'git -C path', and it
eliminates a few subshells and git processes, for the sake of
fork()+exec() challenged OSes.
The first round is at [1]. It made its way to pu back then, but since
the reroll didn't come it was eventually discarded.
What did NOT change since v1 is that the new option added to 'git
rev-parse' is still called '--absolute-git-dir'. There was a
suggestion [2] to turn it into an orthogonal '--absolute-dir' option
that works with other path-querying options, too, but I really doubt
it's worth it. In short, regular scripts don't care, because a
relative path doesn't make any difference for them, and before we do
this orthogonal thing we have to decide a bunch of questions first,
see [3].
Changes since v1:
- Use our real_path() instead of system realpath() to implement 'git
rev-parse --absolute-git-dir'.
- Refactored a bit how __git_refs() determines where it should list
refs from.
- Renamed a few refnames and remote in the tests (this accounts for
the bulk of the interdiff).
- Misc small adjustments: a few more comments, removed unnecessary
disambiguating '--', typofix and more consistent quoting.
- Improved commit messages.
- Rebased to current master.
The interdiff below is compared to v1 rebased on top of current master.
This series is also available at
https://github.com/szeder/git completion-gitdir-improvements
[1] - http://public-inbox.org/git/1456440650-32623-1-git-send-email-szeder@ira.uka.de/T/
[2] - http://public-inbox.org/git/CANoM8SXO_Rz_CVOz9ptsaVCzcQ2D1FQrSuFFW4vZ4SdRYMzD=w@mail.gmail.com/
[3] - http://public-inbox.org/git/20160518185825.Horde.EPd2nJNvqEW_VX4b01yWdIr@webmail.informatik.kit.edu/
SZEDER Gábor (21):
completion: improve __git_refs()'s in-code documentation
completion tests: don't add test cruft to the test repository
completion tests: make the $cur variable local to the test helper
functions
completion tests: consolidate getting path of current working
directory
completion tests: check __gitdir()'s output in the error cases
completion tests: add tests for the __git_refs() helper function
completion: ensure that the repository path given on the command line
exists
completion: fix most spots not respecting 'git --git-dir=<path>'
completion: respect 'git --git-dir=<path>' when listing remote refs
completion: list refs from remote when remote's name matches a
directory
completion: don't list 'HEAD' when trying refs completion outside of a
repo
completion: list short refs from a remote given as a URL
completion: don't offer commands when 'git --opt' needs an argument
completion: fix completion after 'git -C <path>'
rev-parse: add '--absolute-git-dir' option
completion: respect 'git -C <path>'
completion: don't use __gitdir() for git commands
completion: consolidate silencing errors from git commands
completion: don't guard git executions with __gitdir()
completion: extract repository discovery from __gitdir()
completion: cache the path to the repository
Documentation/git-rev-parse.txt | 4 +
builtin/rev-parse.c | 26 +-
contrib/completion/git-completion.bash | 250 ++++++++++-----
t/t1500-rev-parse.sh | 17 +-
t/t9902-completion.sh | 561 +++++++++++++++++++++++++++++----
5 files changed, 690 insertions(+), 168 deletions(-)
--
2.11.0.555.g967c1bcb3
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index 4040b3c86..1967bafba 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -820,10 +820,7 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
if (!gitdir && !prefix)
gitdir = ".git";
if (gitdir) {
- char absolute_path[PATH_MAX];
- if (!realpath(gitdir, absolute_path))
- die_errno(_("unable to get absolute path"));
- puts(absolute_path);
+ puts(real_path(gitdir));
continue;
}
}
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0184d0ebc..ed06cb621 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -350,41 +350,38 @@ __git_tags ()
# Lists refs from the local (by default) or from a remote repository.
# It accepts 0, 1 or 2 arguments:
-# 1: The remote to lists refs from (optional; ignored, if set but empty).
+# 1: The remote to list refs from (optional; ignored, if set but empty).
# Can be the name of a configured remote, a path, or a URL.
# 2: In addition to local refs, list unique branches from refs/remotes/ for
# 'git checkout's tracking DWIMery (optional; ignored, if set but empty).
__git_refs ()
{
local i hash dir track="${2-}"
- local from_local=y remote="${1-}" named_remote=n
+ local list_refs_from=path remote="${1-}"
local format refs pfx
__git_find_repo_path
dir="$__git_repo_path"
- if [ -z "$dir" ] && [ -z "$remote" ]; then
- return
- fi
-
- if [ -n "$remote" ]; then
+ if [ -z "$remote" ]; then
+ if [ -z "$dir" ]; then
+ return
+ fi
+ else
if __git_is_configured_remote "$remote"; then
# configured remote takes precedence over a
# local directory with the same name
- from_local=n
- named_remote=y
+ list_refs_from=remote
+ elif [ -d "$remote/.git" ]; then
+ dir="$remote/.git"
+ elif [ -d "$remote" ]; then
+ dir="$remote"
else
- if [ -d "$remote/.git" ]; then
- dir="$remote/.git"
- elif [ -d "$remote" ]; then
- dir="$remote"
- else
- from_local=n
- fi
+ list_refs_from=url
fi
fi
- if [ "$from_local" = y ] && [ -d "$dir" ]; then
+ if [ "$list_refs_from" = path ]; then
case "$cur" in
refs|refs/*)
format="refname"
@@ -430,18 +427,18 @@ __git_refs ()
done
;;
*)
- if [ "$named_remote" = y ]; then
+ if [ "$list_refs_from" = remote ]; then
echo "HEAD"
- __git for-each-ref --format="%(refname:short)" -- \
+ __git for-each-ref --format="%(refname:short)" \
"refs/remotes/$remote/" | sed -e "s#^$remote/##"
else
__git ls-remote "$remote" HEAD \
- 'refs/tags/*' 'refs/heads/*' 'refs/remotes/*' |
+ "refs/tags/*" "refs/heads/*" "refs/remotes/*" |
while read -r hash i; do
case "$i" in
*^{}) ;;
refs/*) echo "${i#refs/*/}" ;;
- *) echo "$i" ;;
+ *) echo "$i" ;; # symbolic refs
esac
done
fi
@@ -910,7 +907,7 @@ __git_get_option_value ()
done
if [ -n "$config_key" ] && [ -z "$result" ]; then
- result="$(git --git-dir="$(__gitdir)" config "$config_key")"
+ result="$(__git config "$config_key")"
fi
echo "$result"
@@ -2830,9 +2827,12 @@ __git_main ()
if [ -z "$command" ]; then
case "$prev" in
--git-dir|-C|--work-tree)
+ # these need a path argument, let's fall back to
+ # Bash filename completion
return
;;
-c|--namespace)
+ # we don't support completing these options' arguments
return
;;
esac
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 1660759e3..d711bef24 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -519,22 +519,19 @@ test_expect_success '__git_is_configured_remote' '
'
test_expect_success 'setup for ref completion' '
- echo content >file1 &&
- echo more >file2 &&
- git add file1 file2 &&
- git commit -m one &&
- git branch mybranch &&
- git tag mytag &&
+ git commit --allow-empty -m initial &&
+ git branch matching-branch &&
+ git tag matching-tag &&
(
cd otherrepo &&
- >file &&
- git add file &&
- git commit -m initial &&
- git branch branch
+ git commit --allow-empty -m initial &&
+ git branch -m master master-in-other &&
+ git branch branch-in-other &&
+ git tag tag-in-other
) &&
- git remote add remote "$ROOT/otherrepo/.git" &&
- git update-ref refs/remotes/remote/branch master &&
- git update-ref refs/remotes/remote/master master &&
+ git remote add other "$ROOT/otherrepo/.git" &&
+ git fetch --no-tags other &&
+ rm -f .git/FETCH_HEAD &&
git init thirdrepo
'
@@ -542,10 +539,10 @@ test_expect_success '__git_refs - simple' '
cat >expected <<-EOF &&
HEAD
master
- mybranch
- remote/branch
- remote/master
- mytag
+ matching-branch
+ other/branch-in-other
+ other/master-in-other
+ matching-tag
EOF
(
cur= &&
@@ -557,7 +554,7 @@ test_expect_success '__git_refs - simple' '
test_expect_success '__git_refs - full refs' '
cat >expected <<-EOF &&
refs/heads/master
- refs/heads/mybranch
+ refs/heads/matching-branch
EOF
(
cur=refs/heads/ &&
@@ -569,8 +566,9 @@ test_expect_success '__git_refs - full refs' '
test_expect_success '__git_refs - repo given on the command line' '
cat >expected <<-EOF &&
HEAD
- branch
- master
+ branch-in-other
+ master-in-other
+ tag-in-other
EOF
(
__git_dir="$ROOT/otherrepo/.git" &&
@@ -583,8 +581,9 @@ test_expect_success '__git_refs - repo given on the command line' '
test_expect_success '__git_refs - remote on local file system' '
cat >expected <<-EOF &&
HEAD
- branch
- master
+ branch-in-other
+ master-in-other
+ tag-in-other
EOF
(
cur= &&
@@ -595,11 +594,12 @@ test_expect_success '__git_refs - remote on local file system' '
test_expect_success '__git_refs - remote on local file system - full refs' '
cat >expected <<-EOF &&
- refs/heads/branch
- refs/heads/master
+ refs/heads/branch-in-other
+ refs/heads/master-in-other
+ refs/tags/tag-in-other
EOF
(
- cur=refs/heads/ &&
+ cur=refs/ &&
__git_refs otherrepo >"$actual"
) &&
test_cmp expected "$actual"
@@ -608,24 +608,25 @@ test_expect_success '__git_refs - remote on local file system - full refs' '
test_expect_success '__git_refs - configured remote' '
cat >expected <<-EOF &&
HEAD
- branch
- master
+ branch-in-other
+ master-in-other
EOF
(
cur= &&
- __git_refs remote >"$actual"
+ __git_refs other >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - configured remote - full refs' '
cat >expected <<-EOF &&
- refs/heads/branch
- refs/heads/master
+ refs/heads/branch-in-other
+ refs/heads/master-in-other
+ refs/tags/tag-in-other
EOF
(
- cur=refs/heads/ &&
- __git_refs remote >"$actual"
+ cur=refs/ &&
+ __git_refs other >"$actual"
) &&
test_cmp expected "$actual"
'
@@ -633,28 +634,29 @@ test_expect_success '__git_refs - configured remote - full refs' '
test_expect_success '__git_refs - configured remote - repo given on the command line' '
cat >expected <<-EOF &&
HEAD
- branch
- master
+ branch-in-other
+ master-in-other
EOF
(
cd thirdrepo &&
__git_dir="$ROOT/.git" &&
cur= &&
- __git_refs remote >"$actual"
+ __git_refs other >"$actual"
) &&
test_cmp expected "$actual"
'
test_expect_success '__git_refs - configured remote - full refs - repo given on the command line' '
cat >expected <<-EOF &&
- refs/heads/branch
- refs/heads/master
+ refs/heads/branch-in-other
+ refs/heads/master-in-other
+ refs/tags/tag-in-other
EOF
(
cd thirdrepo &&
__git_dir="$ROOT/.git" &&
- cur=refs/heads/ &&
- __git_refs remote >"$actual"
+ cur=refs/ &&
+ __git_refs other >"$actual"
) &&
test_cmp expected "$actual"
'
@@ -662,14 +664,14 @@ test_expect_success '__git_refs - configured remote - full refs - repo given on
test_expect_success '__git_refs - configured remote - remote name matches a directory' '
cat >expected <<-EOF &&
HEAD
- branch
- master
+ branch-in-other
+ master-in-other
EOF
- mkdir remote &&
- test_when_finished "rm -rf remote" &&
+ mkdir other &&
+ test_when_finished "rm -rf other" &&
(
cur= &&
- __git_refs remote >"$actual"
+ __git_refs other >"$actual"
) &&
test_cmp expected "$actual"
'
@@ -677,8 +679,9 @@ test_expect_success '__git_refs - configured remote - remote name matches a dire
test_expect_success '__git_refs - URL remote' '
cat >expected <<-EOF &&
HEAD
- branch
- master
+ branch-in-other
+ master-in-other
+ tag-in-other
EOF
(
cur= &&
@@ -689,11 +692,12 @@ test_expect_success '__git_refs - URL remote' '
test_expect_success '__git_refs - URL remote - full refs' '
cat >expected <<-EOF &&
- refs/heads/branch
- refs/heads/master
+ refs/heads/branch-in-other
+ refs/heads/master-in-other
+ refs/tags/tag-in-other
EOF
(
- cur=refs/heads/ &&
+ cur=refs/ &&
__git_refs "file://$ROOT/otherrepo/.git" >"$actual"
) &&
test_cmp expected "$actual"
@@ -709,7 +713,7 @@ test_expect_success '__git_refs - non-existing remote' '
test_expect_success '__git_refs - non-existing remote - full refs' '
(
- cur=refs/heads/ &&
+ cur=refs/ &&
__git_refs non-existing >"$actual"
) &&
test_must_be_empty "$actual"
@@ -725,30 +729,41 @@ test_expect_success '__git_refs - non-existing URL remote' '
test_expect_success '__git_refs - non-existing URL remote - full refs' '
(
- cur=refs/heads/ &&
+ cur=refs/ &&
__git_refs "file://$ROOT/non-existing" >"$actual"
) &&
test_must_be_empty "$actual"
'
+test_expect_success '__git_refs - not in a git repository' '
+ (
+ GIT_CEILING_DIRECTORIES="$ROOT" &&
+ export GIT_CEILING_DIRECTORIES &&
+ cd subdir &&
+ cur= &&
+ __git_refs >"$actual"
+ ) &&
+ test_must_be_empty "$actual"
+'
+
test_expect_success '__git_refs - unique remote branches for git checkout DWIMery' '
cat >expected <<-EOF &&
HEAD
master
- mybranch
- otherremote/ambiguous
- otherremote/otherbranch
+ matching-branch
+ other/ambiguous
+ other/branch-in-other
+ other/master-in-other
remote/ambiguous
- remote/branch
- remote/master
- mytag
- branch
- master
- otherbranch
+ remote/branch-in-remote
+ matching-tag
+ branch-in-other
+ branch-in-remote
+ master-in-other
EOF
- for remote_ref in refs/remotes/remote/ambiguous \
- refs/remotes/otherremote/ambiguous \
- refs/remotes/otherremote/otherbranch
+ for remote_ref in refs/remotes/other/ambiguous \
+ refs/remotes/remote/ambiguous \
+ refs/remotes/remote/branch-in-remote
do
git update-ref $remote_ref master &&
test_when_finished "git update-ref -d $remote_ref"
@@ -760,19 +775,10 @@ test_expect_success '__git_refs - unique remote branches for git checkout DWIMer
test_cmp expected "$actual"
'
-test_expect_success '__git_refs - not in a git repository' '
- (
- GIT_CEILING_DIRECTORIES="$ROOT" &&
- export GIT_CEILING_DIRECTORIES &&
- cd subdir &&
- cur= &&
- __git_refs >"$actual"
- ) &&
- test_must_be_empty "$actual"
-'
-
-test_expect_success 'remove configured remote used for refs completion' '
- git remote remove remote
+test_expect_success 'teardown after ref completion' '
+ git branch -d matching-branch &&
+ git tag -d matching-tag &&
+ git remote remove other
'
test_expect_success '__git_get_config_variables' '
@@ -898,6 +904,15 @@ test_expect_success 'git --help completion' '
test_completion "git --help core" "core-tutorial "
'
+test_expect_success 'setup for integration tests' '
+ echo content >file1 &&
+ echo more >file2 &&
+ git add file1 file2 &&
+ git commit -m one &&
+ git branch mybranch &&
+ git tag mytag
+'
+
test_expect_success 'checkout completes ref names' '
test_completion "git checkout m" <<-\EOF
master Z
@@ -908,7 +923,7 @@ test_expect_success 'checkout completes ref names' '
test_expect_success 'git -C <path> checkout uses the right repo' '
test_completion "git -C subdir -C subsubdir -C .. -C ../otherrepo checkout b" <<-\EOF
- branch Z
+ branch-in-other Z
EOF
'
^ permalink raw reply related
* [PATCH] reset: add an example of how to split a commit into two
From: Jacob Keller @ 2017-02-03 0:30 UTC (permalink / raw)
To: git; +Cc: Jacob Keller
From: Jacob Keller <jacob.keller@gmail.com>
It is sometimes useful to break a commit into parts to more logically
show how the code changes. There are many possible ways to achieve this
result, but one simple and powerful one is to use git reset -p.
Add an example to the documentation showing how this can be done so that
users are more likely to discover this, instead of inventing more
painful methods such as re-writing code from scratch, or duplicating git
add -p more times than necessary.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
---
Documentation/git-reset.txt | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 25432d9257f9..4adac7a25bf9 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -292,6 +292,29 @@ $ git reset --keep start <3>
<3> But you can use "reset --keep" to remove the unwanted commit after
you switched to "branch2".
+Split a commit into two::
++
+Suppose that you have created a commit, but later decide that you want to split
+the changes into two separate commits, including only part of the old commit
+into the first commit, and including the rest as a separate commit on top. You
+can use git reset in patch mode to interactively select which hunks to split
+out into a separate commit.
++
+------------
+$ git reset -p HEAD^ <1>
+$ git commit --amend <2>
+$ git commit ... <3>
+------------
++
+<1> This lets you interactively undo changes between HEAD^ and HEAD, so you can
+ select which parts to remove from the initial commit. The changes are
+ placed into the index, leaving the working tree untouched.
+<2> Now, you ammend the initial commit with the modifications that you just
+ made in the index.
+<3> Finally, you can add and then commit the final original unmodified files
+ back as the second commit, enabling you to logically separate a commit
+ into a sequence of two commits instead.
+
DISCUSSION
----------
--
2.11.0.864.ge7592a54611d
^ permalink raw reply related
* What's cooking in git.git (Feb 2017, #01; Thu, 2)
From: Junio C Hamano @ 2017-02-02 23:05 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The tip of 'master' has most of the topics (and all the big ones)
that should be in the upcoming release. I'll tag 2.12-rc0 sometime
tomorrow. On the 'maint' front, Git 2.11.1 has been tagged with
bugfixes that are already in 'master'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* bc/use-asciidoctor-opt (2017-01-31) 8 commits
(merged to 'next' on 2017-01-31 at f2a641f6f3)
+ Documentation: implement linkgit macro for Asciidoctor
+ Makefile: add a knob to enable the use of Asciidoctor
+ Documentation: move dblatex arguments into variable
+ Documentation: add XSLT to fix DocBook for Texinfo
+ Documentation: sort sources for gitman.texi
+ Documentation: remove unneeded argument in cat-texi.perl
+ Documentation: modernize cat-texi.perl
+ Documentation: fix warning in cat-texi.perl
Asciidoctor, an alternative reimplementation of AsciiDoc, still
needs some changes to work with documents meant to be formatted
with AsciiDoc. "make USE_ASCIIDOCTOR=YesPlease" to use it out of
the box to document our pages is getting closer to reality.
* cw/doc-sign-off (2017-01-27) 1 commit
(merged to 'next' on 2017-01-31 at 133cc2886d)
+ doc: clarify distinction between sign-off and pgp-signing
Doc update.
* ep/commit-static-buf-cleanup (2017-01-31) 2 commits
(merged to 'next' on 2017-01-31 at 02d3c25219)
+ builtin/commit.c: switch to strbuf, instead of snprintf()
+ builtin/commit.c: remove the PATH_MAX limitation via dynamic allocation
Code clean-up.
* gv/mingw-p4-mapuser (2017-01-30) 1 commit
(merged to 'next' on 2017-01-31 at 5a9f2c96f6)
+ git-p4: fix git-p4.mapUser on Windows
"git p4" did not work well with multiple git-p4.mapUser entries on
Windows.
* hv/mingw-help-is-executable (2017-01-30) 1 commit
(merged to 'next' on 2017-01-31 at 89aae8d018)
+ help: improve is_executable() on Windows
"git help" enumerates executable files in $PATH; the implementation
of "is this file executable?" on Windows has been optimized.
* js/mingw-hooks-with-exe-suffix (2017-01-30) 1 commit
(merged to 'next' on 2017-01-31 at 3b7863c578)
+ mingw: allow hooks to be .exe files
Names of the various hook scripts must be spelled exactly, but on
Windows, an .exe binary must be named with .exe suffix; notice
$GIT_DIR/hooks/<hookname>.exe as a valid <hookname> hook.
* js/retire-relink (2017-01-25) 2 commits
(merged to 'next' on 2017-01-31 at c6c6f9b902)
+ relink: really remove the command
+ relink: retire the command
Cruft removal.
* js/status-pre-rebase-i (2017-01-26) 1 commit
(merged to 'next' on 2017-01-31 at 09e51b2e39)
+ status: be prepared for not-yet-started interactive rebase
After starting "git rebase -i", which first opens the user's editor
to edit the series of patches to apply, but before saving the
contents of that file, "git status" failed to show the current
state (i.e. you are in an interactive rebase session, but you have
applied no steps yet) correctly.
* js/unzip-in-usr-bin-workaround (2017-01-27) 1 commit
(merged to 'next' on 2017-01-31 at 515d1d1f90)
+ test-lib: on FreeBSD, look for unzip(1) in /usr/local/bin/
Test tweak for FreeBSD where /usr/bin/unzip is unsuitable to run
our tests but /usr/local/bin/unzip is usable.
* mm/reset-facl-before-umask-test (2017-01-30) 1 commit
(merged to 'next' on 2017-01-31 at 4a2031e49c)
+ t0001: don't let a default ACL interfere with the umask test
Test tweaks for those who have default ACL in their git source tree
that interfere with the umask test.
* nd/log-graph-configurable-colors (2017-01-31) 4 commits
(merged to 'next' on 2017-01-31 at 36df9e2376)
+ color_parse_mem: allow empty color spec
(merged to 'next' on 2017-01-23 at c369982ad8)
+ log --graph: customize the graph lines with config log.graphColors
+ color.c: trim leading spaces in color_parse_mem()
+ color.c: fix color_parse_mem() with value_len == 0
Some people feel the default set of colors used by "git log --graph"
rather limiting. A mechanism to customize the set of colors has
been introduced.
* rs/absolute-pathdup (2017-01-27) 2 commits
(merged to 'next' on 2017-01-31 at f751f64876)
+ use absolute_pathdup()
+ abspath: add absolute_pathdup()
Code cleanup.
* rs/receive-pack-cleanup (2017-01-30) 1 commit
(merged to 'next' on 2017-01-31 at d660881f69)
+ receive-pack: call string_list_clear() unconditionally
Code clean-up.
* sb/submodule-add-force (2016-11-29) 1 commit
+ submodule add: extend force flag to add existing repos
(this branch is used by sb/push-make-submodule-check-the-default.)
Originally merged to 'next' on 2016-12-12
"git submodule add" used to be confused and refused to add a
locally created repository; users can now use "--force" option
to add them.
* sg/mailmap-self (2017-01-31) 1 commit
(merged to 'next' on 2017-01-31 at 2e7641759c)
+ .mailmap: update Gábor Szeder's email address
Will merge to 'master'.
--------------------------------------------------
[Stalled]
* ls/p4-path-encoding (2016-12-18) 1 commit
- git-p4: fix git-p4.pathEncoding for removed files
When "git p4" imports changelist that removes paths, it failed to
convert pathnames when the p4 used encoding different from the one
used on the Git side. This has been corrected.
Will be rerolled.
cf. <7E1C7387-4F37-423F-803D-3B5690B49D40@gmail.com>
* sh/grep-tree-obj-tweak-output (2017-01-20) 2 commits
- grep: use '/' delimiter for paths
- grep: only add delimiter if there isn't one already
"git grep", when fed a tree-ish as an input, shows each hit
prefixed with "<tree-ish>:<path>:<lineno>:". As <tree-ish> is
almost always either a commit or a tag that points at a commit, the
early part of the output "<tree-ish>:<path>" can be used as the
name of the blob and given to "git show". When <tree-ish> is a
tree given in the extended SHA-1 syntax (e.g. "<commit>:", or
"<commit>:<dir>"), however, this results in a string that does not
name a blob (e.g. "<commit>::<path>" or "<commit>:<dir>:<path>").
"git grep" has been taught to be a bit more intelligent about these
cases and omit a colon (in the former case) or use slash (in the
latter case) to produce "<commit>:<path>" and
"<commit>:<dir>/<path>" that can be used as the name of a blob.
Waiting for the review discussion to settle, followed by a reroll.
* mh/ref-remove-empty-directory (2017-01-07) 23 commits
- files_transaction_commit(): clean up empty directories
- try_remove_empty_parents(): teach to remove parents of reflogs, too
- try_remove_empty_parents(): don't trash argument contents
- try_remove_empty_parents(): rename parameter "name" -> "refname"
- delete_ref_loose(): inline function
- delete_ref_loose(): derive loose reference path from lock
- log_ref_write_1(): inline function
- log_ref_setup(): manage the name of the reflog file internally
- log_ref_write_1(): don't depend on logfile argument
- log_ref_setup(): pass the open file descriptor back to the caller
- log_ref_setup(): improve robustness against races
- log_ref_setup(): separate code for create vs non-create
- log_ref_write(): inline function
- rename_tmp_log(): improve error reporting
- rename_tmp_log(): use raceproof_create_file()
- lock_ref_sha1_basic(): use raceproof_create_file()
- lock_ref_sha1_basic(): inline constant
- raceproof_create_file(): new function
- safe_create_leading_directories(): set errno on SCLD_EXISTS
- safe_create_leading_directories_const(): preserve errno
- t5505: use "for-each-ref" to test for the non-existence of references
- refname_is_safe(): correct docstring
- files_rename_ref(): tidy up whitespace
Deletion of a branch "foo/bar" could remove .git/refs/heads/foo
once there no longer is any other branch whose name begins with
"foo/", but we didn't do so so far. Now we do.
Expecting a reroll.
cf. <5051c78e-51f9-becd-e1a6-9c0b781d6912@alum.mit.edu>
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
"git diff -B -M" produced incorrect patch when the postimage of a
completely rewritten file is similar to the preimage of a removed
file; such a resulting file must not be expressed as a rename from
other place.
The fix in this patch is broken, unfortunately.
Will discard.
--------------------------------------------------
[Cooking]
* jk/delta-chain-limit (2017-01-27) 2 commits
- pack-objects: convert recursion to iteration in break_delta_chain()
- pack-objects: enforce --depth limit in reused deltas
"git repack --depth=<n>" for a long time busted the specified depth
when reusing delta from existing packs. This has been corrected.
Will merge to 'next'.
* js/re-running-failed-tests (2017-01-27) 1 commit
(merged to 'next' on 2017-01-31 at 30c3a9e0cf)
+ t/Makefile: add a rule to re-run previously-failed tests
"make -C t failed" will now run only the tests that failed in the
previous run. This is usable only when prove is not use, and gives
a useless error message when run after "make clean", but otherwise
is serviceable.
Will merge to 'master'.
* cw/log-updates-for-all-refs-really (2017-02-01) 4 commits
(merged to 'next' on 2017-02-02 at 3e11673fcc)
+ doc: add note about ignoring '--no-create-reflog'
(merged to 'next' on 2017-01-31 at 53f71d2401)
+ update-ref: add test cases for bare repository
+ refs: add option core.logAllRefUpdates = always
+ config: add markup to core.logAllRefUpdates doc
The "core.logAllRefUpdates" that used to be boolean has been
enhanced to take 'always' as well, to record ref updates to refs
other than the ones that are expected to be updated (i.e. branches,
remote-tracking branches and notes).
Will merge to 'master'.
* mm/merge-rename-delete-message (2017-01-30) 1 commit
- merge-recursive: make "CONFLICT (rename/delete)" message show both paths
* rs/object-id (2017-01-30) 3 commits
(merged to 'next' on 2017-01-31 at c442e4780c)
+ checkout: convert post_checkout_hook() to struct object_id
+ use oidcpy() for copying hashes between instances of struct object_id
+ use oid_to_hex_r() for converting struct object_id hashes to hex strings
"uchar [40]" to "struct object_id" conversion continues.
Will merge to 'master'.
* rs/swap (2017-01-30) 5 commits
- graph: use SWAP macro
- diff: use SWAP macro
- use SWAP macro
- apply: use SWAP macro
- add SWAP macro
Code clean-up.
Will merge to 'next'.
* pl/complete-diff-submodule-diff (2017-01-30) 1 commit
(merged to 'next' on 2017-01-31 at 7e668d325c)
+ Completion: Add support for --submodule=diff
The command line completion (in contrib/) learned that
"git diff --submodule=" can take "diff" as a recently added option.
Will merge to 'master'.
* ps/urlmatch-wildcard (2017-02-01) 5 commits
- urlmatch: allow globbing for the URL host part
- urlmatch: include host in urlmatch ranking
- urlmatch: split host and port fields in `struct url_info`
- urlmatch: enable normalization of URLs with globs
- mailmap: add Patrick Steinhardt's work address
The <url> part in "http.<url>.<variable>" configuration variable
can now be spelled with '*' that serves as wildcard.
E.g. "http.https://*.example.com.proxy" can be used to specify the
proxy used for https://a.example.com, https://b.example.com, etc.,
i.e. any host in the example.com domain.
* sb/submodule-recursive-absorb (2017-01-26) 3 commits
(merged to 'next' on 2017-01-31 at 0a24cfd06b)
+ submodule absorbing: fix worktree/gitdir pointers recursively for non-moves
+ cache.h: expose the dying procedure for reading gitlinks
+ setup: add gentle version of resolve_git_dir
When a submodule "sub", which has another submodule "module" nested
within it, is "absorbed" into the top-level superproject, the inner
submodule "module" is left in a strange state.
Will merge to 'master'.
* sb/submodule-update-initial-runs-custom-script (2017-01-26) 1 commit
(merged to 'next' on 2017-01-31 at d794f894c6)
+ submodule update: run custom update script for initial populating as well
The user can specify a custom update method that is run when
"submodule update" updates an already checked out submodule. This
was ignored when checking the submodule out for the first time and
we instead always just checked out the commit that is bound to the
path in the superproject's index.
Will merge to 'master'.
* sf/putty-w-args (2017-02-01) 5 commits
- SQUASH???
- connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config
- git_connect(): factor out SSH variant handling
- connect: rename tortoiseplink and putty variables
- connect: handle putty/plink also in GIT_SSH_COMMAND
The command line options for ssh invocation needs to be tweaked for
some implementations of SSH (e.g. PuTTY plink wants "-P <port>"
while OpenSSH wants "-p <port>" to specify port to connect to), and
the variant was guessed when GIT_SSH environment variable is used
to specify it. Extend the guess to the command specified by the
newer GIT_SSH_COMMAND and also core.sshcommand configuration
variable, and give an escape hatch for users to deal with
misdetected cases.
Expecting a reroll of the last step to plug new memory leak.
cf. <xmqqpoj8z7su.fsf@gitster.mtv.corp.google.com>
* jk/describe-omit-some-refs (2017-01-23) 5 commits
(merged to 'next' on 2017-01-23 at f8a14b4996)
+ describe: teach describe negative pattern matches
+ describe: teach --match to accept multiple patterns
+ name-rev: add support to exclude refs by pattern match
+ name-rev: extend --refs to accept multiple patterns
+ doc: add documentation for OPT_STRING_LIST
"git describe" and "git name-rev" have been taught to take more
than one refname patterns to restrict the set of refs to base their
naming output on, and also learned to take negative patterns to
name refs not to be used for naming via their "--exclude" option.
Will cook in 'next'.
* sb/unpack-trees-super-prefix (2017-01-25) 4 commits
(merged to 'next' on 2017-01-31 at dabe6ca2b1)
+ unpack-trees: support super-prefix option
+ t1001: modernize style
+ t1000: modernize style
+ read-tree: use OPT_BOOL instead of OPT_SET_INT
"git read-tree" and its underlying unpack_trees() machinery learned
to report problematic paths prefixed with the --super-prefix option.
Will merge to 'master'.
* sb/submodule-doc (2017-01-12) 3 commits
- submodules: add a background story
- submodule update documentation: don't repeat ourselves
- submodule documentation: add options to the subcommand
Needs review.
* bw/attr (2017-02-01) 27 commits
- attr: reformat git_attr_set_direction() function
- attr: push the bare repo check into read_attr()
- attr: store attribute stack in attr_check structure
- attr: tighten const correctness with git_attr and match_attr
- attr: remove maybe-real, maybe-macro from git_attr
- attr: eliminate global check_all_attr array
- attr: use hashmap for attribute dictionary
- attr: change validity check for attribute names to use positive logic
- attr: pass struct attr_check to collect_some_attrs
- attr: retire git_check_attrs() API
- attr: convert git_check_attrs() callers to use the new API
- attr: convert git_all_attrs() to use "struct attr_check"
- attr: (re)introduce git_check_attr() and struct attr_check
- attr: rename function and struct related to checking attributes
- attr.c: outline the future plans by heavily commenting
- Documentation: fix a typo
- attr.c: add push_stack() helper
- attr: support quoting pathname patterns in C style
- attr.c: plug small leak in parse_attr_line()
- attr.c: tighten constness around "git_attr" structure
- attr.c: simplify macroexpand_one()
- attr.c: mark where #if DEBUG ends more clearly
- attr.c: complete a sentence in a comment
- attr.c: explain the lack of attr-name syntax check in parse_attr()
- attr.c: update a stale comment on "struct match_attr"
- attr.c: use strchrnul() to scan for one line
- commit.c: use strchrnul() to scan for one line
The gitattributes machinery is being taught to work better in a
multi-threaded environment.
Expecting a reroll.
* vn/xdiff-func-context (2017-01-15) 1 commit
- xdiff -W: relax end-of-file function detection
"git diff -W" has been taught to handle the case where a new
function is added at the end of the file better.
Will hold.
An follow-up change to go back from the line that matches the
funcline to show comments before the function definition is still
being discussed.
* ls/filter-process-delayed (2017-01-08) 1 commit
. convert: add "status=delayed" to filter process protocol
Ejected, as does not build when merged to 'pu'.
* nd/worktree-move (2017-01-27) 7 commits
- fixup! worktree move: new command
- worktree remove: new command
- worktree move: refuse to move worktrees with submodules
- worktree move: accept destination as directory
- worktree move: new command
- worktree.c: add update_worktree_location()
- worktree.c: add validate_worktree()
"git worktree" learned move and remove subcommands.
Needs review.
* cc/split-index-config (2016-12-26) 21 commits
- Documentation/git-update-index: explain splitIndex.*
- Documentation/config: add splitIndex.sharedIndexExpire
- read-cache: use freshen_shared_index() in read_index_from()
- read-cache: refactor read_index_from()
- t1700: test shared index file expiration
- read-cache: unlink old sharedindex files
- config: add git_config_get_expiry() from gc.c
- read-cache: touch shared index files when used
- sha1_file: make check_and_freshen_file() non static
- Documentation/config: add splitIndex.maxPercentChange
- t1700: add tests for splitIndex.maxPercentChange
- read-cache: regenerate shared index if necessary
- config: add git_config_get_max_percent_split_change()
- Documentation/git-update-index: talk about core.splitIndex config var
- Documentation/config: add information for core.splitIndex
- t1700: add tests for core.splitIndex
- update-index: warn in case of split-index incoherency
- read-cache: add and then use tweak_split_index()
- split-index: add {add,remove}_split_index() functions
- config: add git_config_get_split_index()
- config: mark an error message up for translation
The experimental "split index" feature has gained a few
configuration variables to make it easier to use.
Waiting for review comments to be addressed.
cf. <20161226102222.17150-1-chriscool@tuxfamily.org>
cf. <a1a44640-ff6c-2294-72ac-46322eff8505@ramsayjones.plus.com>
* sb/push-make-submodule-check-the-default (2017-01-26) 2 commits
(merged to 'next' on 2017-01-26 at 5f4715cea6)
+ Revert "push: change submodule default to check when submodules exist"
(merged to 'next' on 2016-12-12 at 1863e05af5)
+ push: change submodule default to check when submodules exist
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Retracted.
* kn/ref-filter-branch-list (2017-01-31) 20 commits
(merged to 'next' on 2017-01-31 at e7592a5461)
+ branch: implement '--format' option
+ branch: use ref-filter printing APIs
+ branch, tag: use porcelain output
+ ref-filter: allow porcelain to translate messages in the output
+ ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames
+ ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
+ ref-filter: Do not abruptly die when using the 'lstrip=<N>' option
+ ref-filter: rename the 'strip' option to 'lstrip'
+ ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
+ ref-filter: introduce refname_atom_parser()
+ ref-filter: introduce refname_atom_parser_internal()
+ ref-filter: make "%(symref)" atom work with the ':short' modifier
+ ref-filter: add support for %(upstream:track,nobracket)
+ ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
+ ref-filter: introduce format_ref_array_item()
+ ref-filter: move get_head_description() from branch.c
+ ref-filter: modify "%(objectname:short)" to take length
+ ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
+ ref-filter: include reference to 'used_atom' within 'atom_value'
+ ref-filter: implement %(if), %(then), and %(else) atoms
The code to list branches in "git branch" has been consolidated
with the more generic ref-filter API.
Will cook in 'next'.
* jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
(merged to 'next' on 2016-12-05 at 0c77e39cd5)
+ setup_git_env: avoid blind fall-back to ".git"
Originally merged to 'next' on 2016-10-26
This is the endgame of the topic to avoid blindly falling back to
".git" when the setup sequence said we are _not_ in Git repository.
A corner case that happens to work right now may be broken by a
call to die("BUG").
Will cook in 'next'.
* pb/bisect (2016-10-18) 27 commits
- bisect--helper: remove the dequote in bisect_start()
- bisect--helper: retire `--bisect-auto-next` subcommand
- bisect--helper: retire `--bisect-autostart` subcommand
- bisect--helper: retire `--bisect-write` subcommand
- bisect--helper: `bisect_replay` shell function in C
- bisect--helper: `bisect_log` shell function in C
- bisect--helper: retire `--write-terms` subcommand
- bisect--helper: retire `--check-expected-revs` subcommand
- bisect--helper: `bisect_state` & `bisect_head` shell function in C
- bisect--helper: `bisect_autostart` shell function in C
- bisect--helper: retire `--next-all` subcommand
- bisect--helper: retire `--bisect-clean-state` subcommand
- bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
- t6030: no cleanup with bad merge base
- bisect--helper: `bisect_start` shell function partially in C
- bisect--helper: `get_terms` & `bisect_terms` shell function in C
- bisect--helper: `bisect_next_check` & bisect_voc shell function in C
- bisect--helper: `check_and_set_terms` shell function in C
- bisect--helper: `bisect_write` shell function in C
- bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
- bisect--helper: `bisect_reset` shell function in C
- wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
- t6030: explicitly test for bisection cleanup
- bisect--helper: `bisect_clean_state` shell function in C
- bisect--helper: `write_terms` shell function in C
- bisect: rewrite `check_term_format` shell function in C
- bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
Move more parts of "git bisect" to C.
Expecting a reroll.
cf. <CAFZEwPPXPPHi8KiEGS9ggzNHDCGhuqMgH9Z8-Pf9GLshg8+LPA@mail.gmail.com>
cf. <CAFZEwPM9RSTGN54dzaw9gO9iZmsYjJ_d1SjUD4EzSDDbmh-XuA@mail.gmail.com>
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2016-12-05 at 041946dae0)
+ merge: drop 'git merge <message> HEAD <commit>' syntax
Originally merged to 'next' on 2016-10-11
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
Will cook in 'next'.
--------------------------------------------------
[Discarded]
* jc/bundle (2016-03-03) 6 commits
. index-pack: --clone-bundle option
. Merge branch 'jc/index-pack' into jc/bundle
. bundle v3: the beginning
. bundle: keep a copy of bundle file name in the in-core bundle header
. bundle: plug resource leak
. bundle doc: 'verify' is not about verifying the bundle
The beginning of "split bundle", which could be one of the
ingredients to allow "git clone" traffic off of the core server
network to CDN.
While I think it would make it easier for people to experiment and
build on if the topic is merged to 'next', I am at the same time a
bit reluctant to merge an unproven new topic that introduces a new
file format, which we may end up having to support til the end of
time. It is likely that to support a "prime clone from CDN", it
would need a lot more than just "these are the heads and the pack
data is over there", so this may not be sufficient.
* jk/nofollow-attr-ignore (2016-11-02) 5 commits
. exclude: do not respect symlinks for in-tree .gitignore
. attr: do not respect symlinks for in-tree .gitattributes
. exclude: convert "check_index" into a flags field
. attr: convert "macro_ok" into a flags field
. add open_nofollow() helper
As we do not follow symbolic links when reading control files like
.gitignore and .gitattributes from the index, match the behaviour
and not follow symbolic links when reading them from the working
tree. This also tightens security a bit by not leaking contents of
an unrelated file in the error messages when it is pointed at by
one of these files that is a symbolic link.
Perhaps we want to cover .gitmodules too with the same mechanism?
^ permalink raw reply
* [ANNOUNCE] Git v2.11.1
From: Junio C Hamano @ 2017-02-02 23:05 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git v2.11.1 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.11.1'
tag and the 'maint' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
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.11.1 Release Notes
=========================
Fixes since v2.11
-----------------
* The default Travis-CI configuration specifies newer P4 and GitLFS.
* The character width table has been updated to match Unicode 9.0
* Update the isatty() emulation for Windows by updating the previous
hack that depended on internals of (older) MSVC runtime.
* "git rev-parse --symbolic" failed with a more recent notation like
"HEAD^-1" and "HEAD^!".
* An empty directory in a working tree that can simply be nuked used
to interfere while merging or cherry-picking a change to create a
submodule directory there, which has been fixed..
* The code in "git push" to compute if any commit being pushed in the
superproject binds a commit in a submodule that hasn't been pushed
out was overly inefficient, making it unusable even for a small
project that does not have any submodule but have a reasonable
number of refs.
* "git push --dry-run --recurse-submodule=on-demand" wasn't
"--dry-run" in the submodules.
* The output from "git worktree list" was made in readdir() order,
and was unstable.
* mergetool.<tool>.trustExitCode configuration variable did not apply
to built-in tools, but now it does.
* "git p4" LFS support was broken when LFS stores an empty blob.
* Fix a corner case in merge-recursive regression that crept in
during 2.10 development cycle.
* Update the error messages from the dumb-http client when it fails
to obtain loose objects; we used to give sensible error message
only upon 404 but we now forbid unexpected redirects that needs to
be reported with something sensible.
* When diff.renames configuration is on (and with Git 2.9 and later,
it is enabled by default, which made it worse), "git stash"
misbehaved if a file is removed and another file with a very
similar content is added.
* "git diff --no-index" did not take "--no-abbrev" option.
* "git difftool --dir-diff" had a minor regression when started from
a subdirectory, which has been fixed.
* "git commit --allow-empty --only" (no pathspec) with dirty index
ought to be an acceptable way to create a new commit that does not
change any paths, but it was forbidden, perhaps because nobody
needed it so far.
* A pathname that begins with "//" or "\\" on Windows is special but
path normalization logic was unaware of it.
* "git pull --rebase", when there is no new commits on our side since
we forked from the upstream, should be able to fast-forward without
invoking "git rebase", but it didn't.
* The way to specify hotkeys to "xxdiff" that is used by "git
mergetool" has been modernized to match recent versions of xxdiff.
* Unlike "git am --abort", "git cherry-pick --abort" moved HEAD back
to where cherry-pick started while picking multiple changes, when
the cherry-pick stopped to ask for help from the user, and the user
did "git reset --hard" to a different commit in order to re-attempt
the operation.
* Code cleanup in shallow boundary computation.
* A recent update to receive-pack to make it easier to drop garbage
objects made it clear that GIT_ALTERNATE_OBJECT_DIRECTORIES cannot
have a pathname with a colon in it (no surprise!), and this in turn
made it impossible to push into a repository at such a path. This
has been fixed by introducing a quoting mechanism used when
appending such a path to the colon-separated list.
* The function usage_msg_opt() has been updated to say "fatal:"
before the custom message programs give, when they want to die
with a message about wrong command line options followed by the
standard usage string.
* "git index-pack --stdin" needs an access to an existing repository,
but "git index-pack file.pack" to generate an .idx file that
corresponds to a packfile does not.
* Fix for NDEBUG builds.
* A lazy "git push" without refspec did not internally use a fully
specified refspec to perform 'current', 'simple', or 'upstream'
push, causing unnecessary "ambiguous ref" errors.
* "git p4" misbehaved when swapping a directory and a symbolic link.
* Even though an fix was attempted in Git 2.9.3 days, but running
"git difftool --dir-diff" from a subdirectory never worked. This
has been fixed.
* "git p4" that tracks multile p4 paths imported a single changelist
that touches files in these multiple paths as one commit, followed
by many empty commits. This has been fixed.
* A potential but unlikely buffer overflow in Windows port has been
fixed.
* When the http server gives an incomplete response to a smart-http
rpc call, it could lead to client waiting for a full response that
will never come. Teach the client side to notice this condition
and abort the transfer.
* Some platforms no longer understand "latin-1" that is still seen in
the wild in e-mail headers; replace them with "iso-8859-1" that is
more widely known when conversion fails from/to it.
* Update the procedure to generate "tags" for developer support.
* Update the definition of the MacOSX test environment used by
TravisCI.
* A few git-svn updates.
* Compression setting for producing packfiles were spread across
three codepaths, one of which did not honor any configuration.
Unify these so that all of them honor core.compression and
pack.compression variables the same way.
* "git fast-import" sometimes mishandled while rebalancing notes
tree, which has been fixed.
* Recent update to the default abbreviation length that auto-scales
lacked documentation update, which has been corrected.
* Leakage of lockfiles in the config subsystem has been fixed.
* It is natural that "git gc --auto" may not attempt to pack
everything into a single pack, and there is no point in warning
when the user has configured the system to use the pack bitmap,
leading to disabling further "gc".
* "git archive" did not read the standard configuration files, and
failed to notice a file that is marked as binary via the userdiff
driver configuration.
* "git blame --porcelain" misidentified the "previous" <commit, path>
pair (aka "source") when contents came from two or more files.
* "git rebase -i" with a recent update started showing an incorrect
count when squashing more than 10 commits.
* "git <cmd> @{push}" on a detached HEAD used to segfault; it has
been corrected to error out with a message.
* Tighten a test to avoid mistaking an extended ERE regexp engine as
a PRE regexp engine.
* Typing ^C to pager, which usually does not kill it, killed Git and
took the pager down as a collateral damage in certain process-tree
structure. This has been fixed.
Also contains various documentation updates and code clean-ups.
----------------------------------------------------------------
Changes since v2.11.0 are as follows:
Alan Davies (1):
mingw: fix colourization on Cygwin pseudo terminals
Andreas Krey (2):
commit: make --only --allow-empty work without paths
commit: remove 'Clever' message for --only --amend
Beat Bolli (6):
update_unicode.sh: move it into contrib/update-unicode
update_unicode.sh: remove an unnecessary subshell level
update_unicode.sh: pin the uniset repo to a known good commit
update_unicode.sh: automatically download newer definition files
update_unicode.sh: remove the plane filter
unicode_width.h: update the width tables to Unicode 9.0
Brandon Williams (2):
push: --dry-run updates submodules when --recurse-submodules=on-demand
push: fix --dry-run to not push submodules
Christian Couder (1):
Documentation/bisect: improve on (bad|new) and (good|bad)
David Aguilar (8):
mergetool: honor mergetool.$tool.trustExitCode for built-in tools
mergetools/vimdiff: trust Vim's exit code
difftool: fix dir-diff index creation when in a subdirectory
difftool: fix dir-diff index creation when in a subdirectory
difftool: sanitize $workdir as early as possible
difftool: chdir as early as possible
difftool: rename variables for consistency
mergetools: fix xxdiff hotkeys
David Turner (5):
submodules: allow empty working-tree dirs in merge/cherry-pick
remote-curl: don't hang when a server dies before any output
upload-pack: optionally allow fetching any sha1
auto gc: don't write bitmaps for incremental repacks
repack: die on incremental + write-bitmap-index
Dennis Kaarsemaker (1):
push: test pushing ambiguously named branches
Eric Wong (2):
git-svn: allow "0" in SVN path components
git-svn: document useLogAuthor and addAuthorFrom config keys
George Vanburgh (1):
git-p4: fix multi-path changelist empty commits
Heiko Voigt (4):
serialize collection of changed submodules
serialize collection of refs that contain submodule changes
batch check whether submodule needs pushing into one call
submodule_needs_pushing(): explain the behaviour when we cannot answer
Jack Bates (1):
diff: handle --no-abbrev in no-index case
Jeff Hostetler (1):
mingw: replace isatty() hack
Jeff King (32):
rev-parse: fix parent shorthands with --symbolic
t7610: clean up foo.XXXXXX tmpdir
http: simplify update_url_from_redirect
http: always update the base URL for redirects
remote-curl: rename shadowed options variable
http: make redirects more obvious
http: treat http-alternates like redirects
http-walker: complain about non-404 loose object errors
stash: prefer plumbing over git-diff
alternates: accept double-quoted paths
tmp-objdir: quote paths we add to alternates
Makefile: reformat FIND_SOURCE_FILES
Makefile: exclude test cruft from FIND_SOURCE_FILES
Makefile: match shell scripts in FIND_SOURCE_FILES
Makefile: exclude contrib from FIND_SOURCE_FILES
parse-options: print "fatal:" before usage_msg_opt()
README: replace gmane link with public-inbox
t5000: extract nongit function to test-lib-functions.sh
index-pack: complain when --stdin is used outside of a repo
t: use nongit() function where applicable
index-pack: skip collision check when not in repository
archive-zip: load userdiff config
rebase--interactive: count squash commits above 10 correctly
blame: fix alignment with --abbrev=40
blame: handle --no-abbrev
blame: output porcelain "previous" header for each file
git_exec_path: do not return the result of getenv()
execv_dashed_external: use child_process struct
execv_dashed_external: stop exiting with negative code
execv_dashed_external: wait for child on signal death
t7810: avoid assumption about invalid regex syntax
CodingGuidelines: clarify multi-line brace style
Johannes Schindelin (6):
cherry-pick: demonstrate a segmentation fault
merge-recursive: handle NULL in add_cacheinfo() correctly
mingw: intercept isatty() to handle /dev/null as Git expects it
mingw: adjust is_console() to work with stdin
git_exec_path: avoid Coverity warning about unfree()d result
mingw: follow-up to "replace isatty() hack"
Johannes Sixt (3):
t5547-push-quarantine: run the path separator test on Windows, too
normalize_path_copy(): fix pushing to //server/share/dir on Windows
t5615-alternate-env: double-quotes in file names do not work on Windows
Jonathan Tan (1):
fetch: do not redundantly calculate tag refmap
Junio C Hamano (11):
utf8: refactor code to decide fallback encoding
utf8: accept "latin-1" as ISO-8859-1
push: do not use potentially ambiguous default refspec
compression: unify pack.compression configuration parsing
pull: fast-forward "pull --rebase=true"
preparing for 2.10.3
Revert "sequencer: remove useless get_dir() function"
config.abbrev: document the new default that auto-scales
Almost ready for 2.11.1
Ready for 2.11.1
Git 2.11.1
Kristoffer Haugsbakk (4):
doc: add articles (grammar)
doc: add verb in front of command to run
doc: make the intent of sentence clearer
doc: omit needless "for"
Kyle J. McKay (1):
mailinfo.c: move side-effects outside of assert
Kyle Meyer (1):
branch_get_push: do not segfault when HEAD is detached
Lars Schneider (6):
travis-ci: update P4 to 16.2 and GitLFS to 1.5.2 in Linux build
git-p4: fix empty file processing for large file system backend GitLFS
t0021: minor filter process test cleanup
docs: warn about possible '=' in clean/smudge filter process values
t0021: fix flaky test
travis-ci: fix Perforce install on macOS
Luis Ressel (1):
date-formats.txt: Typo fix
Luke Diamand (1):
git-p4: avoid crash adding symlinked directory
Matt McCutchen (2):
doc: mention transfer data leaks in more places
git-gc.txt: expand discussion of races with other processes
Max Kirillov (1):
mingw: consider that UNICODE_STRING::Length counts bytes
Mike Hommey (1):
fast-import: properly fanout notes when tree is imported
Nguyễn Thái Ngọc Duy (13):
worktree.c: zero new 'struct worktree' on allocation
worktree: reorder an if statement
get_worktrees() must return main worktree as first item even on error
worktree.c: get_worktrees() takes a new flag argument
worktree list: keep the list sorted
merge-recursive.c: use string_list_sort instead of qsort
shallow.c: rename fields in paint_info to better express their purposes
shallow.c: stop abusing COMMIT_SLAB_SIZE for paint_info's memory pools
shallow.c: make paint_alloc slightly more robust
shallow.c: remove useless code
config.c: handle error case for fstat() calls
config.c: rename label unlock_and_out
config.c: handle lock file in error case in git_config_rename_...
Rasmus Villemoes (2):
shallow.c: avoid theoretical pointer wrap-around
shallow.c: bit manipulation tweaks
Stefan Beller (7):
unpack-trees: fix grammar for untracked files in directories
t3600: remove useless redirect
t3600: slightly modernize style
cache.h: document index_name_pos
cache.h: document remove_index_entry_at
cache.h: document add_[file_]to_index
documentation: retire unfinished documentation
Stephan Beyer (5):
am: fix filename in safe_to_abort() error message
am: change safe_to_abort()'s not rewinding error into a warning
t3510: test that cherry-pick --abort does not unsafely change HEAD
sequencer: make sequencer abort safer
sequencer: remove useless get_dir() function
Torsten Bögershausen (1):
convert: git cherry-pick -Xrenormalize did not work
Wolfram Sang (1):
request-pull: drop old USAGE stuff
^ permalink raw reply
* Re: git-scm.com status report
From: Samuel Lijin @ 2017-02-02 22:51 UTC (permalink / raw)
To: pedro rijo, j; +Cc: Eric Wong, git@vger.kernel.org, Jeff King
In-Reply-To: <16F9F83D-5A7F-4059-9A27-DB25A8FB1E99@gmail.com>
For anyone interested, this thread is on the HN front page right now[0].
There's one suggestion in particular that stands out to me - shifting
to Digital Ocean[1], which for $240/mo offers wayyyy more than what it
sounds like the current Heroku costs are.
[0] https://news.ycombinator.com/item?id=13554065
[1] https://news.ycombinator.com/item?id=13554632
On Thu, Feb 2, 2017 at 4:01 PM, pedro rijo <pedrorijo91@gmail.com> wrote:
> Hey,
>
> While I’m not experienced with Rails apps, I would like to give my
> contribution to the Git project. I could help doing some kind of triage,
> removing abusing PRs/issues (like
> https://github.com/git/git-scm.com/pull/557), looking for typos and other
> tasks that wouldn’t require a lot of RoR knowledge to get start. Also,
> completely free and available to start digging into the RoR stuff of course!
>
> If you are interested, just let me know :)
>
> Thanks,
> Pedro Rijo
^ permalink raw reply
* [PATCH v2] git-prompt.sh: add submodule indicator
From: Benjamin Fuchs @ 2017-02-02 22:51 UTC (permalink / raw)
To: git; +Cc: szeder.dev, sbeller, gitster, Benjamin Fuchs
In-Reply-To: <1486075892-20676-1-git-send-email-email@benjaminfuchs.de>
I expirienced that working with submodules can be confusing. A submodule can be
anywhere in your parent git repository. While walking through the parent
repository it would be good to have a reminder to know when you entered a
submodule.
This new indicator will show if you are in a submodule. The new prompt will look
like this: (sub:master). If the currently checked out submodule commit does not
match the SHA-1 found in the index of the containing repository a "+" will be
prepended (+sub:master). Adding a new optional env variable for the new feature.
Signed-off-by: Benjamin Fuchs <email@benjaminfuchs.de>
---
contrib/completion/git-prompt.sh | 40 ++++++++++++++++++++++++++-
t/t9903-bash-prompt.sh | 59 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 98 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 97eacd7..9a0c4af 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -93,6 +93,13 @@
# directory is set up to be ignored by git, then set
# GIT_PS1_HIDE_IF_PWD_IGNORED to a nonempty value. Override this on the
# repository level by setting bash.hideIfPwdIgnored to "false".
+#
+# If you would like __git_ps1 to indicate that you are in a submodule,
+# set GIT_PS1_SHOWSUBMODULE to a nonempty value. In this case the name
+# of the submodule will be prepended to the branch name (e.g. module:master).
+# If you set GIT_PS1_SHOWDIRTYSTATE to a nonempty value, the name will be
+# prepended by "+" if the currently checked out submodule commit does not
+# match the SHA-1 found in the index of the containing repository.
# check whether printf supports -v
__git_printf_supports_v=
@@ -284,6 +291,32 @@ __git_eread ()
test -r "$f" && read "$@" <"$f"
}
+# __git_ps1_submodule
+# Requires the git dir set in $g by the caller.
+# Returns the name of the submodule in $sub if we are currently inside one.
+# The name will be prepended by "+" if the currently checked out submodule commit
+# does not match the SHA-1 found in the index of the containing repository.
+# NOTE: git_dir looks like in a ...
+# - submodule: "GIT_PARENT/.git/modules/PATH_TO_SUBMODULE"
+# - parent: "GIT_PARENT/.git" (exception "." in .git)
+__git_ps1_submodule ()
+{
+ local git_dir="$g"
+ local submodule_name="$(basename "$git_dir")"
+ if [ "$submodule_name" != ".git" ] && [ "$submodule_name" != "." ]; then
+ local status=""
+ if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ] &&
+ [ "$(git config --bool bash.showDirtyState)" != "false" ]
+ then
+ local parent_top="${git_dir%.git*}"
+ local submodule_top="${git_dir#*modules/}"
+ git -C "$parent_top" diff --no-ext-diff --ignore-submodules=dirty --quiet -- "$submodule_top" 2>/dev/null || status="+"
+ fi
+
+ sub="$status$submodule_name:"
+ fi
+}
+
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
# when called from PS1 using command substitution
# in this mode it prints text to add to bash PS1 prompt (includes branch name)
@@ -513,8 +546,13 @@ __git_ps1 ()
b="\${__git_ps1_branch_name}"
fi
+ local sub=""
+ if [ -n "${GIT_PS1_SHOWSUBMODULE-}" ]; then
+ __git_ps1_submodule
+ fi
+
local f="$w$i$s$u"
- local gitstring="$c$b${f:+$z$f}$r$p"
+ local gitstring="$c$sub$b${f:+$z$f}$r$p"
if [ $pcmode = yes ]; then
if [ "${__git_printf_supports_v-}" != yes ]; then
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 97c9b32..ac82c99 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -16,9 +16,22 @@ c_lblue='\\[\\e[1;34m\\]'
c_clear='\\[\\e[0m\\]'
test_expect_success 'setup for prompt tests' '
+ mkdir .subrepo &&
+ (cd .subrepo &&
+ git init &&
+ echo 1 >file &&
+ git add file &&
+ git commit -m initial &&
+ git checkout -b dirty &&
+ echo 2 >file &&
+ git commit -m "dirty branch" file
+ ) &&
git init otherrepo &&
echo 1 >file &&
git add file &&
+ git submodule add ./.subrepo sub &&
+ git -C sub checkout master &&
+ git add sub &&
test_tick &&
git commit -m initial &&
git tag -a -m msg1 t1 &&
@@ -755,4 +768,50 @@ test_expect_success 'prompt - hide if pwd ignored - inside gitdir (stderr)' '
test_cmp expected "$actual"
'
+test_expect_success 'prompt - submodule indicator' '
+ printf " (sub:master)" >expected &&
+ (
+ cd sub &&
+ GIT_PS1_SHOWSUBMODULE=y &&
+ __git_ps1 >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success 'prompt - submodule indicator - disabled' '
+ printf " (master)" >expected &&
+ (
+ cd sub &&
+ GIT_PS1_SHOWSUBMODULE= &&
+ __git_ps1 >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success 'prompt - submodule indicator - dirty status indicator' '
+ printf " (+sub:dirty)" >expected &&
+ git -C sub checkout dirty &&
+ test_when_finished "git -C sub checkout master" &&
+ (
+ cd sub &&
+ GIT_PS1_SHOWSUBMODULE=y &&
+ GIT_PS1_SHOWDIRTYSTATE=y &&
+ __git_ps1 >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success 'prompt - submodule indicator - dirty status indicator disabled' '
+ printf " (sub:dirty)" >expected &&
+ git -C sub checkout dirty &&
+ test_when_finished "git -C sub checkout master" &&
+ (
+ cd sub &&
+ GIT_PS1_SHOWSUBMODULE=y &&
+ GIT_PS1_SHOWDIRTYSTATE= &&
+ __git_ps1 >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
test_done
--
2.7.4
^ permalink raw reply related
* [PATCH v2] git-prompt.sh: add submodule indicator
From: Benjamin Fuchs @ 2017-02-02 22:51 UTC (permalink / raw)
To: git; +Cc: szeder.dev, sbeller, gitster, Benjamin Fuchs
Hi everyone again,
I guess this time I'm rerolling my patch the right way.
Thanks again Gábor for your feedback.
And thanks to Junio for being patient and explaining the reroll workflow
Greeting,
Benjamin
Benjamin Fuchs (1):
git-prompt.sh: add submodule indicator
contrib/completion/git-prompt.sh | 40 ++++++++++++++++++++++++++-
t/t9903-bash-prompt.sh | 59 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 98 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH] ls-remote: add "--diff" option to show only refs that differ
From: Linus Torvalds @ 2017-02-02 21:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <xmqqfujws3pl.fsf@gitster.mtv.corp.google.com>
On Thu, Feb 2, 2017 at 1:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Another case I can think of that "--diff" would help is when you are
> inspecting your own mirror (but that can be seen as a special case
> of the "they have copies of yours plus their own", if you think of
> your mirror as "them" and the difference is "being stale").
Yeah, that's actually what I did for some testing (not having stale
branches, but just to check the expected differences for my upstream
kernel repo with my local pulls that I haven't pushed out yet).
The actual real use-case is something that only happens for me only
very occasionally. I end up sending out "did you forget to push"
emails perhaps a couple of times every release, but every time I do I
will have gone and done a ls-remote on their repo..
Linus
^ permalink raw reply
* Re: [PATCH] ls-remote: add "--diff" option to show only refs that differ
From: Junio C Hamano @ 2017-02-02 21:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <CA+55aFw14UXMa6OJ6YLHjy3tzOD+VSNytw6kMpaxFEfyuO2hAw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I basically don't see downstream contributor doing ls-remote, it's a
> upstream maintainer command.
>
> But that may be a lack of imagination on my part.
I actually share that perception. For the "downstream wonders about
the state of the origin" usecase, I would rather recommend "fetch",
either without "-n" (when the downstream does not value the current
state of refs/remotes/*) or with "-n" (when it does for whatever
reason).
>> When one contributor asks you to pull refs/heads/master you want to
>> go and see if it is different from refs/heads/master you have?
>
> No. What happens is that people ask me to do something like
>
> git pull ..some-target.. tags/for-linus-3
>
> and the pull fails because there is no such tag. That's when I go "ok,
> they screwed up, let's see what they *meant* for me to pull", and I go
> "git ls-remote".
In that context, I fully agree that "--diff --tags" would help. The
copies of your tags they have there would overwhelm what you are
really looking for in the output from the command.
And if they asked you to pull "for-linus-3" branch, which is buried
in many other branches (perhaps their publishing repository they ask
you to pull from is also serving as their back-up place, and the
local branches they use before coming up with something pull-able
are all there), then "--diff --refs" would still help by culling
tags that originated from you.
> I agree that it's a specialized case, but I also think it's the _main_
> case for ls-remote in the first place (apart from some scripting to
> check for updates or whatever).
>
> But maybe more people use ls-remote than I think they do (and in
> different ways than what I envision).
You and I are not the only folks in the world, but I agree with you
in thinking that "ls-remote" is not something you would use on
'origin' as a downstream contributor or a consumer.
Another case I can think of that "--diff" would help is when you are
inspecting your own mirror (but that can be seen as a special case
of the "they have copies of yours plus their own", if you think of
your mirror as "them" and the difference is "being stale").
^ permalink raw reply
* Re: [PATCH] ls-remote: add "--diff" option to show only refs that differ
From: Linus Torvalds @ 2017-02-02 20:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <xmqqshnws6ma.fsf@gitster.mtv.corp.google.com>
On Thu, Feb 2, 2017 at 12:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Most downstream folks seem to care about refs/remotes/origin/$branch
> and I think in that context "git ls-remote --diff [origin]" that
> compares their refs/heads/* and refs/remotes/origin/* would make
> sense.
Hmm. Maybe. The main target for noise reduction for me was actually
all the shared tags.
Which doesn't have that issue.
Also, I've never ever used "git ls-remote" on origin. Do people
actually do that? Why would a regular user ever use ls-remote in the
first place?
The only reason I've ever had for using ls-remote is exactly because
the remote is somehow "odd", and the _normal_ flow didn't work, so you
want to start investigating. So by definition (at least for me),
ls-remote is not part of a good normal flow.
So I kind of see where you are coming from, but I don't really see
that as being a normal workflow for me - or really anybody.
What I think *your* use case is would be more for a workflow along the lines of
# update the remote data
git fetch [origin]
# have some way to just see what branches are not the same
git status --all
or something ("git status" already talks about the status of the
current branch vs the origin branch).
> Your has_ref_locally() seems to return true by comparing
> their value with the value of the local ref without any the fetch
> refspec mapping.
Right. Because I see the use of "ls-remote" being mostly for
maintainer pulls, and the "origin" in many ways would be the other way
around (and you wouldn't even know what the name of said origin would
be locally).
I basically don't see downstream contributor doing ls-remote, it's a
upstream maintainer command.
But that may be a lack of imagination on my part.
> When one contributor asks you to pull refs/heads/master you want to
> go and see if it is different from refs/heads/master you have?
No. What happens is that people ask me to do something like
git pull ..some-target.. tags/for-linus-3
and the pull fails because there is no such tag. That's when I go "ok,
they screwed up, let's see what they *meant* for me to pull", and I go
"git ls-remote".
In other words, I don't see anybody ever using git ls-remote if they
already know what the remote is. That's why I don't see "origin" to be
an issue - origin is by definition somethinig you trust, and you just
fetch and pull from.
So the only reason I've ever had for using ls-remote is literally "ok,
what the hell is going on at that remote repo".
And then it is generally a bare repository, and it generally does
*not* have remote branches in it at all. But it *does* generally end
up having all the basic branches and tags (not always, but it's very
common).
Which is why I as a maintainer then want to just weed out anything
that is already my usual branches that everybody downstream already
has.
I agree that it's a specialized case, but I also think it's the _main_
case for ls-remote in the first place (apart from some scripting to
check for updates or whatever).
But maybe more people use ls-remote than I think they do (and in
different ways than what I envision).
Linus
^ permalink raw reply
* Re: [PATCH 00/11] nd/worktree-move update
From: Junio C Hamano @ 2017-02-02 20:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Duy Nguyen, Git Mailing List
In-Reply-To: <alpine.DEB.2.20.1702021330040.3496@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Also, the more important reply was Peff's reply that suggested that the
> proposed fix was incomplete, as it misses --unpack-unreachable:
> https://public-inbox.org/git/20160601160143.GA9219@sigill.intra.peff.net/
While I think that --unpack-unreachable thing is a symptom of the
basic approach of patching things up at the wrong level, if you are
hinting that fix to the issue that gc does not pay attention to
various anchoring point in other worktrees is more important than
adding new commands to "worktree", I fully agree with that.
We have a basic structure of "worktree" working well enough to allow
adventurous folks to experiment (there is a reason why we keep
calling it experimental). mv and other additions are primarily to
make things _easier_ to use, but we shouldn't be encouraging its use
to general public by making it easier for them to hurt themselves,
if we know there still are sharp edges.
Thanks for bringing it up.
^ permalink raw reply
* Re: [PATCH] ls-remote: add "--diff" option to show only refs that differ
From: Junio C Hamano @ 2017-02-02 20:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.20.1702021143470.21619@i7.lan>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> My main use of "git ls-remote" tends to be to check what the other end
> has when some pull request goes wrong (they forgot to push, or they used
> the wrong ref name or whatever), and it ends up being hard to see all
> the relevant data from the noise of people just having the same basic
> tags etc from upstream.
>
> So this adds a "--diff" option that shows only the refs that are
> different from the local repository. So when somebody asks me to pull,
> I can now just trivially look at what they have that isn't already my
> basic branches and tags.
Most downstream folks seem to care about refs/remotes/origin/$branch
and I think in that context "git ls-remote --diff [origin]" that
compares their refs/heads/* and refs/remotes/origin/* would make
sense. Your has_ref_locally() seems to return true by comparing
their value with the value of the local ref without any the fetch
refspec mapping.
When one contributor asks you to pull refs/heads/master you want to
go and see if it is different from refs/heads/master you have?
> Comments?
>
> +static int has_ref_locally(const struct ref *ref)
> +{
> + unsigned char sha1[20];
> +
> + if (!resolve_ref_unsafe(ref->name, RESOLVE_REF_READING, sha1, NULL))
> + return 0;
> +
> + return !hashcmp(ref->old_oid.hash, sha1);
> +}
> +
> @@ -105,6 +121,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
> continue;
> if (!tail_match(pattern, ref->name))
> continue;
> + if (diff && has_ref_locally(ref))
> + continue;
> if (show_symref_target && ref->symref)
> printf("ref: %s\t%s\n", ref->symref, ref->name);
> printf("%s\t%s\n", oid_to_hex(&ref->old_oid), ref->name);
^ permalink raw reply
* [PATCH] ls-remote: add "--diff" option to show only refs that differ
From: Linus Torvalds @ 2017-02-02 19:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 2 Feb 2017 11:37:49 -0800
Subject: [PATCH] ls-remote: add "--diff" option to show only refs that differ
My main use of "git ls-remote" tends to be to check what the other end
has when some pull request goes wrong (they forgot to push, or they used
the wrong ref name or whatever), and it ends up being hard to see all
the relevant data from the noise of people just having the same basic
tags etc from upstream.
So this adds a "--diff" option that shows only the refs that are
different from the local repository. So when somebody asks me to pull,
I can now just trivially look at what they have that isn't already my
basic branches and tags.
Note that "--diff" implies "--refs" (ie it also disables showing peeled
tags).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
This is not a big deal, but maybe others have the same issues I've had.
And maybe nobody else ever uses "git ls-remote". I dunno.
Also, I considered adding this feature as a more generic flag to
"check_ref_type()" (ie add a REF_NONLOCAL option to complete the existing
REF_NORMAL/REF_HEAD/etc flags), but that would have been a more involved
patch and I'm not convinced it makes much sense for any other use, so I
made it a specific local hack to ls-remote instead.
Comments?
builtin/ls-remote.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index 66cdd45cc..23469c3a6 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -2,6 +2,7 @@
#include "cache.h"
#include "transport.h"
#include "remote.h"
+#include "refs.h"
static const char * const ls_remote_usage[] = {
N_("git ls-remote [--heads] [--tags] [--refs] [--upload-pack=<exec>]\n"
@@ -31,6 +32,16 @@ static int tail_match(const char **pattern, const char *path)
return 0;
}
+static int has_ref_locally(const struct ref *ref)
+{
+ unsigned char sha1[20];
+
+ if (!resolve_ref_unsafe(ref->name, RESOLVE_REF_READING, sha1, NULL))
+ return 0;
+
+ return !hashcmp(ref->old_oid.hash, sha1);
+}
+
int cmd_ls_remote(int argc, const char **argv, const char *prefix)
{
const char *dest = NULL;
@@ -39,6 +50,7 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
int quiet = 0;
int status = 0;
int show_symref_target = 0;
+ int diff = 0;
const char *uploadpack = NULL;
const char **pattern = NULL;
@@ -62,6 +74,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
N_("exit with exit code 2 if no matching refs are found"), 2),
OPT_BOOL(0, "symref", &show_symref_target,
N_("show underlying ref in addition to the object pointed by it")),
+ OPT_BOOL(0, "diff", &diff,
+ N_("show only refs that differ from local refs")),
OPT_END()
};
@@ -98,6 +112,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
if (transport_disconnect(transport))
return 1;
+ if (diff)
+ flags |= REF_NORMAL;
if (!dest && !quiet)
fprintf(stderr, "From %s\n", *remote->url);
for ( ; ref; ref = ref->next) {
@@ -105,6 +121,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
continue;
if (!tail_match(pattern, ref->name))
continue;
+ if (diff && has_ref_locally(ref))
+ continue;
if (show_symref_target && ref->symref)
printf("ref: %s\t%s\n", ref->symref, ref->name);
printf("%s\t%s\n", oid_to_hex(&ref->old_oid), ref->name);
^ permalink raw reply related
* Re: [PATCH v3 00/27] Revamp the attribute system; another round
From: Junio C Hamano @ 2017-02-02 19:14 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, sbeller, pclouds
In-Reply-To: <20170128020207.179015-1-bmwill@google.com>
Brandon Williams <bmwill@google.com> writes:
> Per some of the discussion online and off I locally broke up up the question
> and answer and I wasn't very thrilled with the outcome for a number of reasons.
>
> 1. The API is more complex....
> 2. Performance hit....
> ...
> Given the above, v3 is a reroll of the same design as in v2. This is a good
> milestone in improving the attribute system as it achieves the goal of making
> the attribute subsystem thread-safe (ie multiple callers can be executing
> inside the attribute system at the same time) and will enable a future series
> to allow pathspec code to call into the attribute system.
>
> Most of the changes in this revision are cosmetic (variable renames, code
> movement, etc) but there was a memory leak that was also fixed.
I am OK with the patches presented in this round, but let me explain
why I still expect that we would eventually end up spliting the
question & answer into separate data structure before we can truly
go multi-threaded.
A typical application would do
for path taken from some set:
do_something(path)
and "do something with path" would be another helper function, which
may do
do_something(path):
ask 'text' attribute for the path
switch on the attribute and do different things
With the original API, the latter would statically allocate an array
of <question, answer> pairs, with an optimization to populate
<question> which is immutable (because the codepath is always and
only interested in 'text' attribute, and you need a hash lookup to
intern the string "text" which costs cycles) only once, and make a
call to git_check_attr() function with the "path". This obviously
will not work when two threads are calling this helper function, as
the threads both want their git_check_attr() to return their answers
to the array, but the <answer> part are shared between the threads.
A naive and inefficient way to split questions and answers is to
have two arrays, allocating the former statically (protected under a
mutex, of course) to avoid repeated cost of interning, while
allocating the latter (and some working area per invocation, like
the check_all_attr[]) dynamically and place it on stack or heap.
Because do_something() will be called number of times, the cost for
allocation and initialization of the <answer> part that is paid per
invocation will of course become very high.
We could in theory keep the original arrangement of having an
array of <question, answer> pairs and restructure the code to do:
prepare the <question, answer> array
for path taken from some set:
do_something(the array, path)
That way, do_something() do not have to keep allocating,
initializing and destroying the array.
But after looking at the current set of codepaths, before coming to
the conclusion that we need to split the static part that is
specific to the callsite for git_check_attr() and the dynamic part
that is specific to the <callsite, thread> pair, I noticed that
typically the callers that can prepare the array before going into
the loop (which will eventually be spread across multiple threads)
are many levels away in the callchain, and they are not even aware
of what attributes are going to be requested in the leaf level
helper functions. In other words, the approach to hoist "the
<question, answer> array" up in the callchain would not scale. A
caller that loops over paths in the index and check them out does
not want to know (and we do not want to tell it) what exact
attributes are involved in the decision convert_to_working_tree()
makes for each path, for example.
So how would we split questions and answers in a way that is not
naive and inefficient?
I envision that we would allow the attribute subsystem to keep track
of the dynamic part, which will receive the answers, holds working
area like check_all_attr[], and has the equivalent to the "attr
stack", indexed by <thread-id, callsite> pair (and the
identification of "callsite" can be done by using the address of the
static part, i.e. the array of questions that we initialize just
once when interning the list of attribute names for the first time).
The API to prepare and ask for attributes may look like:
static struct attr_static_part Q;
struct attr_dynamic_part *D;
attr_check_init(&Q, "text", ...);
D = git_attr_check(&Q, path);
where Q contains an array of interned attributes (i.e. questions)
and other immutable things that is unique to this callsite, but can
be shared across multiple threads asking the same question from
here. As an internal implementation detail, it probably will have a
mutex to make sure that init will run only once.
Then the implementation of git_attr_check(&Q, path) would be:
- see if there is already the "dynaic part" allocated for the
current thread asking the question Q. If there is not,
allocate one and remember it, so that it can be reused in
later calls by the same thread; if there is, use that existing
one.
- reinitialize the "dynamic part" as needed, e.g. clear the
equivalent to check_all_attr[], adjust the equivalent to
attr_stack for the current path, etc. Just like the current
code optimizes for the case where the entire program (a single
thread) will ask the same question for paths in traversal
order (i.e. falling in the same directory), this will optimize
for the access pattern where each thread asks the same
question for paths in its traversal order.
- do what the current collect_some_attrs() thing does.
And this hopefully won't be as costly as the naive and inefficient
one.
The reason why I was pushing hard to split the static part and the
dynamic part in our redesign of the API is primarily because I
didn't want to update the API callers twice. But I'd imagine that
your v3 (and your earlier "do not discard attr stack, but keep them
around, holding their tips in a hashmap for quick reuse") would at
least lay the foundation for the eventual shape of the API, let's
bite the bullet and accept that we will need to update the callers
again anyway.
Thanks.
^ permalink raw reply
* How to use git show's "%<(<N>[,trunc|ltrunc|mtrunc])"?
From: Hilco Wijbenga @ 2017-02-02 17:51 UTC (permalink / raw)
To: Git Users
Hi all,
I'm trying to get the committer date printed in a custom fashion.
Using "%cI" gets me close:
$ git show --format="%cI | %an" master | head -n 1
2017-01-31T17:02:13-08:00 | Hilco Wijbenga
I would like to get rid of the "-08:00" bit at the end of the
timestamp. According to the "git show" manual I should be able to use
"%<(<N>[,trunc|ltrunc|mtrunc])" to drop that last part.
$ git show --format="%<(19,trunc)cI | %an" master | head -n 1
cI | Hilco Wijbenga
Mmm, it seems to be recognized as a valid "something" but it's not
working as I had expected. :-) I tried several other versions of this
but no luck. Clearly, I'm misunderstanding the format description. How
do I get "2017-01-31T17:02:13 | Hilco Wijbenga" to be output?
Cheers,
Hilco
^ permalink raw reply
* Re: [PATCH 4/7] completion: teach ls-remote to complete options
From: Junio C Hamano @ 2017-02-02 16:57 UTC (permalink / raw)
To: Cornelius Weig
Cc: SZEDER Gábor, bitte.keine.werbung.einwerfen, thomas.braun,
john, git
In-Reply-To: <603697da-c8e9-5644-e0f0-7ee265c069d8@tngtech.com>
Cornelius Weig <cornelius.weig@tngtech.com> writes:
> On 02/02/2017 02:40 AM, SZEDER Gábor wrote:
>>
>>> ls-remote needs to complete remote names and its own options.
>>
>> And refnames, too.
>
> Yes, right. However, do you think it is reasonable to complete remote
> refnames? I don't think so, because it would mean we would have to run
> ls-remote during completion -- and waiting for ls-remote could be quite
> lengthy.
... and by the time the completion script knew what they are, we
have all information necessary without actually having the user run
the command ;-) That does sound backwards.
I am however not sure what Szeder really meant by "refnames". For
example, you may want to see that this
$ git ls-remote origin mast<TAG>
peek into refs/remotes/origin/* and find those matching, i.e. most
likely "master", and that can be done without talking to the remote
side. It won't catch the case where the remote end added a new
branch that also match, e.g. "mastiff", and it will actively harm
the users by giving the impression that Git (collectively, even
though from technical point of view, what the completion script does
is not part of Git) told them that there is no such new branch they
need to worry about.
So probably even with the "peek local" optimization, I have a feeling
that completion of refnames may not be such a good idea.
^ permalink raw reply
* [PATCH] document behavior of empty color name
From: Jeff King @ 2017-02-02 12:42 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Junio C Hamano, git
In-Reply-To: <20170202091615.GA22337@ash>
On Thu, Feb 02, 2017 at 04:16:15PM +0700, Duy Nguyen wrote:
> > I hadn't heard anything back,
>
> Sorry I was accidentally busy during Luna new year holiday.
No problem. That sounds much more fun than working on Git. :)
> > - if (!len)
> > - return -1;
> > + if (!len) {
> > + dst[0] = '\0';
> > + return 0;
> > + }
> >
> > if (!strncasecmp(ptr, "reset", len)) {
> > xsnprintf(dst, end - dst, GIT_COLOR_RESET);
>
> I wonder if it makes more sense to do this in builtin/config.c. The
> "default value" business is strictly git-config command's. The parsing
> function does not need to know. Maybe something like this?
I don't think so. The default value is a git-config thing, but you would
want to be able to do the same thing in a config file. For example, to
disable coloring entirely for part of the diff, you could do:
[color "diff"]
meta = ""
> This is also a good opportunity to document this behavior in
> git-config.txt, I think.
Yeah. Maybe:
-- >8 --
Subject: [PATCH] document behavior of empty color name
Commit 55cccf4bb (color_parse_mem: allow empty color spec,
2017-02-01) clearly defined the behavior of an empty color
config variable. Let's document that, and give a hint about
why it might be useful.
It's important not to say that it makes the item uncolored,
because it doesn't. It just sets no attributes, which means
that any previous attributes continue to take effect.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/config.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 33a007b52..49b264566 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -170,6 +170,9 @@ The position of any attributes with respect to the colors
be turned off by prefixing them with `no` or `no-` (e.g., `noreverse`,
`no-ul`, etc).
+
+An empty color string produces no color effect at all. This can be used
+to avoid coloring specific elements without disabling color entirely.
++
For git's pre-defined color slots, the attributes are meant to be reset
at the beginning of each item in the colored output. So setting
`color.decorate.branch` to `black` will paint that branch name in a
--
2.11.0.948.gca97da533
^ permalink raw reply related
* Re: init --separate-git-dir does not set core.worktree
From: Kyle Meyer @ 2017-02-02 12:37 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List
In-Reply-To: <CACsJy8AZUBt76ZocS2JEr9FP_8Obv8L911AvZxE_sww3qXB7qw@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Thu, Feb 2, 2017 at 10:55 AM, Kyle Meyer <kyle@kyleam.com> wrote:
>>
>> As of 6311cfaf9 (init: do not set unnecessary core.worktree,
>> 2016-09-25), "git init --separate-git-dir" no longer sets core.worktree
>> (test below). Based on the commit message and the corresponding thread
>> [1], I don't think this change in behavior was intentional, but I wasn't
>> able to understand things well enough to attempt a patch.
>
> I'm missing some context. Why does --separate-git-dir have to set
> core.worktree? What fails for you exactly?
Sorry for not providing enough information. I haven't run into a
failure.
In Magit, we need to determine the top-level of the working tree from
COMMIT_EDITMSG. Right now that logic [*1*] looks something like this:
* COMMIT_EDITMSG in .git/modules/<module>/: set working tree to the
output of "git rev-parse --show-toplevel"
* COMMIT_EDITMSG in .git/worktrees/<wtree>/: set working tree to the
path in .git/worktrees/<wtree>/gitdir, minus the trailing "/.git"
* COMMIT_EDITMSG in .git: set working tree to the parent directory
This fails for a repo set up with --separate-git-dir [*2*], where the
last step will go out into an unrelated repo. If core.worktree was set
and "git rev-parse --show-toplevel" returned the working tree like it
did for submodules, things would work.
Of course, the issue above isn't a reason that --separate-git-dir should
set core.worktree, but the submodule behavior is why we were wondering
if it should. And so I was going to ask here whether core.worktree
should be set, but then I confused myself into thinking 6311cfaf9
unintentionally changed this behavior.
[*1*] This is done by magit-toplevel:
https://github.com/magit/magit/blob/e34f4e8eb00f292e8c475489fa7caa286857a421/lisp/magit-git.el#L400
[*2*] https://github.com/magit/magit/issues/2955
https://github.com/magit/magit/issues/2981
^ permalink raw reply
* Re: [PATCH 00/11] nd/worktree-move update
From: Johannes Schindelin @ 2017-02-02 12:33 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.DEB.2.20.1702021223320.3496@virtualbox>
Hi Duy,
On Thu, 2 Feb 2017, Johannes Schindelin wrote:
> Hi Duy,
>
> On Thu, 2 Feb 2017, Duy Nguyen wrote:
>
> > On Thu, Feb 2, 2017 at 5:37 PM, Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > On Thu, 2 Feb 2017, Duy Nguyen wrote:
> > >
> > >> You meant this one [1]? There is nothing substantial since then.
> > >>
> > >> [1] https://public-inbox.org/git/%3C20160601104519.16563-1-pclouds@gmail.com%3E/
> >
> > I could rebase and clean it up a bit if you need it, but I don't
> > think it'll end up in 'pu' or anywhere near since Junio wanted a
> > cleaner approach [1]. That means (as far as I can see) a lot more work
> > around refs store and backend area before it's ready to handle "get
> > refs from this worktree store" (or "get refs from every reachable
> > stores").
> >
> > [1] https://public-inbox.org/git/xmqqshwwzyee.fsf@gitster.mtv.corp.google.com/
Given that
https://public-inbox.org/git/xmqqy46ntrhk.fsf@gitster.mtv.corp.google.com/
seems to have expected something to happen within a reasonable time frame,
and that 8 months is substantially longer than a reasonable time frame, I
am not sure that that position can still be defended.
Also, the more important reply was Peff's reply that suggested that the
proposed fix was incomplete, as it misses --unpack-unreachable:
https://public-inbox.org/git/20160601160143.GA9219@sigill.intra.peff.net/
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH 00/11] nd/worktree-move update
From: Johannes Schindelin @ 2017-02-02 11:31 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CACsJy8CBG_a_nX_syXKrdG2-ren=NO9CNxe6tm94FGnEo1HZLQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]
Hi Duy,
On Thu, 2 Feb 2017, Duy Nguyen wrote:
> On Thu, Feb 2, 2017 at 5:37 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Thu, 2 Feb 2017, Duy Nguyen wrote:
> >
> >> On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin
> >> <Johannes.Schindelin@gmx.de> wrote:
> >> >
> >> > On Thu, 2 Feb 2017, Duy Nguyen wrote:
> >> >
> >> >> On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin
> >> >> <Johannes.Schindelin@gmx.de> wrote:
> >> >> >
> >> >> > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote:
> >> >> >
> >> >> >> This squashes two changes from Johannes and Ramsay: [...]
> >> >> >
> >> >> > Sorry, I lost track of the worktree discussions... Could you
> >> >> > remind me which patch is supposed to fix my continuous reflog
> >> >> > corruption?
> >> >>
> >> >> The corruption caused by git-gc? It's not fixed. All the changes
> >> >> in this series is shown here.
> >> >
> >> > Oh sorry, I meant to ask "and if it is not in this patch series,
> >> > would you mind pointing me at the patch series that has that fix?"
> >>
> >> You meant this one [1]? There is nothing substantial since then.
> >>
> >> [1] https://public-inbox.org/git/%3C20160601104519.16563-1-pclouds@gmail.com%3E/
> >
> > I guess I mean that.
> >
> > Given that this results in real data loss, it is surprising that this
> > has not made it even into `pu` yet!
>
> I could rebase and clean it up a bit if you need it, but I don't think
> it'll end up in 'pu' or anywhere near since Junio wanted a cleaner
> approach [1]. That means (as far as I can see) a lot more work around
> refs store and backend area before it's ready to handle "get refs from
> this worktree store" (or "get refs from every reachable stores").
>
> [1] https://public-inbox.org/git/xmqqshwwzyee.fsf@gitster.mtv.corp.google.com/
That is a big, big bummer.
We are talking about a data corrupting bug here, yes? It should be
possible to do that redesign work while having a small workaround in place
that unbreaks, say, me?
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH 00/11] nd/worktree-move update
From: Duy Nguyen @ 2017-02-02 11:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.DEB.2.20.1702021136210.3496@virtualbox>
On Thu, Feb 2, 2017 at 5:37 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Duy,
>
> On Thu, 2 Feb 2017, Duy Nguyen wrote:
>
>> On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> >
>> > On Thu, 2 Feb 2017, Duy Nguyen wrote:
>> >
>> >> On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin
>> >> <Johannes.Schindelin@gmx.de> wrote:
>> >> >
>> >> > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote:
>> >> >
>> >> >> This squashes two changes from Johannes and Ramsay: [...]
>> >> >
>> >> > Sorry, I lost track of the worktree discussions... Could you remind
>> >> > me which patch is supposed to fix my continuous reflog corruption?
>> >>
>> >> The corruption caused by git-gc? It's not fixed. All the changes in
>> >> this series is shown here.
>> >
>> > Oh sorry, I meant to ask "and if it is not in this patch series, would you
>> > mind pointing me at the patch series that has that fix?"
>>
>> You meant this one [1]? There is nothing substantial since then.
>>
>> [1] https://public-inbox.org/git/%3C20160601104519.16563-1-pclouds@gmail.com%3E/
>
> I guess I mean that.
>
> Given that this results in real data loss, it is surprising that this has
> not made it even into `pu` yet!
I could rebase and clean it up a bit if you need it, but I don't
think it'll end up in 'pu' or anywhere near since Junio wanted a
cleaner approach [1]. That means (as far as I can see) a lot more work
around refs store and backend area before it's ready to handle "get
refs from this worktree store" (or "get refs from every reachable
stores").
[1] https://public-inbox.org/git/xmqqshwwzyee.fsf@gitster.mtv.corp.google.com/
--
Duy
^ permalink raw reply
* Re: [PATCH v2 7/7] completion: recognize more long-options
From: Cornelius Weig @ 2017-02-02 10:40 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: j6t, Shawn Pearce, git
In-Reply-To: <CAM0VKjkAnsT_LE4OZRkLPuiEZW88P7_OBbOw0XovHhLYfBhbwg@mail.gmail.com>
On 02/02/2017 03:00 AM, SZEDER Gábor wrote:
>> Personally, I agree with you that
>>> Adding more long options that git commands learn along the way is
>>> always an improvement.
>> However, people may start complaining that their terminal becomes too
>> cluttered when doing a double-Tab. In my cover letter, I go to length
>> about this. My assumption was that all options that are mentioned in the
>> introduction of the command man-page should be important enough to have
>> them in the completion list.
>
> But that doesn't mean that the ones not mentioned in the synopsis
> section are not worth completing.
Absolutely. What I meant is that at least the options from the synopsis
should be contained in the set of completable options.
>> Btw, I haven't found that non-destructive options should not be eligible
>> for completion. To avoid confusion about this in the future, I suggest
>> to also change the documentation:
>>
>> index 933bb6e..96f1c7f 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -13,7 +13,7 @@
>> # *) git email aliases for git-send-email
>> # *) tree paths within 'ref:path/to/file' expressions
>> # *) file paths within current working directory and index
>> -# *) common --long-options
>> +# *) common non-destructive --long-options
>
> I don't mind such a change, but I don't think that list was ever meant
> to be comprehensive or decisive. It is definitely not the former, as
> it's missing several things that the completion script does support.
> OTOH, it talks about .git/remotes, which has been considered legacy
> for quite some years (though it's right, because the completion script
> still supports it).
Then let's not do that change, because for some commands destructive
long-options have been in the list of completed options for quite a
while. Given that, the above change of the documentation, might stir up
more confusion than it settles.
^ permalink raw reply
* Re: [PATCH 00/11] nd/worktree-move update
From: Johannes Schindelin @ 2017-02-02 10:37 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CACsJy8A-tuea7W+tj6rNddtM0j_374FODjQqKsT8eHfeZ0qDZg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]
Hi Duy,
On Thu, 2 Feb 2017, Duy Nguyen wrote:
> On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Thu, 2 Feb 2017, Duy Nguyen wrote:
> >
> >> On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin
> >> <Johannes.Schindelin@gmx.de> wrote:
> >> >
> >> > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote:
> >> >
> >> >> This squashes two changes from Johannes and Ramsay: [...]
> >> >
> >> > Sorry, I lost track of the worktree discussions... Could you remind
> >> > me which patch is supposed to fix my continuous reflog corruption?
> >>
> >> The corruption caused by git-gc? It's not fixed. All the changes in
> >> this series is shown here.
> >
> > Oh sorry, I meant to ask "and if it is not in this patch series, would you
> > mind pointing me at the patch series that has that fix?"
>
> You meant this one [1]? There is nothing substantial since then.
>
> [1] https://public-inbox.org/git/%3C20160601104519.16563-1-pclouds@gmail.com%3E/
I guess I mean that.
Given that this results in real data loss, it is surprising that this has
not made it even into `pu` yet!
Would you mind rebasing and re-submitting?
Thanks,
Johannes
^ permalink raw reply
* Re: [PATCH 00/11] nd/worktree-move update
From: Duy Nguyen @ 2017-02-02 9:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.DEB.2.20.1702021043110.3496@virtualbox>
On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Duy,
>
> On Thu, 2 Feb 2017, Duy Nguyen wrote:
>
>> On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > Hi Duy,
>> >
>> > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote:
>> >
>> >> This squashes two changes from Johannes and Ramsay: [...]
>> >
>> > Sorry, I lost track of the worktree discussions... Could you remind me
>> > which patch is supposed to fix my continuous reflog corruption?
>>
>> The corruption caused by git-gc? It's not fixed. All the changes in
>> this series is shown here.
>
> Oh sorry, I meant to ask "and if it is not in this patch series, would you
> mind pointing me at the patch series that has that fix?"
You meant this one [1]? There is nothing substantial since then.
[1] https://public-inbox.org/git/%3C20160601104519.16563-1-pclouds@gmail.com%3E/
--
Duy
^ permalink raw reply
* Re: [PATCH 00/11] nd/worktree-move update
From: Johannes Schindelin @ 2017-02-02 9:43 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CACsJy8B3bdokeYVt6aEyZVSzO50PiQRn+0sid9mSDTZ9q-mnww@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]
Hi Duy,
On Thu, 2 Feb 2017, Duy Nguyen wrote:
> On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Hi Duy,
> >
> > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote:
> >
> >> This squashes two changes from Johannes and Ramsay: [...]
> >
> > Sorry, I lost track of the worktree discussions... Could you remind me
> > which patch is supposed to fix my continuous reflog corruption?
>
> The corruption caused by git-gc? It's not fixed. All the changes in
> this series is shown here.
Oh sorry, I meant to ask "and if it is not in this patch series, would you
mind pointing me at the patch series that has that fix?"
Thanks,
Johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox