* 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
* [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: [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
* 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: 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
* [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
* [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 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 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 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 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 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 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 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
* 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
* 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: 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: 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: [PATCH] blame: add option to print tips (--tips)
From: Edmundo Carmona Antoranz @ 2017-01-22 21:39 UTC (permalink / raw)
To: Git List; +Cc: Edmundo Carmona Antoranz
In-Reply-To: <20170122212855.25924-1-eantoranz@gmail.com>
Hello, everybody!
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)
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1935) static void emit_other(struct scoreboard *sb,
struct blame_entry *ent, int opt)
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1936) {
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1937) int cnt;
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1938) const char *cp;
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1939) struct origin *suspect = ent->suspect;
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1940) struct commit_info ci;
d59f765ac9: use sha1_to_hex_r() instead of strcpy
d59f765ac9 builtin/blame.c (Jeff King 2015-09-24
17:08:03 -0400 1941) char hex[GIT_SHA1_HEXSZ + 1];
cee7f245dc: git-pickaxe: blame rewritten.
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1942) int show_raw_time = !!(opt &
OUTPUT_RAW_TIMESTAMP);
f2aea1696f: blame: add option to print tips (--tips)
f2aea1696f builtin/blame.c (Edmundo Carmona Antoranz 2017-01-22
15:23:31 -0600 1943) int revision_length = (opt &
OUTPUT_LONG_OBJECT_NAME) ? GIT_SHA1_HEXSZ : abbrev;
cee7f245dc: git-pickaxe: blame rewritten.
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1944)
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1945) get_commit_info(suspect->commit, &ci, 1);
f2fd0760f6: Convert struct object to object_id
f2fd0760f6 builtin/blame.c (brian m. carlson 2015-11-10
02:22:28 +0000 1946) sha1_to_hex_r(hex,
suspect->commit->object.oid.hash);
cee7f245dc: git-pickaxe: blame rewritten.
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1947)
f2aea1696f: blame: add option to print tips (--tips)
f2aea1696f builtin/blame.c (Edmundo Carmona Antoranz 2017-01-22
15:23:31 -0600 1948) if (opt & OUTPUT_SHOW_TIPS)
f2aea1696f builtin/blame.c (Edmundo Carmona Antoranz 2017-01-22
15:23:31 -0600 1949) printf("\t%.*s: %s\n", revision_length,
hex, ci.summary.buf);
f2aea1696f builtin/blame.c (Edmundo Carmona Antoranz 2017-01-22
15:23:31 -0600 1950)
cee7f245dc: git-pickaxe: blame rewritten.
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1951) cp = nth_line(sb, ent->lno);
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1952) for (cnt = 0; cnt < ent->num_lines; cnt++) {
cee7f245dc builtin-pickaxe.c (Junio C Hamano 2006-10-19
16:00:04 -0700 1953) char ch;
f2aea1696f: blame: add option to print tips (--tips)
f2aea1696f builtin/blame.c (Edmundo Carmona Antoranz 2017-01-22
15:23:31 -0600 1954) int length = revision_length;
b11121d9e3: git-blame: show lines attributed to boundary
commits differently.
b11121d9e3 builtin-blame.c (Junio C Hamano 2006-12-01
20:45:45 -0800 1955)
b11121d9e3 builtin-blame.c (Junio C Hamano 2006-12-01
20:45:45 -0800 1956) if (suspect->commit->object.flags &
UNINTERESTING) {
e68989a739: annotate: fix for cvsserver.
e68989a739 builtin-blame.c (Junio C Hamano 2007-02-06
01:52:04 -0800 1957) if (blank_boundary)
e68989a739 builtin-blame.c (Junio C Hamano 2007-02-06
01:52:04 -0800 1958) memset(hex, ' ',
length);
7ceacdffc5: "blame -c" should be compatible with "annotate"
7ceacdffc5 builtin-blame.c (Junio C Hamano 2008-09-05
00:57:35 -0700 1959) else if (!(opt &
OUTPUT_ANNOTATE_COMPAT)) {
4c10a5caa7: blame: -b (blame.blankboundary) and --root (blame.showroot)
4c10a5caa7 builtin-blame.c (Junio C Hamano 2006-12-18
14:04:38 -0800 1960) length--;
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:
15:32 $ ./git blame --tips -L 1934,1960 builtin/blame.c
cee7f245dc: builtin-pickaxe.c (Junio C Hamano
2006-10-19 16:00:04 -0700) git-pickaxe: blame rewritten.
1934
1935 static void emit_other(struct scoreboard *sb, struct blame_entry
*ent, int opt)
1936 {
1937 int cnt;
1938 const char *cp;
1939 struct origin *suspect = ent->suspect;
1940 struct commit_info ci;
d59f765ac9: builtin/blame.c (Jeff King
2015-09-24 17:08:03 -0400) use sha1_to_hex_r() instead of strcpy
1941 char hex[GIT_SHA1_HEXSZ + 1];
cee7f245dc: builtin-pickaxe.c (Junio C Hamano
2006-10-19 16:00:04 -0700) git-pickaxe: blame rewritten.
1942 int show_raw_time = !!(opt & OUTPUT_RAW_TIMESTAMP);
f2aea1696f: builtin/blame.c (Edmundo Carmona Antoranz
2017-01-22 15:23:31 -0600) blame: add option to print tips (--tips)
1943 int revision_length = (opt & OUTPUT_LONG_OBJECT_NAME) ?
GIT_SHA1_HEXSZ : abbrev;
cee7f245dc: builtin-pickaxe.c (Junio C Hamano
2006-10-19 16:00:04 -0700) git-pickaxe: blame rewritten.
1944
1945 get_commit_info(suspect->commit, &ci, 1);
Best regards!
On Sun, Jan 22, 2017 at 3:28 PM, Edmundo Carmona Antoranz
<eantoranz@gmail.com> wrote:
> ---
> builtin/blame.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/blame.c b/builtin/blame.c
> index 126b8c9e5..4bc449f40 100644
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -1884,6 +1884,7 @@ static const char *format_time(unsigned long time, const char *tz_str,
> #define OUTPUT_NO_AUTHOR 0200
> #define OUTPUT_SHOW_EMAIL 0400
> #define OUTPUT_LINE_PORCELAIN 01000
> +#define OUTPUT_SHOW_TIPS 02000
>
> static void emit_porcelain_details(struct origin *suspect, int repeat)
> {
> @@ -1939,14 +1940,18 @@ static void emit_other(struct scoreboard *sb, struct blame_entry *ent, int opt)
> struct commit_info ci;
> char hex[GIT_SHA1_HEXSZ + 1];
> int show_raw_time = !!(opt & OUTPUT_RAW_TIMESTAMP);
> + int revision_length = (opt & OUTPUT_LONG_OBJECT_NAME) ? GIT_SHA1_HEXSZ : abbrev;
>
> get_commit_info(suspect->commit, &ci, 1);
> sha1_to_hex_r(hex, suspect->commit->object.oid.hash);
>
> + if (opt & OUTPUT_SHOW_TIPS)
> + printf("\t%.*s: %s\n", revision_length, hex, ci.summary.buf);
> +
> cp = nth_line(sb, ent->lno);
> for (cnt = 0; cnt < ent->num_lines; cnt++) {
> char ch;
> - int length = (opt & OUTPUT_LONG_OBJECT_NAME) ? GIT_SHA1_HEXSZ : abbrev;
> + int length = revision_length;
>
> if (suspect->commit->object.flags & UNINTERESTING) {
> if (blank_boundary)
> @@ -2609,6 +2614,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
> { OPTION_CALLBACK, 'C', NULL, &opt, N_("score"), N_("Find line copies within and across files"), PARSE_OPT_OPTARG, blame_copy_callback },
> { OPTION_CALLBACK, 'M', NULL, &opt, N_("score"), N_("Find line movements within and across files"), PARSE_OPT_OPTARG, blame_move_callback },
> OPT_STRING_LIST('L', NULL, &range_list, N_("n,m"), N_("Process only line range n,m, counting from 1")),
> + OPT_BIT(0, "tips", &output_option, N_("Show tips before content lines"), OUTPUT_SHOW_TIPS),
> OPT__ABBREV(&abbrev),
> OPT_END()
> };
> --
> 2.11.0.rc1
>
^ permalink raw reply
* [PATCH] blame: add option to print tips (--tips)
From: Edmundo Carmona Antoranz @ 2017-01-22 21:28 UTC (permalink / raw)
To: git; +Cc: Edmundo Carmona Antoranz
---
builtin/blame.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 126b8c9e5..4bc449f40 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1884,6 +1884,7 @@ static const char *format_time(unsigned long time, const char *tz_str,
#define OUTPUT_NO_AUTHOR 0200
#define OUTPUT_SHOW_EMAIL 0400
#define OUTPUT_LINE_PORCELAIN 01000
+#define OUTPUT_SHOW_TIPS 02000
static void emit_porcelain_details(struct origin *suspect, int repeat)
{
@@ -1939,14 +1940,18 @@ static void emit_other(struct scoreboard *sb, struct blame_entry *ent, int opt)
struct commit_info ci;
char hex[GIT_SHA1_HEXSZ + 1];
int show_raw_time = !!(opt & OUTPUT_RAW_TIMESTAMP);
+ int revision_length = (opt & OUTPUT_LONG_OBJECT_NAME) ? GIT_SHA1_HEXSZ : abbrev;
get_commit_info(suspect->commit, &ci, 1);
sha1_to_hex_r(hex, suspect->commit->object.oid.hash);
+ if (opt & OUTPUT_SHOW_TIPS)
+ printf("\t%.*s: %s\n", revision_length, hex, ci.summary.buf);
+
cp = nth_line(sb, ent->lno);
for (cnt = 0; cnt < ent->num_lines; cnt++) {
char ch;
- int length = (opt & OUTPUT_LONG_OBJECT_NAME) ? GIT_SHA1_HEXSZ : abbrev;
+ int length = revision_length;
if (suspect->commit->object.flags & UNINTERESTING) {
if (blank_boundary)
@@ -2609,6 +2614,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
{ OPTION_CALLBACK, 'C', NULL, &opt, N_("score"), N_("Find line copies within and across files"), PARSE_OPT_OPTARG, blame_copy_callback },
{ OPTION_CALLBACK, 'M', NULL, &opt, N_("score"), N_("Find line movements within and across files"), PARSE_OPT_OPTARG, blame_move_callback },
OPT_STRING_LIST('L', NULL, &range_list, N_("n,m"), N_("Process only line range n,m, counting from 1")),
+ OPT_BIT(0, "tips", &output_option, N_("Show tips before content lines"), OUTPUT_SHOW_TIPS),
OPT__ABBREV(&abbrev),
OPT_END()
};
--
2.11.0.rc1
^ permalink raw reply related
* interaction between git-diff-index and git-apply
From: Ariel Davis @ 2017-01-22 19:09 UTC (permalink / raw)
To: git
Hello,
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.
Below are steps to reproduce, as well as information about my machine, which I
discovered this behavior on.
Reproduction instructions:
$ mkdir -p test/repo
$ cd test/repo
$ git init -q
$ echo 1 > file
$ git add file
$ git commit -qm 1
$ echo 2 >> file
$ git add file
$ git commit -qm 2
$ git diff @~ > ../patch
$ git apply --reverse ../patch
$ git diff-index --name-only @
file
$ git apply ../patch
$ git diff-index --name-only @
file
$ git status
On branch master
nothing to commit, working tree clean
$ git diff-index --name-only @
$ echo hmm
hmm
System information:
$ uname -a
Darwin azdavis-mbp 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST
2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64 i386 MacBookPro12,1 Darwin
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.12.2
BuildVersion: 16C67
$ git --version
git version 2.11.0
Thank you for your time.
Ariel Davis
^ permalink raw reply
* [PATCH v3 4/4] git gui: allow for a long recentrepo list
From: Philip Oakley @ 2017-01-22 19:53 UTC (permalink / raw)
To: GitList; +Cc: Self
In-Reply-To: <20170122195301.1784-1-philipoakley@iee.org>
The gui.recentrepo list may be longer than the maxrecent setting.
Allow extra space to show any extra entries.
In an ideal world, the git gui would limit the number of entries
to the maxrecent setting, however the recentrepo config list may
have been extended outwith the gui, or the maxrecent setting changed
to a reduced value. Further, when testing the gui's recentrepo
logic it is useful to show these extra, but valid, entries.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
lib/choose_repository.tcl | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index f39636f..80f5a59 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -142,6 +142,10 @@ constructor pick {} {
-label [mc "Recent Repositories"]
}
+ if {[set lenrecent [llength $sorted_recent]] < $maxrecent} {
+ set lenrecent $maxrecent
+ }
+
${NS}::label $w_body.space
${NS}::label $w_body.recentlabel \
-anchor w \
@@ -153,7 +157,7 @@ constructor pick {} {
-background [get_bg_color $w_body.recentlabel] \
-wrap none \
-width 50 \
- -height $maxrecent
+ -height $lenrecent
$w_recentlist tag conf link \
-foreground blue \
-underline 1
--
2.9.0.windows.1.323.g0305acf
^ permalink raw reply related
* [PATCH v3 1/4] git-gui: remove duplicate entries from .gitconfig's gui.recentrepo
From: Philip Oakley @ 2017-01-22 19:52 UTC (permalink / raw)
To: GitList; +Cc: Self
In-Reply-To: <20170122195301.1784-1-philipoakley@iee.org>
The git gui's recent repo list may become contaminated with duplicate
entries. The git gui would barf when attempting to remove one entry.
Remove them all - there is no option within 'git config' to selectively
remove one of the entries.
This issue was reported on the 'Git User' list
(https://groups.google.com/forum/#!topic/git-users/msev4KsQGFc,
Warning: gui.recentrepo has multiply values while executing).
And also by zosrothko as a Git-for-Windows issue
https://github.com/git-for-windows/git/issues/1014.
On startup the gui checks that entries in the recentrepo list are still
valid repos and deletes thoses that are not. If duplicate entries are
present the 'git config --unset' will barf and this prevents the gui
from starting.
Subsequent patches fix other parts of recentrepo logic used for syncing
internal lists with the external .gitconfig.
Reported-by: Alexey Astakhov <asstv7@gmail.com>
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
lib/choose_repository.tcl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 75d1da8..133ca0a 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -247,7 +247,7 @@ proc _get_recentrepos {} {
proc _unset_recentrepo {p} {
regsub -all -- {([()\[\]{}\.^$+*?\\])} $p {\\\1} p
- git config --global --unset gui.recentrepo "^$p\$"
+ git config --global --unset-all gui.recentrepo "^$p\$"
load_config 1
}
--
2.9.0.windows.1.323.g0305acf
^ permalink raw reply related
* [PATCH v3 3/4] git gui: de-dup selected repo from recentrepo history
From: Philip Oakley @ 2017-01-22 19:53 UTC (permalink / raw)
To: GitList; +Cc: Self
In-Reply-To: <20170122195301.1784-1-philipoakley@iee.org>
When the gui/user selects a repo for display, that repo is brought to
the end of the recentrepo config list. The logic can fail if there are
duplicate old entries for the repo (you cannot unset a single config
entry when duplicates are present).
Similarly, the maxrecentrepo logic could fail if older duplicate entries
are present.
The first commit of this series ({this}~2) fixed the config unsetting
issue. Rather than manipulating a local copy of the $recent list (one
cannot know how many entries were removed), simply re-read it.
We must also catch the error when the attempt to remove the second copy
from the re-read list is performed.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
lib/choose_repository.tcl | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index aa87bcc..f39636f 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -247,7 +247,7 @@ proc _get_recentrepos {} {
proc _unset_recentrepo {p} {
regsub -all -- {([()\[\]{}\.^$+*?\\])} $p {\\\1} p
- git config --global --unset-all gui.recentrepo "^$p\$"
+ catch {git config --global --unset-all gui.recentrepo "^$p\$"}
load_config 1
}
@@ -262,12 +262,11 @@ proc _append_recentrepos {path} {
set i [lsearch $recent $path]
if {$i >= 0} {
_unset_recentrepo $path
- set recent [lreplace $recent $i $i]
}
- lappend recent $path
git config --global --add gui.recentrepo $path
load_config 1
+ set recent [get_config gui.recentrepo]
if {[set maxrecent [get_config gui.maxrecentrepo]] eq {}} {
set maxrecent 10
@@ -275,7 +274,7 @@ proc _append_recentrepos {path} {
while {[llength $recent] > $maxrecent} {
_unset_recentrepo [lindex $recent 0]
- set recent [lrange $recent 1 end]
+ set recent [get_config gui.recentrepo]
}
}
--
2.9.0.windows.1.323.g0305acf
^ permalink raw reply related
* [PATCH v3 2/4] git gui: cope with duplicates in _get_recentrepo
From: Philip Oakley @ 2017-01-22 19:52 UTC (permalink / raw)
To: GitList; +Cc: Self
In-Reply-To: <20170122195301.1784-1-philipoakley@iee.org>
_get_recentrepo will fail if duplicate invalid entries are present
in the recentrepo config list. The previous commit fixed the
'git config' limitations in _unset_recentrepo by unsetting all config
entries, however this code would fail on the second attempt to unset it.
Refactor the code to pre-sort and de-duplicate the recentrepo list to
avoid a potential second unset attempt.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
lib/choose_repository.tcl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 133ca0a..aa87bcc 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -235,14 +235,14 @@ method _invoke_next {} {
proc _get_recentrepos {} {
set recent [list]
- foreach p [get_config gui.recentrepo] {
+ foreach p [lsort -unique [get_config gui.recentrepo]] {
if {[_is_git [file join $p .git]]} {
lappend recent $p
} else {
_unset_recentrepo $p
}
}
- return [lsort $recent]
+ return $recent
}
proc _unset_recentrepo {p} {
--
2.9.0.windows.1.323.g0305acf
^ 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