* Re: How to use git show's "%<(<N>[,trunc|ltrunc|mtrunc])"?
From: Hilco Wijbenga @ 2017-02-03 17:10 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Users
In-Reply-To: <CACsJy8DjqrEZ=VaZo6bn4i2r=Wr8k4ExYv48N-rDvfPO=hqpLA@mail.gmail.com>
On 3 February 2017 at 00:06, Duy Nguyen <pclouds@gmail.com> wrote:
> On Fri, Feb 3, 2017 at 12:51 AM, Hilco Wijbenga
> <hilco.wijbenga@gmail.com> wrote:
>> Hi all,
>>
>> I'm trying to get the committer date printed in a custom fashion.
>> Using "%cI" gets me close:
>>
>> $ git show --format="%cI | %an" master | head -n 1
>> 2017-01-31T17:02:13-08:00 | Hilco Wijbenga
>>
>> I would like to get rid of the "-08:00" bit at the end of the
>> timestamp. According to the "git show" manual I should be able to use
>> "%<(<N>[,trunc|ltrunc|mtrunc])" to drop that last part.
>>
>> $ git show --format="%<(19,trunc)cI | %an" master | head -n 1
>
> You're almost there. Just insert another '%' between "trunc)" and "cI".
Thank you so much! This has been bugging me. :-) Rereading "git help
show", I guess it's implied I should do this but it very much wasn't
clear to me (obviously). I guess I'm too used to the "%19.19s" type of
approach. Maybe there should be some examples?
>> How do I get "2017-01-31T17:02:13 | Hilco Wijbenga" to be output?
>
> You'll get an ellipsis at the end though.. (i.e. 02:13... | Hilco)
Indeed, that's not very nice. I suppose I can understand the reason
for it but it mostly defeats the purpose of "trunc", doesn't it?
Luckily, Sylvie's solution does exactly what I want.
^ permalink raw reply
* Fail git pull --rebase when local merges present? (was: [ANNOUNCE] Git v2.11.1)
From: Stephen Bash @ 2017-02-03 16:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linux Kernel
On Thu, Feb 2, 2017 at 6:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> * "git pull --rebase", when there is no new commits on our side since
> we forked from the upstream, should be able to fast-forward without
> invoking "git rebase", but it didn't.
As someone who has to mentor new developers to Git at my $dayjob, this
is really nice! Thanks!
Slightly related (in that it's a pitfall of *always* using pull
--rebase), does anyone know if there is a way to make git pull
--rebase fail if there's a local merge? For our workflow I'd like to
tell new people to just default to pull --rebase, but having to add
(and explain) the "don't rebase a merge" caveat tends to lose them...
(yes we mix merge and rebase; it works for us... most of the time)
Thanks,
Stephen
^ permalink raw reply
* Re: init --separate-git-dir does not set core.worktree
From: Duy Nguyen @ 2017-02-03 13:38 UTC (permalink / raw)
To: Kyle Meyer; +Cc: Git Mailing List, Stefan Beller
In-Reply-To: <87efzg7oq3.fsf@kyleam.com>
On Thu, Feb 2, 2017 at 7:37 PM, Kyle Meyer <kyle@kyleam.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Thu, Feb 2, 2017 at 10:55 AM, Kyle Meyer <kyle@kyleam.com> wrote:
>>>
>>> As of 6311cfaf9 (init: do not set unnecessary core.worktree,
>>> 2016-09-25), "git init --separate-git-dir" no longer sets core.worktree
>>> (test below). Based on the commit message and the corresponding thread
>>> [1], I don't think this change in behavior was intentional, but I wasn't
>>> able to understand things well enough to attempt a patch.
>>
>> I'm missing some context. Why does --separate-git-dir have to set
>> core.worktree? What fails for you exactly?
>
> Sorry for not providing enough information. I haven't run into a
> failure.
>
> In Magit, we need to determine the top-level of the working tree from
> COMMIT_EDITMSG. Right now that logic [*1*] looks something like this:
This is much better :)
> * COMMIT_EDITMSG in .git/modules/<module>/: set working tree to the
> output of "git rev-parse --show-toplevel"
>
> * COMMIT_EDITMSG in .git/worktrees/<wtree>/: set working tree to the
> path in .git/worktrees/<wtree>/gitdir, minus the trailing "/.git"
>
> * COMMIT_EDITMSG in .git: set working tree to the parent directory
>
> This fails for a repo set up with --separate-git-dir [*2*], where the
> last step will go out into an unrelated repo. If core.worktree was set
> and "git rev-parse --show-toplevel" returned the working tree like it
> did for submodules, things would work.
OK. If I read this right, given a path of any text file somewhere
within ".git" directory. you are tasked to find out where the
associated worktree is? I.e. this is not an emacsclient executed as
part of "git commit", correct?
So you need some sort of back-link to ".git" location. And
unfortunately there's no such thing for .git file (unless it points to
.git/worktrees/...). I'm hesitant to set core.worktree unless it's
absolutely needed since it may have unexpected interaction with
$GIT_WORK_TREE and others (not sure if it has any interaction with
submodules too). I think adding a new file "gitdir" would be a safer
option.
I'm not entirely sure if enforcing "one worktree - one repository" is
safe though. The first two bullet points are very specific and we can
assume that, but ".git" files alone can be used for anything. In
theory you can always create a secondary worktree (that's not managed
by "git worktree") by setting GIT_WORK_TREE and "git checkout -f"
somewhere. But I guess those would be temporary and nobody would want
magic to point back to them.
As a fall-back mechanism, I think after magit has found the worktree,
it should verify the found location is the correct worktree, with "git
rev-parse --git-dir" or something, and alert the user otherwise. I
think "git rev-parse --git-path COMMIT_MSG" should give back the same
COMMIT_MSG path (and it applies for any files in .git dir, covering
all three cases). The user could add some magit-specific files to tell
magit where the actual worktree is when they hit corner cases.
If the use case is limited to editing COMMIT_EDITMSG only (after it's
generated by git), it may be best to add `pwd` as a comment to that
file. You won't have to go through all the magic rules to find it out
(*). And it helps non-magic users too.
(*) well, you do, because you probably can't expect everybody to have
latest git version.
> Of course, the issue above isn't a reason that --separate-git-dir should
> set core.worktree, but the submodule behavior is why we were wondering
> if it should.
I'm not a submodule person, so I'll pass that "why" question to Stefan.
> And so I was going to ask here whether core.worktree
> should be set, but then I confused myself into thinking 6311cfaf9
> unintentionally changed this behavior.
>
>
> [*1*] This is done by magit-toplevel:
> https://github.com/magit/magit/blob/e34f4e8eb00f292e8c475489fa7caa286857a421/lisp/magit-git.el#L400
>
> [*2*] https://github.com/magit/magit/issues/2955
> https://github.com/magit/magit/issues/2981
--
Duy
^ permalink raw reply
* Re: [PATCH] document behavior of empty color name
From: Jeff King @ 2017-02-03 12:29 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Junio C Hamano, git
In-Reply-To: <20170203092430.GA10987@ash>
On Fri, Feb 03, 2017 at 04:24:30PM +0700, Duy Nguyen wrote:
> > I don't think so. The default value is a git-config thing, but you would
> > want to be able to do the same thing in a config file. For example, to
> > disable coloring entirely for part of the diff, you could do:
> >
> > [color "diff"]
> > meta = ""
>
> OK but it makes log.graphColors add empty colors though. In t4202.39,
> we have " blue,invalid-color, cyan, red , ". With this patch the color
> after red would be no color. Without it, we get a complaint and the
> next color would be cycled back to blue. The test does not catch this
> because the test graph does not have enough fork points to get to red
> and back to blue.
Right, I think that's the correct behavior. The empty color name is a
real color ("none"), and you can put it in your list just like any other
color.
It's possible that somebody would like to use the sort of "hanging
comma" behavior that people do with lists that might be added to later
(e.g., for enums in C).
IMHO that would be best handled by having the list-parsing code drop
trailing empty entries. But I don't think this special case is worth
supporting, if only for the mental complexity it adds to the user.
-Peff
^ permalink raw reply
* Re: git-scm.com status report
From: Jeff King @ 2017-02-03 12:08 UTC (permalink / raw)
To: pedro rijo; +Cc: sxlijin, e, git
In-Reply-To: <16F9F83D-5A7F-4059-9A27-DB25A8FB1E99@gmail.com>
On Thu, Feb 02, 2017 at 10:01:45PM +0000, pedro rijo wrote:
> While I’m not experienced with Rails apps, I would like to give my
> contribution to the Git project. I could help doing some kind of
> triage, removing abusing PRs/issues (like
> https://github.com/git/git-scm.com/pull/557
> <https://github.com/git/git-scm.com/pull/557>), looking for typos and
> other tasks that wouldn’t require a lot of RoR knowledge to get start.
> Also, completely free and available to start digging into the RoR
> stuff of course!
Thanks! I think a good first step is just to start watching the
repository and jump in on issues where you think you can contribute.
Clicking "close" or "merge" on an issue is something only I can do for
now, but having a group of people reviewing and responding to issues and
PRs is a big help (so I _can_ just click those buttons). And then
over time hopefully we can grow a stable of reviewers, and hand out
repo privileges to the active ones.
-Peff
^ permalink raw reply
* Re: git-scm.com status report
From: Jeff King @ 2017-02-03 11:58 UTC (permalink / raw)
To: Samuel Lijin; +Cc: Eric Wong, git@vger.kernel.org
In-Reply-To: <CAJZjrdUGsp5-HsA0Hxk4Qo+2s6crLbu-LuX=ECuC2QpM6HCWgg@mail.gmail.com>
On Thu, Feb 02, 2017 at 12:54:53AM -0600, Samuel Lijin wrote:
> In theory, you could also dump the build artifacts to a GH Pages repo
> and host it from there, although I don't know if you would run up
> against any of the usage limits[0]. The immediate problem I see with
> that approach, though, is that I have no idea how any of the dynamic
> stuff (e.g. search) would be replaced.
I've talked with Pages people and they say it shouldn't be a big deal to
host. The main issue is that it's not _just_ a static site. It's a site
that's static once built, but a lot of the content is auto-generated
from other sources (git manpages, Pro Git and its translations, etc).
So there's work involved in moving that generation step to whatever the
new process is (it's fine if it's running "make" locally after a Git
release and pushing up the result).
> A question: there's a DB schema in there. Does the site still use a DB?
It does use the database to hold all of the bits that aren't checked
into Git. So renderings of the manpages, the latest release git version,
etc. AFAIK, it's all things that I would be comfortable committing into
a git repository.
-Peff
^ permalink raw reply
* [PATCH v2 0/7] completion bash: add more options and commands
From: cornelius.weig @ 2017-02-03 11:01 UTC (permalink / raw)
To: git; +Cc: szeder.dev, j6t, Cornelius Weig
From: Cornelius Weig <cornelius.weig@tngtech.com>
This is the re-roll of patch series <20170122225724.19360-1-cornelius.weig@tngtech.com>.
This patch series adds all long-options that are mentioned in the synopsis of
the man-page for the respective git-command. There are only a few exceptions,
as discussed in the above thread. For example, no unsafe options should be
completed.
Furthermore, the patches add subommand option completion for git-submodule and
git-remote.
Changes wrt first submission:
- improve completion for git-remote set-head & set-branches
- remove completion of unsafe options
- improve commit messages
- added sign-off :)
- rebase to current master
Cornelius Weig (7):
completion: teach submodule subcommands to complete options
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 to complete options
completion: recognize more long-options
contrib/completion/git-completion.bash | 139 ++++++++++++++++++++++++++++-----
1 file changed, 118 insertions(+), 21 deletions(-)
Interdiff since first iteration:
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 87d3d2c..3545f6a 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -936,7 +936,7 @@ _git_apply ()
--apply --no-add --exclude=
--ignore-whitespace --ignore-space-change
--whitespace= --inaccurate-eof --verbose
- --recount --directory= --unsafe-paths
+ --recount --directory=
"
return
esac
@@ -1459,7 +1459,7 @@ _git_ls_remote ()
{
case "$cur" in
--*)
- __gitcomp "--heads --tags --refs --get-url"
+ __gitcomp "--heads --tags --refs --get-url --symref"
return
;;
esac
@@ -2415,9 +2415,18 @@ _git_remote ()
;;
add,*)
;;
+ set-head,--*)
+ __gitcomp "--auto --delete"
+ ;;
+ set-branches,--*)
+ __gitcomp "--add"
+ ;;
set-head,*|set-branches,*)
__git_complete_remote_or_refspec
;;
+ update,--*)
+ __gitcomp "--prune"
+ ;;
update,*)
__gitcomp "$(__git_get_config_variables "remotes")"
;;
@@ -2494,7 +2503,7 @@ _git_rm ()
{
case "$cur" in
--*)
- __gitcomp "--cached --dry-run --ignore-unmatch --quiet --force"
+ __gitcomp "--cached --dry-run --ignore-unmatch --quiet"
return
;;
esac
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/7] completion: add subcommand completion for rerere
From: cornelius.weig @ 2017-02-03 11:01 UTC (permalink / raw)
To: git; +Cc: szeder.dev, j6t, Cornelius Weig
In-Reply-To: <20170203110159.377-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.
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
---
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 v2 1/7] completion: teach submodule subcommands to complete options
From: cornelius.weig @ 2017-02-03 11:01 UTC (permalink / raw)
To: git; +Cc: szeder.dev, j6t, Cornelius Weig
In-Reply-To: <20170203110159.377-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
Each submodule subcommand has specific long-options. Therefore, teach
bash completion to support option completion based on the current
subcommand. All long-options that are mentioned in the man-page synopsis
are added.
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
---
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 v2 6/7] completion: teach remote subcommands to complete options
From: cornelius.weig @ 2017-02-03 11:01 UTC (permalink / raw)
To: git; +Cc: szeder.dev, j6t, Cornelius Weig
In-Reply-To: <20170203110159.377-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
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 45 ++++++++++++++++++++++++++++------
1 file changed, 38 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 4841036..d8960cf 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2384,24 +2384,55 @@ _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="
+ ;;
+ add,*)
+ ;;
+ set-head,--*)
+ __gitcomp "--auto --delete"
;;
- set-head|set-branches)
+ set-branches,--*)
+ __gitcomp "--add"
+ ;;
+ set-head,*|set-branches,*)
__git_complete_remote_or_refspec
;;
- update)
+ update,--*)
+ __gitcomp "--prune"
+ ;;
+ 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 v2 5/7] completion: teach replace to complete options
From: cornelius.weig @ 2017-02-03 11:01 UTC (permalink / raw)
To: git; +Cc: szeder.dev, j6t, Cornelius Weig
In-Reply-To: <20170203110159.377-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.
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
---
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 a355eeb..4841036 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 v2 7/7] completion: recognize more long-options
From: cornelius.weig @ 2017-02-03 11:01 UTC (permalink / raw)
To: git; +Cc: szeder.dev, j6t, Cornelius Weig
In-Reply-To: <20170203110159.377-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
Command completion only recognizes a subset of the available options for
the various git commands. The set of recognized options needs to balance
between having all useful options and to not clutter the terminal.
This commit adds all long-options that are mentioned in the man-page
synopsis of the respective git command. Possibly dangerous options are
not included in this set, to avoid accidental data loss. The added
options are:
- apply: --recount --directory=
- archive: --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: --keep
- revert: --strategy= --strategy-option=
- shortlog: --email
- tag: --merged --no-merged --create-reflog
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Helped-by: Johannes Sixt <j6t@kdbg.org>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
---
contrib/completion/git-completion.bash | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d8960cf..3545f6a 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=
"
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
@@ -2465,7 +2473,7 @@ _git_reset ()
case "$cur" in
--*)
- __gitcomp "--merge --mixed --hard --soft --patch"
+ __gitcomp "--merge --mixed --hard --soft --patch --keep"
return
;;
esac
@@ -2481,7 +2489,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
@@ -2509,7 +2520,7 @@ _git_shortlog ()
__gitcomp "
$__git_log_common_options
$__git_log_shortlog_options
- --numbered --summary
+ --numbered --summary --email
"
return
;;
@@ -2787,8 +2798,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 v2 4/7] completion: teach ls-remote to complete options
From: cornelius.weig @ 2017-02-03 11:01 UTC (permalink / raw)
To: git; +Cc: szeder.dev, j6t, Cornelius Weig
In-Reply-To: <20170203110159.377-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, --get-url, and --symref.
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
---
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..a355eeb 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 --symref"
+ return
+ ;;
+ esac
__gitcomp_nl "$(__git_remotes)"
}
--
2.10.2
^ permalink raw reply related
* [PATCH v2 3/7] completion: improve bash completion for git-add
From: cornelius.weig @ 2017-02-03 11:01 UTC (permalink / raw)
To: git; +Cc: szeder.dev, j6t, Cornelius Weig
In-Reply-To: <20170203110159.377-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
Command completion for git-add did not recognize some long-options.
This commits adds completion for all long-options that are mentioned in
the man-page synopsis. In addition, if the user specified `--update` or
`-u`, path completion will only suggest modified tracked files.
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com>
---
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
* Re: mergetool and difftool inconsistency?
From: David Aguilar @ 2017-02-03 10:32 UTC (permalink / raw)
To: Denton Liu; +Cc: git
In-Reply-To: <20170126025810.GA3020@arch-attack.localdomain>
On Wed, Jan 25, 2017 at 06:58:10PM -0800, Denton Liu wrote:
> Hello all,
>
> I was wondering if there is any reason why 'git difftool' accepts the
> '-g|--gui' whereas 'git mergetool' does not have an option to accept
> that flag. Please let me know if this is intentional, otherwise I can
> write up a patch to add the GUI flag to 'mergetool'.
>
> Thanks!
Hello,
The difference was not intentional. The "--gui" feature was
added to difftool because that's where the feature was
originally requested, but there's no reason why mergetool
couldn't have a similar option.
cheers,
--
David
^ permalink raw reply
* Re: [PATCH] document behavior of empty color name
From: Duy Nguyen @ 2017-02-03 9:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20170202124238.53k74cedpp2rcmzo@sigill.intra.peff.net>
On Thu, Feb 02, 2017 at 01:42:44PM +0100, Jeff King wrote:
> On Thu, Feb 02, 2017 at 04:16:15PM +0700, Duy Nguyen wrote:
>
> > > I hadn't heard anything back,
> >
> > Sorry I was accidentally busy during Luna new year holiday.
>
> No problem. That sounds much more fun than working on Git. :)
>
> > > - if (!len)
> > > - return -1;
> > > + if (!len) {
> > > + dst[0] = '\0';
> > > + return 0;
> > > + }
> > >
> > > if (!strncasecmp(ptr, "reset", len)) {
> > > xsnprintf(dst, end - dst, GIT_COLOR_RESET);
> >
> > I wonder if it makes more sense to do this in builtin/config.c. The
> > "default value" business is strictly git-config command's. The parsing
> > function does not need to know. Maybe something like this?
>
> I don't think so. The default value is a git-config thing, but you would
> want to be able to do the same thing in a config file. For example, to
> disable coloring entirely for part of the diff, you could do:
>
> [color "diff"]
> meta = ""
OK but it makes log.graphColors add empty colors though. In t4202.39,
we have " blue,invalid-color, cyan, red , ". With this patch the color
after red would be no color. Without it, we get a complaint and the
next color would be cycled back to blue. The test does not catch this
because the test graph does not have enough fork points to get to red
and back to blue.
I suppose this is ok after your documentation patch ("that's by
design!"). Just wanted to point it out in case I miss something.
--
Duy
^ permalink raw reply
* [ANNOUNCE] Git for Windows 2.11.1
From: Johannes Schindelin @ 2017-02-03 9:19 UTC (permalink / raw)
To: git-for-windows, git; +Cc: Johannes Schindelin
MIME-Version: 1.0
Fcc: Sent
Dear Git users,
It is my pleasure to announce that Git for Windows 2.11.1 is available from:
https://git-for-windows.github.io/
Changes since Git for Windows v2.11.0(3) (January 14th 2017)
New Features
• Comes with Git v2.11.1.
• Performance was enhanced when using fscache in a massively sparse
checkout.
• Git hooks can now be .exe files.
Bug Fixes
• Git GUI will no longer set GIT_DIR when calling Git Bash after
visualizing the commit history.
• When the PATH contains UNC entries, Git Bash will no longer error
out with a "Bad address" error message.
Filename | SHA-256
-------- | -------
Git-2.11.1-64-bit.exe | 2c6408f98297b8f4ad0df36f3aabab67164b3b3d7bb3d91d49f237aba566f8ac
Git-2.11.1-32-bit.exe | a556c6f65c13f54dcce64df96bbc94a156bb7c9025a27cf0caa329648adaac06
PortableGit-2.11.1-64-bit.7z.exe | 47058bbfb815ec3e9247b96aedcaea21df58db59c3a73594ffcbd4171ac2cb11
PortableGit-2.11.1-32-bit.7z.exe | 2f76bed9b649d990cf6999674e11e6cf5d502d25b89072b34c984f6aa86dafbb
MinGit-2.11.1-64-bit.zip | 668d16a799dd721ed126cc91bed49eb2c072ba1b25b50048280a4e2c5ed56e59
MinGit-2.11.1-32-bit.zip | 6ca79af09015625f350ef4ad74a75cfb001b340aec095b6963be9d45becb3bba
Git-2.11.1-64-bit.tar.bz2 | 06b066c7a3f1934d96f2a838b64cbf1aced8578e5321bf6ff0e7bd65e6c34988
Git-2.11.1-32-bit.tar.bz2 | f06e3d78ca25ae8def8dac3e584912c74d0d819966772dfb965d78e1e462f0b0
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH] reset: add an example of how to split a commit into two
From: Duy Nguyen @ 2017-02-03 9:05 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git Mailing List, Jacob Keller
In-Reply-To: <20170203003038.22278-1-jacob.e.keller@intel.com>
On Fri, Feb 3, 2017 at 7:30 AM, Jacob Keller <jacob.e.keller@intel.com> wrote:
> From: Jacob Keller <jacob.keller@gmail.com>
>
> It is sometimes useful to break a commit into parts to more logically
> show how the code changes. There are many possible ways to achieve this
> result, but one simple and powerful one is to use git reset -p.
>
> Add an example to the documentation showing how this can be done so that
> users are more likely to discover this, instead of inventing more
> painful methods such as re-writing code from scratch, or duplicating git
> add -p more times than necessary.
>
> Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
> ---
> Documentation/git-reset.txt | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
> index 25432d9257f9..4adac7a25bf9 100644
> --- a/Documentation/git-reset.txt
> +++ b/Documentation/git-reset.txt
> @@ -292,6 +292,29 @@ $ git reset --keep start <3>
> <3> But you can use "reset --keep" to remove the unwanted commit after
> you switched to "branch2".
>
> +Split a commit into two::
> ++
> +Suppose that you have created a commit, but later decide that you want to split
> +the changes into two separate commits, including only part of the old commit
> +into the first commit, and including the rest as a separate commit on top. You
> +can use git reset in patch mode to interactively select which hunks to split
> +out into a separate commit.
> ++
> +------------
> +$ git reset -p HEAD^ <1>
For good practice, perhaps put "git diff --cached HEAD^" before "git commit".
I tend to avoid "reset -p" and "checkout -p" though because sometimes
it does not work. Not sure if it's just me, I think it may have
something to do with splitting hunks. So I usually go with "reset
HEAD^" then "add -p" and "commit -c HEAD@{1}" instead.
> +$ git commit --amend <2>
> +$ git commit ... <3>
> +------------
> ++
> +<1> This lets you interactively undo changes between HEAD^ and HEAD, so you can
> + select which parts to remove from the initial commit. The changes are
> + placed into the index, leaving the working tree untouched.
> +<2> Now, you ammend the initial commit with the modifications that you just
s/ammend/amend/
> + made in the index.
> +<3> Finally, you can add and then commit the final original unmodified files
> + back as the second commit, enabling you to logically separate a commit
> + into a sequence of two commits instead.
--
Duy
^ permalink raw reply
* Re: [PATCH 00/11] nd/worktree-move update
From: Duy Nguyen @ 2017-02-03 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <xmqqmve4s5r2.fsf@gitster.mtv.corp.google.com>
On Fri, Feb 3, 2017 at 3:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> Also, the more important reply was Peff's reply that suggested that the
>> proposed fix was incomplete, as it misses --unpack-unreachable:
>> https://public-inbox.org/git/20160601160143.GA9219@sigill.intra.peff.net/
>
> While I think that --unpack-unreachable thing is a symptom of the
> basic approach of patching things up at the wrong level, if you are
> hinting that fix to the issue that gc does not pay attention to
> various anchoring point in other worktrees is more important than
> adding new commands to "worktree", I fully agree with that.
Just to make it clear. It's not like I put new worktree commands on
higher priority. "worktree move/remove" was more or less ready for a
long time and the gc problem was blocked by ref-iterator series (which
entered master a few moths ago, but then I was busy with other things
and couldn't get right back to the gc issue).
You didn't answer Johannes's rhetoric question though: "It should be
possible to do that redesign work while having a small workaround in
place that unbreaks, say, me?"
I assume "the right way" is still updating refs subsystem so that we
can have a ref iterator to traverse all refs, or just one worktree,
etc. Should I keep looking for a middle ground (maybe better than the
linked series) to "unbreak Johannes"? I ignored all those comments
(about --unpack-reachable and bisect refs) because I saw no chance of
an updated series getting in git.git anyway.
--
Duy
^ permalink raw reply
* Re: How to use git show's "%<(<N>[,trunc|ltrunc|mtrunc])"?
From: Duy Nguyen @ 2017-02-03 8:06 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi0-8JnnZbdm9vu1RwTU1mXr7dboLC3ito3LcvK9gkNi_A@mail.gmail.com>
On Fri, Feb 3, 2017 at 12:51 AM, Hilco Wijbenga
<hilco.wijbenga@gmail.com> wrote:
> Hi all,
>
> I'm trying to get the committer date printed in a custom fashion.
> Using "%cI" gets me close:
>
> $ git show --format="%cI | %an" master | head -n 1
> 2017-01-31T17:02:13-08:00 | Hilco Wijbenga
>
> I would like to get rid of the "-08:00" bit at the end of the
> timestamp. According to the "git show" manual I should be able to use
> "%<(<N>[,trunc|ltrunc|mtrunc])" to drop that last part.
>
> $ git show --format="%<(19,trunc)cI | %an" master | head -n 1
You're almost there. Just insert another '%' between "trunc)" and "cI".
> How do I get "2017-01-31T17:02:13 | Hilco Wijbenga" to be output?
You'll get an ellipsis at the end though.. (i.e. 02:13... | Hilco)
--
Duy
^ permalink raw reply
* Re: difflame
From: Edmundo Carmona Antoranz @ 2017-02-03 4:47 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git List
In-Reply-To: <CAOc6etabV=h6fEVee=N2-3ERUU7_w6eCM006mSMPqiwkRycQBw@mail.gmail.com>
On Thu, Feb 2, 2017 at 10:46 PM, Edmundo Carmona Antoranz
<eantoranz@gmail.com> wrote:
> I have been "scripting around git blame --reverse" for some days now.
> Mind taking a look? I've been working on blame-deletions for this.
blame-deletions branch, that is
Sorry for the previous top-posting.
^ permalink raw reply
* Re: difflame
From: Edmundo Carmona Antoranz @ 2017-02-03 4:46 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git List
In-Reply-To: <CAOc6etYzAeD32oSjrvmv-PBJTdAGobsQ30iH8Q+Z9ShWOqiHfQ@mail.gmail.com>
I have been "scripting around git blame --reverse" for some days now.
Mind taking a look? I've been working on blame-deletions for this.
22:41 $ ../difflame/difflame.py HEAD~5 HEAD
diff --git a/file b/file
index b414108..051c298 100644
--- a/file
+++ b/file
@@ -1,6 +1,9 @@
^1513353 (Edmundo 2017-02-02 22:41:45 -0600 1) 1
f20952eb (Edmundo 2017-02-02 22:41:45 -0600 2) 2
bb04dc7c (Edmundo 2017-02-02 22:41:45 -0600 3) 3
-de3c07b (Edmundo 2017-02-02 22:41:47 -060 4) 4
058ea125 (Edmundo 2017-02-02 22:41:45 -0600 4) 5
85fc6b81 (Edmundo 2017-02-02 22:41:45 -0600 5) 6
+2cd990a6 (Edmundo 2017-02-02 22:41:45 -0600 6) 7
+ab0be970 (Edmundo 2017-02-02 22:41:45 -0600 7) 8
+944452c0 (Edmundo 2017-02-02 22:41:45 -0600 8) 9
+6641edb0 (Edmundo 2017-02-02 22:41:45 -0600 9) 10
$ git show de3c07b
commit de3c07bc21a83472d5c5ddf172dcb742665924dd (HEAD -> master)
Author: Edmundo <eantoranz@gmail.com>
Date: Thu Feb 2 22:41:47 2017 -0600
drop 4
diff --git a/file b/file
index f00c965..051c298 100644
--- a/file
+++ b/file
@@ -1,7 +1,6 @@
1
2
3
-4
5
6
7
Next step: solve the
find-real-deletion-revision-when-there-are-multiple-child-nodes
problem.... and let me read the discussion around git blame --reverse.
Thanks in advance.
On Mon, Jan 30, 2017 at 8:37 PM, Edmundo Carmona Antoranz
<eantoranz@gmail.com> wrote:
> Maybe a little work on blame to get the actual revision where some
> lines were "deleted"?
>
> Something like git blame --blame-deletion that could be based on --reverse?
>
> On Mon, Jan 30, 2017 at 7:35 PM, Edmundo Carmona Antoranz
> <eantoranz@gmail.com> wrote:
>> I'm thinking of something like this:
>>
>> Say I just discovered a problem in a file.... I want to see who worked
>> on it since some revision that I know is working fine (or even
>> something as generic as HEAD~100..). It could be a number of people
>> with different revisions. I would diff to see what changed.... and
>> blame the added lines (blame reverse to try to get as close as
>> possible with a single command in case I want to see what happened
>> with something that was deleted). If I could get blame information of
>> added/deleted lines in a single run, that would help a lot.
>>
>> Lo and behold: difflame.
>>
>>
>>
>> On Mon, Jan 30, 2017 at 5:26 PM, Jeff King <peff@peff.net> wrote:
>>> On Mon, Jan 30, 2017 at 01:08:41PM -0800, Junio C Hamano wrote:
>>>
>>>> Jeff King <peff@peff.net> writes:
>>>>
>>>> > On Tue, Jan 17, 2017 at 11:24:02PM -0600, Edmundo Carmona Antoranz wrote:
>>>> >
>>>> >> For a very long time I had wanted to get the output of diff to include
>>>> >> blame information as well (to see when something was added/removed).
>>>> >
>>>> > This is something I've wanted, too. The trickiest part, though, is
>>>> > blaming deletions, because git-blame only tracks the origin of content,
>>>> > not the origin of a change.
>>>>
>>>> Hmph, this is a comment without looking at what difflame does
>>>> internally, so you can ignore me if I am misunderstood what problem
>>>> you are pointing out, but I am not sure how "tracks the origin of
>>>> content" could be a problem.
>>>>
>>>> If output from "git show" says this:
>>>>
>>>> --- a/file
>>>> +++ b/file
>>>> @@ -1,5 +1,6 @@
>>>> a
>>>> b
>>>> -c
>>>> +C
>>>> +D
>>>> d
>>>> e
>>>>
>>>> in order to annotate lines 'a', 'b', 'd', and 'e' for their origin,
>>>> you would run 'blame' on the commit the above output was taken from
>>>> (or its parent---they are in the context so either would be OK).
>>>>
>>>> You know where 'C' and 'D' came from already. It's the commit you
>>>> are feeding "git show".
>>>
>>> I think the point (or at least as I understand it) is that the diff is
>>> not "git show" for a particular commit. It could be part of a much
>>> larger diff that covers many commits.
>>>
>>> As a non-hypothetical instance, I have a fork of git.git that has
>>> various enhancements. I want to feed those enhancements upstream. I need
>>> to know which commits should be cherry-picked to get those various
>>> enhancements.
>>>
>>> Looking at "log origin..fork" tells me too many commits, because it
>>> includes ones which aren't useful anymore. Either because they already
>>> went upstream, or because they were cherry-picked to the fork and their
>>> upstream counterparts merged (or even equivalent commits made upstream
>>> that obsoleted the features).
>>>
>>> Looking at "git diff origin fork" tells me what the actual differences
>>> are, but it doesn't show me which commits are responsible for them.
>>>
>>> I can "git blame" each individual line of the diff (starting with "fork"
>>> as the tip), but that doesn't work for lines that no longer exist (i.e.,
>>> when the interesting change is a deletion).
>>>
>>>> In order to run blame to find where 'c' came from, you need to start
>>>> at the _parent_ of the commit the above output came from, and the
>>>> hunk header shows which line range to find the final 'c'.
>>>
>>> So perhaps that explains my comment more. "blame" is not good for
>>> finding which commit took away a line. I've tried using "blame
>>> --reverse", but it shows you the parent of the commit you are looking
>>> for, which is slightly annoying. :)
>>>
>>> "git log -S" is probably a better tool for finding that.
>>>
>>> -Peff
^ permalink raw reply related
* Re: How to use git show's "%<(<N>[,trunc|ltrunc|mtrunc])"?
From: Hilco Wijbenga @ 2017-02-03 4:32 UTC (permalink / raw)
To: G. Sylvie Davies; +Cc: Git Users
In-Reply-To: <CAAj3zPz8wFc_5dRmM=-jMnqp6a7fGtc4XSyU5meF6mO5me47Dw@mail.gmail.com>
On 2 February 2017 at 20:19, G. Sylvie Davies <sylvie@bit-booster.com> wrote:
> On Thu, Feb 2, 2017 at 9:51 AM, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>> Hi all,
>>
>> I'm trying to get the committer date printed in a custom fashion.
>> Using "%cI" gets me close:
>>
>> $ git show --format="%cI | %an" master | head -n 1
>> 2017-01-31T17:02:13-08:00 | Hilco Wijbenga
>>
>> I would like to get rid of the "-08:00" bit at the end of the
>> timestamp. According to the "git show" manual I should be able to use
>> "%<(<N>[,trunc|ltrunc|mtrunc])" to drop that last part.
>>
>> $ git show --format="%<(19,trunc)cI | %an" master | head -n 1
>> cI | Hilco Wijbenga
>>
>> Mmm, it seems to be recognized as a valid "something" but it's not
>> working as I had expected. :-) I tried several other versions of this
>> but no luck. Clearly, I'm misunderstanding the format description. How
>> do I get "2017-01-31T17:02:13 | Hilco Wijbenga" to be output?
>>
>
> Will this work for you?
>
> $ git show -s --pretty='%cd | %an' --date=format:%FT%R:%S
> 2017-02-02T10:01:36 | G. Sylvie Davies
Ah, that does indeed do exactly what I want. Thank you.
> I have no idea how portable this might be. As "git help log" says:
>
> --date=format:... feeds the format ... to your system
> strftime. Use --date=format:%c to show the date in your system
> locale’s preferred format. See the strftime manual for a complete list
> of format placeholders.
It should be fine for my purposes.
Any idea why "%<(19,trunc)cl" doesn't work? (Your solution solves my
original problem perfectly but I'd like to understand how I'm
misreading the spec.)
^ permalink raw reply
* Re: How to use git show's "%<(<N>[,trunc|ltrunc|mtrunc])"?
From: G. Sylvie Davies @ 2017-02-03 4:19 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi0-8JnnZbdm9vu1RwTU1mXr7dboLC3ito3LcvK9gkNi_A@mail.gmail.com>
On Thu, Feb 2, 2017 at 9:51 AM, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> Hi all,
>
> I'm trying to get the committer date printed in a custom fashion.
> Using "%cI" gets me close:
>
> $ git show --format="%cI | %an" master | head -n 1
> 2017-01-31T17:02:13-08:00 | Hilco Wijbenga
>
> I would like to get rid of the "-08:00" bit at the end of the
> timestamp. According to the "git show" manual I should be able to use
> "%<(<N>[,trunc|ltrunc|mtrunc])" to drop that last part.
>
> $ git show --format="%<(19,trunc)cI | %an" master | head -n 1
> cI | Hilco Wijbenga
>
> Mmm, it seems to be recognized as a valid "something" but it's not
> working as I had expected. :-) I tried several other versions of this
> but no luck. Clearly, I'm misunderstanding the format description. How
> do I get "2017-01-31T17:02:13 | Hilco Wijbenga" to be output?
>
Will this work for you?
$ git show -s --pretty='%cd | %an' --date=format:%FT%R:%S
2017-02-02T10:01:36 | G. Sylvie Davies
I have no idea how portable this might be. As "git help log" says:
--date=format:... feeds the format ... to your system
strftime. Use --date=format:%c to show the date in your system
locale’s preferred format. See the strftime manual for a complete list
of format placeholders.
- Sylvie
^ permalink raw reply
* Re: [PATCH 00/12] completion: speed up refs completion
From: Jacob Keller @ 2017-02-03 4:15 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Git mailing list
In-Reply-To: <20170203025405.8242-1-szeder.dev@gmail.com>
On Thu, Feb 2, 2017 at 6:53 PM, SZEDER Gábor <szeder.dev@gmail.com> wrote:
> This series speeds up refs completion for large number of refs, partly
> by giving up disambiguating ambiguous refs (patch 6) and partly by
> eliminating most of the shell processing between 'git for-each-ref'
> and 'ls-remote' and Bash's completion facility. The rest is a bit of
> preparatory reorganization, cleanup and bugfixes.
>
> The last patch touches the ZSH wrapper, too. By a lucky educated
> guess I managed to get it work on the first try, but I don't really
> know what I've actually done, so... ZSH users, please have a closer
> look.
>
> At the end of this series refs completion from a local repository is
> as fast as it can possibly get, at least as far as the completion
> script is concerned, because it basically does nothing anymore :) All
> it does is run 'git for-each-ref' with assorted options to do all the
> work, and feed its output directly, without any processing into Bash's
> COMPREPLY array. There is still room for improvements in the code
> paths using 'git ls-remote', but for that we would need enhancements
> to 'ls-remote'.
>
> It goes on top of the __gitdir() improvements series I just posted at:
>
> http://public-inbox.org/git/20170203024829.8071-1-szeder.dev@gmail.com/T/
>
> This series is also available at:
>
> https://github.com/szeder/git completion-refs-speedup
>
Nice! This is something i've been bothered by in the past since
completion would take a rather long time!
Regards,
Jake
^ 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