* Re: interaction between git-diff-index and git-apply
From: Junio C Hamano @ 2017-01-22 22:06 UTC (permalink / raw)
To: Ariel Davis; +Cc: git
In-Reply-To: <C45218A3-8A81-4307-AADB-FBA4F51EAC51@icloud.com>
Ariel Davis <ariel.z.davis@icloud.com> writes:
> I have noticed an interesting interaction between git-diff-index and git-apply.
> Essentially, it seems that if we start with a clean working tree, then
> git-apply a patch, then git-apply the reverse of that patch, git-diff-index
> still thinks files are modified. But then, if we git-status, git-diff-index
> seems to "realize" the files are actually not modified.
That is perfectly normal and you are making it too complex. You do
not need to involve "git apply" at all.
$ git init
$ echo hello >file && git add file && git commit -m initial
$ git diff-index HEAD
$ echo hello >file
$ git diff-index HEAD
:100644 100644 ce013625030ba8dba906f756967f9e9ca394464a 0000000000000000000000000000000000000000 M file
$ git update-index --refresh
$ git diff-index HEAD
$ exit
A few things about Git that are involved in the above are:
* There are plumbing commands that are geared more towards
scripting Git efficiently and there are end-user facing Porcelain
commands.
* Git uses cached "(l)stat" information to avoid having to inspect
the contents of the file all the time. The idea is that Git
remembers certain attributes (like size and last modified time)
of a file when the contents of the file and the blob object in
the index are the same (e.g. when you did "git add file" in the
above sequence), and it can tell a file was edited/modified if
these attributes are different from those recorded in the index
without comparing the contents of the file with the blob.
* The plumbing commands trust the cached "(l)stat" information for
efficiency and whoever uses the plumbing commands are responsible
for culling the false positives when cached "(l)stat" information
is used to see which paths are modified. They (typically these
are scripted commands) do so with "update-index --refresh".
* The Porcelain commands sacrifice the efficiency and internally do
an equivalent of "update-index --refresh" at the beginning to
hide the false positive.
After your reverse application of the patch with "git apply" (or the
second "echo hello" into the file in the above example), the
contents of the file is equivalent to what is in the index, but the
last modified timestamp (among others) is different because you
wrote into the file. If you do not do "update-index --refresh"
before running "diff-index" again, "diff-index" will notice and
report the fact that you touched that file. If you run "git status",
"git diff", etc., they internally do "update-index --refresh" and
then after that until you touch the file on the filesystem, the
cached "(l)stat" information will match and you will stop seeing the
false positive.
^ permalink raw reply
* Re: Does it make sense to show tips on blame?
From: Junio C Hamano @ 2017-01-22 22:25 UTC (permalink / raw)
To: Edmundo Carmona Antoranz; +Cc: Git List
In-Reply-To: <CAOc6etZ9QeJAf1CKh9Eraigwy45yR6eO-7Th+bZRnTa71BoPew@mail.gmail.com>
Edmundo Carmona Antoranz <eantoranz@gmail.com> writes:
> Output is like this (from README.txt, taken from difflame on git
> itself, sorry if it's too wide):
It is not just too wide but it is line-wrapped and cannot see what
you wanted to say out of it.
What does the word "tip" mean in this context? The word is often
used to mean the commits directly pointed at by branches (i.e. the
tip of history), but I do not think that is what you are interested
in showing in this butchered "diff" output.
> 2a113aee9b (Johan Herland 2009-12-07 12:27:24 +0100 2227)
> 405d7f4af fast-import: properly fanout notes when tree is imported
> +405d7f4af6 (Mike Hommey 2016-12-21 06:04:48 +0900 2228) if (!root->tree)
> +405d7f4af6 (Mike Hommey 2016-12-21 06:04:48 +0900 2229)
> load_tree(root);
> ...
Do you mean the one-line summary for the commit? The commits that
are shown will not be at the tip most of the time (the "+" ones may
be if you happen to be running "git show" on the tip of a branch,
but that is minority if you also want to do "git log -p"), so I am
not sure it makes sense to call them "tips" in the above output.
If I were doing the above, I would probably do them as footnotes to
keep the body of the patch text (slightly) more readable. E.g.
@@ -l,k +m,n @@
2a113aee9b
+405d7f4af6 if (!root-tree)
+405d7f4af6 load_tree(root)
...
#2a113aee9b "fast-import: Proper notes tree manipulation", 2009-12-07
#405d7f4af6 "fast-import: properly fanout notes when tree is imported", 2016-12-21
> The question is if you think it makes sense to add this option to
> git-blame itself.
>
> Something like:
> git blame --tips README.txt
I do not think I would use it personally, as it would make it hard
to pipe the output of "git blame" to less and then /search things,
as extra cruft added by the option will get in the way. IOW, I do
not think we want it for human-oriented output.
On the other hand, when output from "blame" is used by scripts (or
GUI frontends), having the one-line summary would be very useful.
But I think the authors of "blame" already thought about that
usecase and included the "summary" field in the "--porcelain" output
that are meant to be consumed by scripts, so...
^ permalink raw reply
* Re: [PATCH v2 3/4] show-ref: Optimize show_ref a bit
From: Junio C Hamano @ 2017-01-22 22:47 UTC (permalink / raw)
To: Vladimir Panteleev; +Cc: git
In-Reply-To: <20170121010821.25046-4-git@thecybershadow.net>
Vladimir Panteleev <git@thecybershadow.net> writes:
> The inner `if (verify)' check was not being used before the preceding
> commit, as show_ref was never being called from a code path where
> verify was non-zero.
>
> Adding a `!verify' check to the outer if skips an unnecessary string
> comparison when verify is non-zero, and show_ref is already called
> with a reference exactly matching pattern.
>
> Signed-off-by: Vladimir Panteleev <git@thecybershadow.net>
> ---
> builtin/show-ref.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/builtin/show-ref.c b/builtin/show-ref.c
> index bcdc1a95e..3cf344d47 100644
> --- a/builtin/show-ref.c
> +++ b/builtin/show-ref.c
> @@ -43,7 +43,7 @@ static int show_ref(const char *refname, const struct object_id *oid,
> if (!match)
> return 0;
> }
> - if (pattern) {
> + if (pattern && !verify) {
> int reflen = strlen(refname);
> const char **p = pattern, *m;
> while ((m = *p++) != NULL) {
> @@ -54,9 +54,6 @@ static int show_ref(const char *refname, const struct object_id *oid,
> continue;
> if (len == reflen)
> goto match;
> - /* "--verify" requires an exact match */
> - if (verify)
> - continue;
> if (refname[reflen - len - 1] == '/')
> goto match;
> }
Having to do this change probably is an indication that the division
of labour between show_ref() and show_one() up to this step needs to
be rethought.
Conceptually, "git show-ref" works in two ways:
* When in --verify mode, the end user gives which refnames to
consider showing.
* Otherwise the end user gives pattern and the command infers which
refnames to consider showing using the pattern.
And for the refnames that are considered for showing, we may do
various things, like -d to deref and --quiet to be silent. We want
this actual "output" step to be the same between two modes of
operation.
So a better division of labour would be:
* Make show_ref() about "using pattern, enumerate what refs to
show" and call show_one().
* Update show_one() and teach _it_ to handle quiet and deref_tags.
* From cmd_show_ref(), in --verify mode, make sure the ref exists
and call show_one(), because we do not do the "using pattern,
enumerate what refs to show" at all.
And from that point of view, I think 4/4 is going in the wrong
direction.
I also think that "git show-ref --verify HEAD" should work; it is OK
that the command accepts "--head" in that case, but when in --verify
mode, the end user gives which refnames to consider showing, and
HEAD given from the command line is a signal enough that that
psuedo-ref is what the end user wants to be shown. "--head" is
about not filtering in "enumerate the ones that match the given
patterns" mode, and it feels unnecessary to require it in "--verify"
mode.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 3/4] show-ref: Optimize show_ref a bit
From: Junio C Hamano @ 2017-01-22 22:55 UTC (permalink / raw)
To: Vladimir Panteleev; +Cc: git
In-Reply-To: <xmqqa8aivhik.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Having to do this change probably is an indication that the division
> of labour between show_ref() and show_one() up to this step needs to
> be rethought.
>
> Conceptually, "git show-ref" works in two ways:
>
> * When in --verify mode, the end user gives which refnames to
> consider showing.
>
> * Otherwise the end user gives pattern and the command infers which
> refnames to consider showing using the pattern.
>
> And for the refnames that are considered for showing, we may do
> various things, like -d to deref and --quiet to be silent. We want
> this actual "output" step to be the same between two modes of
> operation.
... also "error out if the named object did not exist" can be part
of this, which means ...
> So a better division of labour would be:
>
> * Make show_ref() about "using pattern, enumerate what refs to
> show" and call show_one().
>
> * Update show_one() and teach _it_ to handle quiet and deref_tags.
... "if (!has_sha1_file(oid->hash)) die()" in show_ref() would
probably want to be part of this update.
^ permalink raw reply
* [PATCH v2] travis-ci: fix Perforce install on macOS
From: Lars Schneider @ 2017-01-22 22:55 UTC (permalink / raw)
To: git; +Cc: gitster
The `perforce` and `perforce-server` package were moved from brew [1][2]
to cask [3]. Teach TravisCI the new location.
Perforce updates their binaries without version bumps. That made the
brew install (legitimately!) fail due to checksum mismatches. The
workaround is not necessary anymore as Cask [4] allows to disable the
checksum test for individual formulas.
[1] https://github.com/Homebrew/homebrew-binary/commit/1394e42de04d07445f82f9512627e864ff4ca4c6
[2] https://github.com/Homebrew/homebrew-binary/commit/f8da22d6b8dbcfcfdb2dfa9ac1a5e5d8e05aac2b
[3] https://github.com/caskroom/homebrew-cask/pull/29180
[4] https://caskroom.github.io/
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
---
Hi,
this small update removes one more unnecessary line and makes the
formula name lower case (no functional reason - just looks better ;-).
@Junio: Do you prefer such a v2 as "--in-reply-to" to v1 or as separate
thread? What eases your workflow?
Thanks,
Lars
Notes:
Base Commit: 787f75f056 (787f75f0567aa8c7347544c65e9d3bc6640a27d4)
Diff on Web: https://github.com/larsxschneider/git/commit/a8ec423355
Checkout: git fetch https://github.com/larsxschneider/git travisci/brew-perforce-fix-v2 && git checkout a8ec423355
Interdiff (v1..v2):
diff --git a/.travis.yml b/.travis.yml
index c6ba8c8ec5..9c63c8c3f6 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -76,12 +76,11 @@ before_install:
;;
osx)
brew update --quiet
- brew tap homebrew/binary --quiet
# Uncomment this if you want to run perf tests:
# brew install gnu-time
brew install git-lfs gettext
brew link --force gettext
- brew install Caskroom/cask/perforce
+ brew install caskroom/cask/perforce
;;
esac;
echo "$(tput setaf 6)Perforce Server Version$(tput sgr0)";
.travis.yml | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 3843967a69..9c63c8c3f6 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -75,20 +75,12 @@ before_install:
popd
;;
osx)
- brew_force_set_latest_binary_hash () {
- FORMULA=$1
- SHA=$(brew fetch --force $FORMULA 2>&1 | grep ^SHA256: | cut -d ' ' -f 2)
- sed -E -i.bak "s/sha256 \"[0-9a-f]{64}\"/sha256 \"$SHA\"/g" \
- "$(brew --repository homebrew/homebrew-binary)/$FORMULA.rb"
- }
brew update --quiet
- brew tap homebrew/binary --quiet
- brew_force_set_latest_binary_hash perforce
- brew_force_set_latest_binary_hash perforce-server
# Uncomment this if you want to run perf tests:
# brew install gnu-time
- brew install git-lfs perforce-server perforce gettext
+ brew install git-lfs gettext
brew link --force gettext
+ brew install caskroom/cask/perforce
;;
esac;
echo "$(tput setaf 6)Perforce Server Version$(tput sgr0)";
--
2.11.0
^ permalink raw reply related
* [PATCH 0/7] completion bash: add more options and commands
From: bitte.keine.werbung.einwerfen @ 2017-01-22 22:57 UTC (permalink / raw)
To: git; +Cc: thomas.braun, szeder, john, Cornelius Weig
From: Cornelius Weig <cornelius.weig@tngtech.com>
The cli interface for git has the greatest versatility of all git tools.
Its productivity depends on how easy it is to type commands and to remember
options. The command line completion helps two-fold by easing input and
displaying possible options.
Bash completion lacks support for several options and some useful commands.
Although the selection of recognized options is always opinionated (e.g. the
documentation for git-completion.bash says that 'common' long options are
recognized), I think that extending the cli completion will always increase the
productivity.
To that end, the following commits add completion support for several existing
options and subcommands. For every command all options that are mentioned in
the introduction of its man page should now be available for completion.
Cornelius Weig (7):
completion: teach options to submodule subcommands
completion: add subcommand completion for rerere
completion: improve bash completion for git-add
completion: teach ls-remote to complete options
completion: teach replace to complete options
completion: teach remote subcommands option completion
completion: recognize more long-options
contrib/completion/git-completion.bash | 132 +++++++++++++++++++++++++++------
1 file changed, 110 insertions(+), 22 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH 1/7] completion: teach options to submodule subcommands
From: bitte.keine.werbung.einwerfen @ 2017-01-22 22:57 UTC (permalink / raw)
To: git; +Cc: thomas.braun, szeder, john, Cornelius Weig
In-Reply-To: <20170122225724.19360-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
The subcommands of submodule have different long-options which command
line users need to type in. Therefore, teach bash completion to support
most subcommand options for submodule.
---
contrib/completion/git-completion.bash | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 6721ff8..c54a557 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2556,10 +2556,11 @@ _git_submodule ()
__git_has_doubledash && return
local subcommands="add status init deinit update summary foreach sync"
- if [ -z "$(__git_find_on_cmdline "$subcommands")" ]; then
+ local subcommand="$(__git_find_on_cmdline "$subcommands")"
+ if [ -z "$subcommand" ]; then
case "$cur" in
--*)
- __gitcomp "--quiet --cached"
+ __gitcomp "--quiet"
;;
*)
__gitcomp "$subcommands"
@@ -2567,6 +2568,33 @@ _git_submodule ()
esac
return
fi
+
+ case "$subcommand,$cur" in
+ add,--*)
+ __gitcomp "--branch --force --name --reference --depth"
+ ;;
+ status,--*)
+ __gitcomp "--cached --recursive"
+ ;;
+ deinit,--*)
+ __gitcomp "--force --all"
+ ;;
+ update,--*)
+ __gitcomp "
+ --init --remote --no-fetch
+ --recommend-shallow --no-recommend-shallow
+ --force --rebase --merge --reference --depth --recursive --jobs
+ "
+ ;;
+ summary,--*)
+ __gitcomp "--cached --files --summary-limit"
+ ;;
+ foreach,--*|sync,--*)
+ __gitcomp "--recursive"
+ ;;
+ *)
+ ;;
+ esac
}
_git_svn ()
--
2.10.2
^ permalink raw reply related
* [PATCH 2/7] completion: add subcommand completion for rerere
From: bitte.keine.werbung.einwerfen @ 2017-01-22 22:57 UTC (permalink / raw)
To: git; +Cc: thomas.braun, szeder, john, Cornelius Weig
In-Reply-To: <20170122225724.19360-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
Managing recorded resolutions requires command-line usage of git-rerere.
Added subcommand completion for rerere and path completion for its
subcommand forget.
---
contrib/completion/git-completion.bash | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c54a557..8329f09 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2401,6 +2401,17 @@ _git_replace ()
__gitcomp_nl "$(__git_refs)"
}
+_git_rerere ()
+{
+ local subcommands="clear forget diff remaining status gc"
+ local subcommand="$(__git_find_on_cmdline "$subcommands")"
+ if test -z "$subcommand"
+ then
+ __gitcomp "$subcommands"
+ return
+ fi
+}
+
_git_reset ()
{
__git_has_doubledash && return
--
2.10.2
^ permalink raw reply related
* [PATCH 4/7] completion: teach ls-remote to complete options
From: bitte.keine.werbung.einwerfen @ 2017-01-22 22:57 UTC (permalink / raw)
To: git; +Cc: thomas.braun, szeder, john, Cornelius Weig
In-Reply-To: <20170122225724.19360-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
ls-remote needs to complete remote names and its own options. In
addition to the existing remote name completions, do also complete
the options --heads, --tags, --refs, and --get-url.
---
contrib/completion/git-completion.bash | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 652c7e2..36fe439 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1449,6 +1449,12 @@ _git_ls_files ()
_git_ls_remote ()
{
+ case "$cur" in
+ --*)
+ __gitcomp "--heads --tags --refs --get-url"
+ return
+ ;;
+ esac
__gitcomp_nl "$(__git_remotes)"
}
--
2.10.2
^ permalink raw reply related
* [PATCH 7/7] completion: recognize more long-options
From: bitte.keine.werbung.einwerfen @ 2017-01-22 22:57 UTC (permalink / raw)
To: git; +Cc: thomas.braun, szeder, john, Cornelius Weig
In-Reply-To: <20170122225724.19360-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
Recognize several new long-options for bash completion in the following
commands:
- apply: --recount --directory= --unsafe-paths
- archive: --prefix= --remote= --exec= --output
- branch: --column --no-column --sort= --points-at
- clone: --no-single-branch --shallow-submodules
- commit: --patch --short --date --allow-empty
- describe: --first-parent
- fetch, pull: --unshallow --update-shallow
- fsck: --name-objects
- grep: --break --heading --show-function --function-context
--untracked --no-index
- mergetool: --prompt --no-prompt
- reset: --merge --mixed --hard --soft --patch --keep
- revert: --strategy= --strategy-option=
- rm: --force
- shortlog: --email
- tag: --merged --no-merged --create-reflog
---
contrib/completion/git-completion.bash | 31 +++++++++++++++++++++----------
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0e09519..87d3d2c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -936,6 +936,7 @@ _git_apply ()
--apply --no-add --exclude=
--ignore-whitespace --ignore-space-change
--whitespace= --inaccurate-eof --verbose
+ --recount --directory= --unsafe-paths
"
return
esac
@@ -974,7 +975,7 @@ _git_archive ()
--*)
__gitcomp "
--format= --list --verbose
- --prefix= --remote= --exec=
+ --prefix= --remote= --exec= --output
"
return
;;
@@ -1029,6 +1030,7 @@ _git_branch ()
--track --no-track --contains --merged --no-merged
--set-upstream-to= --edit-description --list
--unset-upstream --delete --move --remotes
+ --column --no-column --sort= --points-at
"
;;
*)
@@ -1142,6 +1144,8 @@ _git_clone ()
--single-branch
--branch
--recurse-submodules
+ --no-single-branch
+ --shallow-submodules
"
return
;;
@@ -1183,6 +1187,7 @@ _git_commit ()
--reset-author --file= --message= --template=
--cleanup= --untracked-files --untracked-files=
--verbose --quiet --fixup= --squash=
+ --patch --short --date --allow-empty
"
return
esac
@@ -1201,7 +1206,7 @@ _git_describe ()
--*)
__gitcomp "
--all --tags --contains --abbrev= --candidates=
- --exact-match --debug --long --match --always
+ --exact-match --debug --long --match --always --first-parent
"
return
esac
@@ -1284,6 +1289,7 @@ __git_fetch_recurse_submodules="yes on-demand no"
__git_fetch_options="
--quiet --verbose --append --upload-pack --force --keep --depth=
--tags --no-tags --all --prune --dry-run --recurse-submodules=
+ --unshallow --update-shallow
"
_git_fetch ()
@@ -1333,7 +1339,7 @@ _git_fsck ()
--*)
__gitcomp "
--tags --root --unreachable --cache --no-reflogs --full
- --strict --verbose --lost-found
+ --strict --verbose --lost-found --name-objects
"
return
;;
@@ -1377,6 +1383,8 @@ _git_grep ()
--max-depth
--count
--and --or --not --all-match
+ --break --heading --show-function --function-context
+ --untracked --no-index
"
return
;;
@@ -1576,7 +1584,7 @@ _git_mergetool ()
return
;;
--*)
- __gitcomp "--tool="
+ __gitcomp "--tool= --prompt --no-prompt"
return
;;
esac
@@ -2456,7 +2464,7 @@ _git_reset ()
case "$cur" in
--*)
- __gitcomp "--merge --mixed --hard --soft --patch"
+ __gitcomp "--merge --mixed --hard --soft --patch --keep"
return
;;
esac
@@ -2472,7 +2480,10 @@ _git_revert ()
fi
case "$cur" in
--*)
- __gitcomp "--edit --mainline --no-edit --no-commit --signoff"
+ __gitcomp "
+ --edit --mainline --no-edit --no-commit --signoff
+ --strategy= --strategy-option=
+ "
return
;;
esac
@@ -2483,7 +2494,7 @@ _git_rm ()
{
case "$cur" in
--*)
- __gitcomp "--cached --dry-run --ignore-unmatch --quiet"
+ __gitcomp "--cached --dry-run --ignore-unmatch --quiet --force"
return
;;
esac
@@ -2500,7 +2511,7 @@ _git_shortlog ()
__gitcomp "
$__git_log_common_options
$__git_log_shortlog_options
- --numbered --summary
+ --numbered --summary --email
"
return
;;
@@ -2778,8 +2789,8 @@ _git_tag ()
--*)
__gitcomp "
--list --delete --verify --annotate --message --file
- --sign --cleanup --local-user --force --column --sort
- --contains --points-at
+ --sign --cleanup --local-user --force --column --sort=
+ --contains --points-at --merged --no-merged --create-reflog
"
;;
esac
--
2.10.2
^ permalink raw reply related
* [PATCH 3/7] completion: improve bash completion for git-add
From: bitte.keine.werbung.einwerfen @ 2017-01-22 22:57 UTC (permalink / raw)
To: git; +Cc: thomas.braun, szeder, john, Cornelius Weig
In-Reply-To: <20170122225724.19360-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
Add some long-options for git-add and improve path completion when the
--update flag is given.
---
contrib/completion/git-completion.bash | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8329f09..652c7e2 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -947,13 +947,17 @@ _git_add ()
--*)
__gitcomp "
--interactive --refresh --patch --update --dry-run
- --ignore-errors --intent-to-add
+ --ignore-errors --intent-to-add --force --edit --chmod=
"
return
esac
- # XXX should we check for --update and --all options ?
- __git_complete_index_file "--others --modified --directory --no-empty-directory"
+ local complete_opt="--others --modified --directory --no-empty-directory"
+ if test -n "$(__git_find_on_cmdline "-u --update")"
+ then
+ complete_opt="--modified"
+ fi
+ __git_complete_index_file "$complete_opt"
}
_git_archive ()
--
2.10.2
^ permalink raw reply related
* [PATCH 5/7] completion: teach replace to complete options
From: bitte.keine.werbung.einwerfen @ 2017-01-22 22:57 UTC (permalink / raw)
To: git; +Cc: thomas.braun, szeder, john, Cornelius Weig
In-Reply-To: <20170122225724.19360-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
Git-replace needs to complete references and its own options. In
addition to the existing references completions, do also complete the
options --edit --graft --format= --list --delete.
---
contrib/completion/git-completion.bash | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 36fe439..e76cbd7 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2408,6 +2408,12 @@ _git_remote ()
_git_replace ()
{
+ case "$cur" in
+ --*)
+ __gitcomp "--edit --graft --format= --list --delete"
+ return
+ ;;
+ esac
__gitcomp_nl "$(__git_refs)"
}
--
2.10.2
^ permalink raw reply related
* [PATCH 6/7] completion: teach remote subcommands option completion
From: bitte.keine.werbung.einwerfen @ 2017-01-22 22:57 UTC (permalink / raw)
To: git; +Cc: thomas.braun, szeder, john, Cornelius Weig
In-Reply-To: <20170122225724.19360-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
Git-remote needs to complete remote names, its subcommands, and options
thereof. In addition to the existing subcommand and remote name
completion, do also complete the options
- add: --track --master --fetch --tags --no-tags --mirror=
- set-url: --push --add --delete
- get-url: --push --all
- prune: --dry-run
---
contrib/completion/git-completion.bash | 36 +++++++++++++++++++++++++++-------
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e76cbd7..0e09519 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2384,24 +2384,46 @@ _git_config ()
_git_remote ()
{
- local subcommands="add rename remove set-head set-branches set-url show prune update"
+ local subcommands="
+ add rename remove set-head set-branches
+ get-url set-url show prune update
+ "
local subcommand="$(__git_find_on_cmdline "$subcommands")"
if [ -z "$subcommand" ]; then
- __gitcomp "$subcommands"
+ case "$cur" in
+ --*)
+ __gitcomp "--verbose"
+ ;;
+ *)
+ __gitcomp "$subcommands"
+ ;;
+ esac
return
fi
- case "$subcommand" in
- rename|remove|set-url|show|prune)
- __gitcomp_nl "$(__git_remotes)"
+ case "$subcommand,$cur" in
+ add,--*)
+ __gitcomp "--track --master --fetch --tags --no-tags --mirror="
;;
- set-head|set-branches)
+ add,*)
+ ;;
+ set-head,*|set-branches,*)
__git_complete_remote_or_refspec
;;
- update)
+ update,*)
__gitcomp "$(__git_get_config_variables "remotes")"
;;
+ set-url,--*)
+ __gitcomp "--push --add --delete"
+ ;;
+ get-url,--*)
+ __gitcomp "--push --all"
+ ;;
+ prune,--*)
+ __gitcomp "--dry-run"
+ ;;
*)
+ __gitcomp_nl "$(__git_remotes)"
;;
esac
}
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] blame: add option to print tips (--tips)
From: Junio C Hamano @ 2017-01-22 22:58 UTC (permalink / raw)
To: Edmundo Carmona Antoranz; +Cc: Git List
In-Reply-To: <CAOc6etaQ-fDWn38YzXkGOC0fSan1vrxjVDUXS924nBXWTTrhNQ@mail.gmail.com>
Edmundo Carmona Antoranz <eantoranz@gmail.com> writes:
> So, this is a draft of what I mean by "adding tips to blame".
>
> Example output (sample from builtin/blame.c):
> ...
> 15:32 $ ./git blame --tips -L 1934,1960 builtin/blame.c
> cee7f245dc: git-pickaxe: blame rewritten.
> cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
> 16:00:04 -0700 1934)
This is unfortunately unreadable to guess what you wanted to
achieve, not because the lines are too wide, but because they are
line-wrapped.
> Does it look "worthy"? And if so, would it be better to think of
> something like an "aggregate" option (or something like that) that
> would include the common information as tips, something like:
What is the target audience? If you are trying to write a script
that reads output by "git blame", you are strongly discouraged
unless you are reading from "git blame --porcelain" which is more
compact and has this information already IIRC.
^ permalink raw reply
* Re: Does it make sense to show tips on blame?
From: Edmundo Carmona Antoranz @ 2017-01-22 22:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <xmqqefzuvijl.fsf@gitster.mtv.corp.google.com>
On Sun, Jan 22, 2017 at 4:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Edmundo Carmona Antoranz <eantoranz@gmail.com> writes:
>
> What does the word "tip" mean in this context? The word is often
> used to mean the commits directly pointed at by branches (i.e. the
> tip of history), but I do not think that is what you are interested
> in showing in this butchered "diff" output.
>
> Do you mean the one-line summary for the commit? The commits that
> are shown will not be at the tip most of the time (the "+" ones may
> be if you happen to be running "git show" on the tip of a branch,
> but that is minority if you also want to do "git log -p"), so I am
> not sure it makes sense to call them "tips" in the above output.
>
Yeah, it would be the 1-line summary for the revision that is related
to the lines that
will be printed right after the summary, as a way to provide
additional context about
those lines without having to resort to an additional git show
--summary command.
Perhaps a name more appropriate name than "tips" in the context of git would be
better suited to avoid confusion.
> If I were doing the above, I would probably do them as footnotes to
> keep the body of the patch text (slightly) more readable. E.g.
>
> @@ -l,k +m,n @@
> 2a113aee9b
> +405d7f4af6 if (!root-tree)
> +405d7f4af6 load_tree(root)
> ...
> #2a113aee9b "fast-import: Proper notes tree manipulation", 2009-12-07
> #405d7f4af6 "fast-import: properly fanout notes when tree is imported", 2016-12-21
>
Now, this is a different topic altogether (difflame related) and I
think it was raised from the fact that I
included output from difflame (which starts from diff output) as my
example. When talking about
blame it would be no-patches, just plain blame output writing the
1-line summary for blocks of lines
related to the same revision. I already sent a patch today with the
changes needed to see what I mean in action.
Could you give it a test drive? Consider it's a rough draft (and I
also raise the question of "aggregating" output
on the mail thread)
Something like this, hope this doesn't get butchered (at least not
that hard, i'm truncating the lines):
3d426842: README.txt
3d426842 (Edmundo Carmona Antoranz 2017-01-17 22:26:18 -0600 1) difflame
3d426842 (Edmundo Carmona Antoranz 2017-01-17 22:26:18 -0600 2)
3d426842 (Edmundo Carmona Antoranz 2017-01-17 22:26:18 -0600 3) Copyright 2017
3d426842 (Edmundo Carmona Antoranz 2017-01-17 22:26:18 -0600 4) Released unde
3d426842 (Edmundo Carmona Antoranz 2017-01-17 22:26:18 -0600 5)
0660083e: Add params to blame and diff, adjust README.txt
0660083e (Edmundo Carmona Antoranz 2017-01-18 20:51:12 -0600 6) Show the outp
0660083e (Edmundo Carmona Antoranz 2017-01-18 20:51:12 -0600 7)
c869edc9: README.txt - stick (or at least, at least try) to 80 columns
c869edc9 (Edmundo Carmona Antoranz 2017-01-20 23:39:51 -0600 8) Example outp
c869edc9 (Edmundo Carmona Antoranz 2017-01-20 23:39:51 -0600 9) params to cha
>> The question is if you think it makes sense to add this option to
>> git-blame itself.
>>
>> Something like:
>> git blame --tips README.txt
>
> I do not think I would use it personally, as it would make it hard
> to pipe the output of "git blame" to less and then /search things,
> as extra cruft added by the option will get in the way. IOW, I do
> not think we want it for human-oriented output.
Doing a search through less, it would make sense to leave the 1-line summary out
but when looking at blame output through OSI layer 8, I'd definitely
like to get that 1-line summary "as an option" every so often (more
often than not
in my case, probably).
^ permalink raw reply
* Re: [PATCH] blame: add option to print tips (--tips)
From: Edmundo Carmona Antoranz @ 2017-01-22 23:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <xmqq1svuvh0y.fsf@gitster.mtv.corp.google.com>
On Sun, Jan 22, 2017 at 4:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> What is the target audience? If you are trying to write a script
> that reads output by "git blame", you are strongly discouraged
> unless you are reading from "git blame --porcelain" which is more
> compact and has this information already IIRC.
I wrote this for human consumption, actually. Maybe I overestimated the
need for this feature (I definitely find it handy, but it might be just me).
^ permalink raw reply
* [PATCH 4/4] git-prompt.sh: add tests for submodule indicator
From: Benjamin Fuchs @ 2017-01-22 23:11 UTC (permalink / raw)
To: git; +Cc: szeder.dev, sbeller, email
---
t/t9903-bash-prompt.sh | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 97c9b32..4dce366 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -37,6 +37,11 @@ test_expect_success 'setup for prompt tests' '
git commit -m "yet another b2" file &&
mkdir ignored_dir &&
echo "ignored_dir/" >>.gitignore &&
+ git checkout -b submodule &&
+ git submodule add ./. sub &&
+ git -C sub checkout master &&
+ git add sub &&
+ git commit -m submodule &&
git checkout master
'
@@ -755,4 +760,42 @@ 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 &&
+ git checkout submodule &&
+ test_when_finished "git checkout master" &&
+ (
+ cd sub &&
+ GIT_PS1_SHOWSUBMODULE=1 &&
+ __git_ps1 >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success 'prompt - submodule indicator - verify false' '
+ printf " (master)" >expected &&
+ git checkout submodule &&
+ test_when_finished "git checkout master" &&
+ (
+ cd sub &&
+ GIT_PS1_SHOWSUBMODULE= &&
+ __git_ps1 >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+test_expect_success 'prompt - submodule indicator - dirty status indicator' '
+ printf " (+sub:b1)" >expected &&
+ git checkout submodule &&
+ git -C sub checkout b1 &&
+ test_when_finished "git checkout master" &&
+ (
+ cd sub &&
+ GIT_PS1_SHOWSUBMODULE=1 &&
+ __git_ps1 >"$actual"
+ ) &&
+ test_cmp expected "$actual"
+'
+
+
test_done
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH] Option to allow cherry-pick to skip empty commits
From: Junio C Hamano @ 2017-01-22 23:27 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <20170121131629.16326-1-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> This allows cherry-picking a set of commits, some of which may be
> redundant, without stopping to ask for the user intervention.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> Documentation/git-cherry-pick.txt | 4 ++++
> builtin/revert.c | 1 +
> sequencer.c | 45 +++++++++++++++++++++++++++++++--------
> sequencer.h | 1 +
> 4 files changed, 42 insertions(+), 9 deletions(-)
>
>
> I would like to add to cherry-pick the ability to skip patches. To this
> end, I'm working on two options: a general `--skip-empty` option to
> handle redundant and empty commits by simply skipping them (no user
> intervention), and a `--skip` option as an alternative form to
> `--continue` to skip the ongoing (conflicting or empty) commit.
>
> The patch here presents my implementation of the `--skip-empty` option,
> including documentation. Comments welcome.
Sounds like a useful thing to do.
> +static int allow_or_skip_empty(struct replay_opts *opts, struct commit *commit)
> {
> int index_unchanged, empty_commit;
>
> /*
> - * Three cases:
> + * Four cases:
> *
> - * (1) we do not allow empty at all and error out.
> + * (1) we do not allow empty at all and error out;
> *
> - * (2) we allow ones that were initially empty, but
> + * (2) we skip empty commits altogether;
> + *
> + * (3) we allow ones that were initially empty, but
> * forbid the ones that become empty;
> *
> - * (3) we allow both.
> + * (4) we allow both.
> */
The original gave callers the choice to tell two cases (a commit was
empty in the original history, and a commit that was not empty in
the original history turns out to be redundant) apart and handle
them differently. I tend to agree that skipping the former should
be the norm, and also I think it is sensible to drop the latter, and
that is what your updated (2) gives us, I think.
But I would suspect that it would rather be common to have a
deliberately empty commit in the original as a marker in a history
and want to keep that across cherry-picking a series, while wanting
to discard/skip patches that are already applied in an updated base.
Shouldn't that be supported as the fifth case?
^ permalink raw reply
* Re: [PATCH] blame: add option to print tips (--tips)
From: Junio C Hamano @ 2017-01-22 23:35 UTC (permalink / raw)
To: Edmundo Carmona Antoranz; +Cc: Git List
In-Reply-To: <CAOc6etY5odte=TKyWX3Wf1BVaNTfDeA-xsGOKiyuH88HZgqFDQ@mail.gmail.com>
Edmundo Carmona Antoranz <eantoranz@gmail.com> writes:
> I wrote this for human consumption, actually.
I see.
> Maybe I overestimated the
> need for this feature (I definitely find it handy, but it might be just me).
That is too early to tell. At this point we only know there are me
who won't use it and you who will, among all the other people in the
world.
^ permalink raw reply
* Re: [PATCH v2 7/7] Makefile: add a knob to enable the use of Asciidoctor
From: Øyvind A. Holm @ 2017-01-23 2:57 UTC (permalink / raw)
To: brian m. carlson; +Cc: git, Johannes Schindelin, Jeff King
In-Reply-To: <20170122024156.284180-8-sandals@crustytoothpaste.net>
[-- Attachment #1: Type: text/plain, Size: 3209 bytes --]
On 2017-01-22 02:41:56, brian m. carlson wrote:
> While Git has traditionally built its documentation using AsciiDoc, some
> people wish to use Asciidoctor for speed or other reasons. Add a
> Makefile knob, USE_ASCIIDOCTOR, that sets various options in order to
> produce acceptable output. For HTML output, XHTML5 was chosen, since
> the AsciiDoc options also produce XHTML, albeit XHTML 1.1.
I applied and tested the patches on the current master, commit
787f75f0567a ("Sixth batch for 2.12"), and "make doc" with
USE_ASCIIDOCTOR fails:
$ git clean -fxd && make doc USE_ASCIIDOCTOR=1
Removing Documentation/cmd-list.made
Removing Documentation/cmds-ancillaryinterrogators.txt
Removing Documentation/cmds-ancillarymanipulators.txt
Removing Documentation/cmds-foreignscminterface.txt
Removing Documentation/cmds-mainporcelain.txt
Removing Documentation/cmds-plumbinginterrogators.txt
Removing Documentation/cmds-plumbingmanipulators.txt
Removing Documentation/cmds-purehelpers.txt
Removing Documentation/cmds-synchelpers.txt
Removing Documentation/cmds-synchingrepositories.txt
Removing Documentation/doc.dep
Removing Documentation/mergetools-diff.txt
Removing Documentation/mergetools-list.made
Removing Documentation/mergetools-merge.txt
Removing GIT-VERSION-FILE
GIT_VERSION = 2.11.0.460.g218feb5a0e89
make -C Documentation all
make[1]: Entering directory '/home/sunny/src/git/src-other/devel/git/git/Documentation'
GEN mergetools-list.made
GEN cmd-list.made
GEN doc.dep
make[2]: Entering directory '/home/sunny/src/git/src-other/devel/git/git'
make[2]: 'GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory '/home/sunny/src/git/src-other/devel/git/git'
make[2]: Entering directory '/home/sunny/src/git/src-other/devel/git/git'
make[2]: 'GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory '/home/sunny/src/git/src-other/devel/git/git'
ASCIIDOC git-init-db.html
Couldn't find a view in @views for document
Use --trace for backtrace
Makefile:330: recipe for target 'git-init-db.html' failed
make[1]: *** [git-init-db.html] Error 1
make[1]: Leaving directory '/home/sunny/src/git/src-other/devel/git/git/Documentation'
Makefile:2091: recipe for target 'doc' failed
make: *** [doc] Error 2
2017-01-23 03:50:05 sunny@sunbase:~/src/git/src-other/devel/git/git (tp-bmc-asciidoctor)
$ lsb_release -d
Description: Debian GNU/Linux 8.7 (jessie)
$ asciidoctor --version
Asciidoctor 0.1.4 [http://asciidoctor.org]
I installed Asciidoctor with a standard "apt-get install asciidoctor",
do I need to install more packages?
The build is broken by patch #7 ("Makefile: add a knob to enable the use
of Asciidoctor"), the other commits seems to work, though I haven't
tested them all individually yet. Standard "make doc" works.
Regards,
Øyvind
+-| Øyvind A. Holm <sunny@sunbase.org> - N 60.37604° E 5.33339° |-+
| OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc |
| Fingerprint: A006 05D6 E676 B319 55E2 E77E FB0C BEE8 94A5 06E5 |
+------------| 60bceb4e-e116-11e6-8fac-db5caa6d21d3 |-------------+
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 7/7] Makefile: add a knob to enable the use of Asciidoctor
From: brian m. carlson @ 2017-01-23 4:09 UTC (permalink / raw)
To: Øyvind A. Holm, git, Johannes Schindelin, Jeff King
In-Reply-To: <20170123025712.o52hgkdu26h6lrm2@sunbase.org>
[-- Attachment #1: Type: text/plain, Size: 3598 bytes --]
On Mon, Jan 23, 2017 at 03:57:13AM +0100, Øyvind A. Holm wrote:
> On 2017-01-22 02:41:56, brian m. carlson wrote:
> > While Git has traditionally built its documentation using AsciiDoc, some
> > people wish to use Asciidoctor for speed or other reasons. Add a
> > Makefile knob, USE_ASCIIDOCTOR, that sets various options in order to
> > produce acceptable output. For HTML output, XHTML5 was chosen, since
> > the AsciiDoc options also produce XHTML, albeit XHTML 1.1.
>
> I applied and tested the patches on the current master, commit
> 787f75f0567a ("Sixth batch for 2.12"), and "make doc" with
> USE_ASCIIDOCTOR fails:
>
> $ git clean -fxd && make doc USE_ASCIIDOCTOR=1
> Removing Documentation/cmd-list.made
> Removing Documentation/cmds-ancillaryinterrogators.txt
> Removing Documentation/cmds-ancillarymanipulators.txt
> Removing Documentation/cmds-foreignscminterface.txt
> Removing Documentation/cmds-mainporcelain.txt
> Removing Documentation/cmds-plumbinginterrogators.txt
> Removing Documentation/cmds-plumbingmanipulators.txt
> Removing Documentation/cmds-purehelpers.txt
> Removing Documentation/cmds-synchelpers.txt
> Removing Documentation/cmds-synchingrepositories.txt
> Removing Documentation/doc.dep
> Removing Documentation/mergetools-diff.txt
> Removing Documentation/mergetools-list.made
> Removing Documentation/mergetools-merge.txt
> Removing GIT-VERSION-FILE
> GIT_VERSION = 2.11.0.460.g218feb5a0e89
> make -C Documentation all
> make[1]: Entering directory '/home/sunny/src/git/src-other/devel/git/git/Documentation'
> GEN mergetools-list.made
> GEN cmd-list.made
> GEN doc.dep
> make[2]: Entering directory '/home/sunny/src/git/src-other/devel/git/git'
> make[2]: 'GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory '/home/sunny/src/git/src-other/devel/git/git'
> make[2]: Entering directory '/home/sunny/src/git/src-other/devel/git/git'
> make[2]: 'GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory '/home/sunny/src/git/src-other/devel/git/git'
> ASCIIDOC git-init-db.html
> Couldn't find a view in @views for document
> Use --trace for backtrace
> Makefile:330: recipe for target 'git-init-db.html' failed
> make[1]: *** [git-init-db.html] Error 1
> make[1]: Leaving directory '/home/sunny/src/git/src-other/devel/git/git/Documentation'
> Makefile:2091: recipe for target 'doc' failed
> make: *** [doc] Error 2
> 2017-01-23 03:50:05 sunny@sunbase:~/src/git/src-other/devel/git/git (tp-bmc-asciidoctor)
>
> $ lsb_release -d
> Description: Debian GNU/Linux 8.7 (jessie)
>
> $ asciidoctor --version
> Asciidoctor 0.1.4 [http://asciidoctor.org]
>
> I installed Asciidoctor with a standard "apt-get install asciidoctor",
> do I need to install more packages?
>
> The build is broken by patch #7 ("Makefile: add a knob to enable the use
> of Asciidoctor"), the other commits seems to work, though I haven't
> tested them all individually yet. Standard "make doc" works.
I think you need a newer version of Asciidoctor. I fixed one or two
issues upstream in 1.5.2, I think, that made it work properly.
You could try to do the build with the "html5" target instead of
"xhtml5" and see if that works. If so, we could switch to that instead
if we want to support older Asciidoctor versions.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] Option to allow cherry-pick to skip empty commits
From: Giuseppe Bilotta @ 2017-01-23 10:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <xmqqpojeu14h.fsf@gitster.mtv.corp.google.com>
On Mon, Jan 23, 2017 at 12:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>> +static int allow_or_skip_empty(struct replay_opts *opts, struct commit *commit)
>> {
>> int index_unchanged, empty_commit;
>>
>> /*
>> - * Three cases:
>> + * Four cases:
>> *
>> - * (1) we do not allow empty at all and error out.
>> + * (1) we do not allow empty at all and error out;
>> *
>> - * (2) we allow ones that were initially empty, but
>> + * (2) we skip empty commits altogether;
>> + *
>> + * (3) we allow ones that were initially empty, but
>> * forbid the ones that become empty;
>> *
>> - * (3) we allow both.
>> + * (4) we allow both.
>> */
>
> The original gave callers the choice to tell two cases (a commit was
> empty in the original history, and a commit that was not empty in
> the original history turns out to be redundant) apart and handle
> them differently. I tend to agree that skipping the former should
> be the norm, and also I think it is sensible to drop the latter, and
> that is what your updated (2) gives us, I think.
>
> But I would suspect that it would rather be common to have a
> deliberately empty commit in the original as a marker in a history
> and want to keep that across cherry-picking a series, while wanting
> to discard/skip patches that are already applied in an updated base.
> Shouldn't that be supported as the fifth case?
I was actually wondering about that. I guess the best approach
(symmetric wrt to the --allow) would be to intro introduce
--skip-empty _and_ --skip-redundant, with the former implying the
latter.
By the way, I noticed going over the code that the -allow options are
not stored, so that in case of interruption they will be reset, is
this intentional or a bug?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* sparse checkout : ignore paths
From: Tushar Kapila @ 2017-01-23 11:45 UTC (permalink / raw)
To: git
When we clone/ pull with : config core.sparsecheckout true
We can specify paths to include. Would be good to explicitly specify
paths to exclude too. So I can include want/
but exclude want/bin/
Similar to .git/info/sparse-checkout can we have a
.git/info/sparse-ignore-checkout optional file?
Logic would be to see if a path matches that is in
.git/info/sparse-checkout then see if its flagged in
.git/info/sparse-ignore-checkout , do not download if blocked in
.git/info/sparse-ignore-checkout. If the file does not exist, then
nothing ignored.
Regards,
Tushar Kapila
^ permalink raw reply
* Re: Idea: Add a filter option to 'git rebase'
From: Johannes Schindelin @ 2017-01-23 11:57 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List, Thomas Braun
In-Reply-To: <7EEBBEA4046743C9AE04AE50EE30D72A@PhilipOakley>
Hi,
On Sat, 21 Jan 2017, Philip Oakley wrote:
> From: "Thomas Braun" Friday, January 20, 2017 11:35 PM
> > Am 20.01.2017 um 23:28 schrieb Philip Oakley:
> > > A recent question on stackoverflow
> > > http://stackoverflow.com/questions/41753252/drop-commits-by-commit-message-in-git-rebase
> > > sought to remove automatically commits that could be identified by
> > > relevant words in the commit message.
Interesting. As long as those magic words appear in the oneline, I would
simply call the command ":%s/^pick.*<magic-word>/#&/".
But that is neither scripted nor does it work with magic words elsewhere
in the commit message (let alone more sophisticated filtering based on,
say, authorship or magic words in the diff's "+" lines).
> > > I had thought that the ubiquitous `git filter-branch` should be able
> > > to do this sort of thing. I was wrong. (It was pointed out to me
> > > that...) The man page notes that removing a commit via filter-branch
> > > does not remove the changes from following commits and directs
> > > readers to using `git rebase(1)`.
Right, filter-branch never cherry-picks patches, but instead complete
trees.
> > > However the rebase command does not have any filter option to allow
> > > the automatic population of its TODO list with the appropriate
> > > pick/edit/drop/etc. values.
> >
> > Well you can use an arbitrary shell command as editor, so something
> > like
> >
> > $ GIT_SEQUENCE_EDITOR="sed -i -re 's/^pick /edit /'" git rebase -i master
> >
> > will change pick to edit of all commits.
> >
> > Maybe that can be mentioned in the man page of rebase?
Please note that using a script instead of a command, you can do really
sophisticated things including sophisticated re-writing of the edit script
as well as calling the GIT_EDITOR in the end to re-establish
interactivity. I do exactly that in my Git garden shears [*1*].
> I had been more thinking of a process that passed single sha1's to the
> filter on each pass through the rebase list, so that the coding was
> simpler, plus the --interactive could be used, if required, for final
> refinement (gitk being handy for that).
>
> However, a mention in the man pages would be zero code cost, and could
> help.
In the (frustratingly) long run, we will want to add a command-line option
that allows overriding the edit script generation, paired with a
command-line option that generates the current version of the edit script
(in my rebase--helper work that is still under review, the latter option
already exists).
That way, you have full flexibility and could even generate the entire
edit script from scratch, rather than letting rebase -i generate one and
then filtering it.
Ciao,
Johannes
Footnote *1*:
https://github.com/git-for-windows/build-extra/blob/master/shears.sh
^ permalink raw reply
* [PATCH v1 2/2] urlmatch: allow regex-based URL matching
From: Patrick Steinhardt @ 2017-01-23 13:06 UTC (permalink / raw)
To: git; +Cc: Patrick Steinhardt, Patrick Steinhardt
In-Reply-To: <20170123130635.29577-1-patrick.steinhardt@elego.de>
The URL matching function computes for two URLs whether they match not.
The match is performed by splitting up the URL into different parts and
then doing an exact comparison with the to-be-matched URL.
The main user of `urlmatch` is the configuration subsystem. It allows to
set certain configurations based on the URL which is being connected to
via keys like `http.<url>.*`. A common use case for this is to set
proxies for only some remotes which match the given URL. Unfortunately,
having exact matches for all parts of the URL can become quite tedious
in some setups. Imagine for example a corporate network where there are
dozens or even hundreds of subdomains, which would have to be configured
individually.
This commit introduces the ability to have regex-based URL matches. A
user can prefix a configuration key's URL with a question mark ('?') to
use regular expressions instead of exact matches in order to find all
matching URLs. A user can now simply add a key
`http.?http://.*\\.example\\.com.proxy` to set a proxy for all
subdomains of `example.com`. When no question mark is given as a prefix,
then the configuration subsystem will use the old algorithm based on
exact matches.
Signed-off-by: Patrick Steinhardt <patrick.steinhardt@elego.de>
---
Documentation/config.txt | 6 ++++-
t/t1300-repo-config.sh | 31 ++++++++++++++++++++++++++
urlmatch.c | 57 ++++++++++++++++++++++++++++++++++++++----------
3 files changed, 81 insertions(+), 13 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 506431267..23651b19e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1906,7 +1906,11 @@ http.followRedirects::
http.<url>.*::
Any of the http.* options above can be applied selectively to some URLs.
- For a config key to match a URL, each element of the config key is
+ There are two different modes to match URLs: if the config key's URL is
+ prefixed with a `?`, it allows to make use of regular expressions. An
+ example for this is `http.?http://.*\\.example\\.com.*` to match all
+ subdomains of `example.com`.
+ If the key is not prefixed with a `?`, each element of the config key is
compared to that of the URL, in the following order:
+
--
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 923bfc5a2..fbbc58304 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1177,6 +1177,37 @@ test_expect_success 'urlmatch' '
test_cmp expect actual
'
+test_expect_success 'regex-based urlmatch' '
+ cat >.git/config <<-\EOF &&
+ [http]
+ sslVerify
+ [http "?https://.*\\.example\\.com"]
+ sslVerify = false
+ cookieFile = /tmp/cookie.txt
+ EOF
+
+ test_expect_code 1 git config --bool --get-urlmatch doesnt.exist https://good.example.com >actual &&
+ test_must_be_empty actual &&
+
+ test_expect_code 1 git config --bool --get-urlmatch doesnt.exist https://good-example.com >actual &&
+ test_must_be_empty actual &&
+
+ echo true >expect &&
+ git config --bool --get-urlmatch http.SSLverify https://example.com >actual &&
+ test_cmp expect actual &&
+
+ echo false >expect &&
+ git config --bool --get-urlmatch http.sslverify https://subdomain.example.com >actual &&
+ test_cmp expect actual &&
+
+ {
+ echo http.cookiefile /tmp/cookie.txt &&
+ echo http.sslverify false
+ } >expect &&
+ git config --get-urlmatch HTTP https://subdomain.example.com >actual &&
+ test_cmp expect actual
+'
+
# good section hygiene
test_expect_failure 'unsetting the last key in a section removes header' '
cat >.git/config <<-\EOF &&
diff --git a/urlmatch.c b/urlmatch.c
index 132d342bc..8ed5047e3 100644
--- a/urlmatch.c
+++ b/urlmatch.c
@@ -490,18 +490,51 @@ int urlmatch_config_entry(const char *var, const char *value, void *cb)
}
dot = strrchr(key, '.');
if (dot) {
- char *config_url, *norm_url;
- struct url_info norm_info;
-
- config_url = xmemdupz(key, dot - key);
- norm_url = url_normalize(config_url, &norm_info);
- free(config_url);
- if (!norm_url)
- return 0;
- matched_len = match_urls(url, &norm_info, &user_matched);
- free(norm_url);
- if (!matched_len)
- return 0;
+ /*
+ * When the configuration key's URL is prefixed
+ * with a '?', regular expressions are enabled to
+ * match the URL instead of the exact-match
+ * algorithm.
+ */
+ if (starts_with(key, "?")) {
+ char *config_url;
+ regex_t reg;
+ int status;
+
+ config_url = xmemdupz(key + 1, dot - key - 1);
+ if (regcomp(®, config_url, REG_EXTENDED)) {
+ warning(_("Cannot prepare URL regexp %s"),
+ config_url);
+ free(config_url);
+ return 0;
+ }
+
+ status = regexec(®, url->url, 0, NULL, 0);
+ free(config_url);
+ regfree(®);
+
+ if (status) {
+ if (status != REG_NOMATCH)
+ warning(_("regexec returned %d for input '%s'"),
+ status, url->url);
+
+ return 0;
+ }
+ } else {
+ char *config_url, *norm_url;
+ struct url_info norm_info;
+
+ config_url = xmemdupz(key, dot - key);
+ norm_url = url_normalize(config_url, &norm_info);
+ free(config_url);
+ if (!norm_url)
+ return 0;
+ matched_len = match_urls(url, &norm_info, &user_matched);
+ free(norm_url);
+ if (!matched_len)
+ return 0;
+ }
+
key = dot + 1;
}
--
2.11.0
^ permalink raw reply related
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