* [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
* [PATCH v1 1/2] mailmap: add Patrick Steinhardt's work address
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>
Signed-off-by: Patrick Steinhardt <patrick.steinhardt@elego.de>
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index 9c87a3840..ea59205b9 100644
--- a/.mailmap
+++ b/.mailmap
@@ -177,6 +177,7 @@ Paolo Bonzini <bonzini@gnu.org> <paolo.bonzini@lu.unisi.ch>
Pascal Obry <pascal@obry.net> <pascal.obry@gmail.com>
Pascal Obry <pascal@obry.net> <pascal.obry@wanadoo.fr>
Pat Notz <patnotz@gmail.com> <pknotz@sandia.gov>
+Patrick Steinhardt <ps@pks.im> <patrick.steinhardt@elego.de>
Paul Mackerras <paulus@samba.org> <paulus@dorrigo.(none)>
Paul Mackerras <paulus@samba.org> <paulus@pogo.(none)>
Peter Baumann <waste.manager@gmx.de> <Peter.B.Baumann@stud.informatik.uni-erlangen.de>
--
2.11.0
^ permalink raw reply related
* [PATCH v1 0/2] urlmatch: allow regexp-based matches
From: Patrick Steinhardt @ 2017-01-23 13:06 UTC (permalink / raw)
To: git; +Cc: Patrick Steinhardt, Patrick Steinhardt
Hi,
Short disclaimer: this patch results from work for a client at my
day job at elego Software Solutions GmbH. As such, I'm using my
work mail address and added a new mailmap entry. I wasn't exactly
certain if the mailmap entry should've been created in a separate
commit series, as it has nothing to do with the actual topic --
I can re-send it separately if requested.
This patch is mostly a request for comments. The use case is to
be able to configure an HTTP proxy for all subdomains of a
certain domain where there are hundreds of subdomains. The most
flexible way I could imagine was by using regular expressions for
the matching, which is how I implemented it for now. So users can
now create a configuration key like
`http.?http://.*\\.example\\.com.*` to apply settings for all
subdomains of `example.com`.
I tried to make this feature as backwards-compatible as it can be
by having the '?' prefix. Older clients will barf when trying to
normalize the URL as '?' is not in the set of allowed characters
for a URL, and for newer clients there will be no change in
behavior for previously configured `http.<url>.*` keys.
Regards
Patrick Steinhardt
Patrick Steinhardt (2):
mailmap: add Patrick Steinhardt's work address
urlmatch: allow regex-based URL matching
.mailmap | 1 +
Documentation/config.txt | 6 ++++-
t/t1300-repo-config.sh | 31 ++++++++++++++++++++++++++
urlmatch.c | 57 ++++++++++++++++++++++++++++++++++++++----------
4 files changed, 82 insertions(+), 13 deletions(-)
--
2.11.0
^ permalink raw reply
* GSoC 2017: application open, deadline = February 9, 2017
From: Matthieu Moy @ 2017-01-23 15:02 UTC (permalink / raw)
To: git, Pranit Bauva, Lars Schneider, Christian Couder, Jeff King,
Carlos Martín Nieto, Johannes Schindelin, Thomas Gummerer
Hi,
The Google Summer of Code 2017 program is launched
(https://summerofcode.withgoogle.com/).
Last year, Pranit Bauva worked on porting "git bisect" from shell to C,
mentored by Christian and Lars (I didn't follow closely, but essentially
many preparatory steps, cleanups and tests were merged in master, and
patches starting the real port are still queued in pu). The org admins
were Peff and I.
The application deadline is February 9, 2017, i.e. a bit more than 2
weeks from now. So, we should decide quickly whether or not to
participate, and if so work on the application.
On my side, I've been struggling to find some time budget to allocate to
Git since last year and I couldn't even keep up with discussions on this
list :-(. Last summer, I thought that being an org co-admin would help,
but it didn't. So, as much as possible, I'd like to avoid being an org
admin this year. It's not a lot of work (much, much less than being a
mentor!), but if I manage to get some time to work for Git, I'd rather
do that on coding and reviewing this year.
So, a bunch of unanswered questions:
* Does the git.git community want to participate in GSoC this year?
Actually, I have mixed feelings about this: I do like GSoC, but it
seems we lack reviewer time more than coder time, and GSoC does not
make it better. OTOH, a GSoC participant is a potential reviewer in
the long run ...
* Does the libgit2 community want to participate in GSoC? If so, we
should clarify the application process. Last year, I wrote (too late):
> It's essentially too late to change this for this year, but next
> time we should discuss earlier about how we want to organize this
> git.git/libgit2 thing. For example, I think it would make little sense
> to have a git.git microproject and then apply for a libgit2 project
> since we have very different ways of interacting. And honestly, right
> now the application is really git.git-centric so I don't think it
> attracts students towards libgit2. So, if you want to attract more
> students, we should work on that.
If the answer to one of the above question is yes, then:
* Who's willing to mentor? and to admin?
* We need to write the application, i.e. essentially polish and update
the text here: https://git.github.io/SoC-2016-Org-Application/ and
update the list of project ideas and microprojects :
https://git.github.io/SoC-2017-Ideas/
https://git.github.io/SoC-2016-Microprojects/
Cheers,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: sparse checkout : ignore paths
From: Johannes Schindelin @ 2017-01-23 15:13 UTC (permalink / raw)
To: Tushar Kapila; +Cc: git
In-Reply-To: <CALNyQkyy_prP60kp_DpMzG9+affqPW0-z6F81R4OSgHg0QFc+g@mail.gmail.com>
Hi,
On Mon, 23 Jan 2017, Tushar Kapila wrote:
> 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.
That is already possible by using "negative patterns", i.e. patterns
preceded by an exclamation point.
Ciao,
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