Re: [PATCH on master v2] revision: use commit graph in get_reference()
Jonathan Tan writes:
> When fetching into a repository, a connectivity check is first made by
> check_exist_and_connected() in builtin/fetch.c that runs:
> ...
> Another way to accomplish this effect would be to modify parse_object()
> to use the commit graph if possible; however, I did not want to change
> parse_object()'s current behavior of always checking the object
> signature of the returned object.
Sounds good.
> Signed-off-by: Jonathan Tan
> ---
> This patch is now on master.
OK.
Obviously that won't apply to the base for v1 without conflicts, and
it of course applies cleanly on 'master', but the result of doing so
will cause the same conflicts when sb/more-repo-in-api is merged on
top, which means that the same conflicts need to be resolved if this
wants to be merged to 'next' (or 'pu', FWIW).
> diff --git a/commit-graph.c b/commit-graph.c
> index 40c855f185..a571b523b7 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -374,24 +375,41 @@ static int find_commit_in_graph(struct commit *item,
> struct commit_graph *g, uin
> }
> }
>
> -static int parse_commit_in_graph_one(struct commit_graph *g, struct commit
> *item)
> +static struct commit *parse_commit_in_graph_one(struct repository *r,
> + struct commit_graph *g,
> + struct commit *shell,
> + const struct object_id *oid)
Now the complexity of the behaviour of this function deserves to be
documented in a comment in front. Let me see if I can get it
correctly without such a comment by explaining the function aloud.
The caller may or may not have already obtained an in-core commit
object for a given object name, so shell could be NULL but otherwise
it could be used for optimization. When shell==NULL, the function
looks up the commit object using the oid parameter instead. The
returned in-core commit has the parents etc. filled as if we ran
parse_commit() on it. If the commit is not yet in the graph, the
caller may get a NULL even if the commit exists.
> {
> uint32_t pos;
>
> - if (item->object.parsed)
> - return 1;
> + if (shell && shell->object.parsed)
> + return shell;
>
> - if (find_commit_in_graph(item, g, &pos))
> - return fill_commit_in_graph(item, g, pos);
> + if (shell && shell->graph_pos != COMMIT_NOT_FROM_GRAPH) {
> + pos = shell->graph_pos;
> + } else if (bsearch_graph(g, shell ? &shell->object.oid : oid, &pos)) {
> + /* bsearch_graph sets pos */
Please spell an empty statement like so:
; /* comment */
> + } else {
> + return NULL;
We come here when the commit (either came from shell or from oid) is
not found by bsearch_graph(). "Is the caller prepared for it, and
how?" is a natural question a reader would have. Let's read on.
> + }
>
> - return 0;
> + if (!shell) {
> + shell = lookup_commit(r, oid);
> + if (!shell)
> + return NULL;
> + }
> +
> + fill_commit_in_graph(shell, g, pos);
> + return shell;
> }
>
> -int parse_commit_in_graph(struct repository *r, struct commit *item)
> +struct commit *parse_commit_in_graph(struct repository *r, struct commit
> *shell,
> + const struct object_id *oid)
> {
> if (!prepare_commit_graph(r))
> return 0;
> - return parse_commit_in_graph_one(r->objects->commit_graph, item);
> + return parse_commit_in_graph_one(r, r->objects->commit_graph, shell,
> + oid);
> }
>
> void load_commit_graph_info(struct repository *r, struct commit *item)
> @@ -1025,7 +1043,7 @@ int verify_commit_graph(struct repository *r, struct
> commit_graph *g)
> }
>
> graph_commit = lookup_commit(r, &cur_oid);
> - if (!parse_commit_in_graph_one(g, graph_commit))
> + if (!parse_commit_in_graph_one(r, g, graph_commit, NULL))
> graph_report("failed to parse %s from commit-graph",
>oid_to_hex(&cur_oid));
> }
> diff --git a/commit-graph.h b/commit-graph.h
> index 9db40b4d3a..8b7b5985dc 100644
> --- a/commit-graph.h
> +++ b/commit-graph.h
> @@ -13,16 +13,20 @@ struct commit;
> char *get_commit_graph_filename(const char *obj_dir);
>
> /*
> - * Given a commit struct, try to fill the commit struct info, including:
> + * If the given commit (identified by shell->object.oid or oid) is in the
> + * commit graph, returns a commit struct (reusing shell if it is not NULL)
> + * including the following info:
> * 1. tree object
> * 2. date
> * 3. parents.
> *
> - * Returns 1 if and only if the commit was found in the packed graph.
> + * If not, returns NULL. See parse_commit_buffer() for the fallback after
> this
> + * call.
> *
> - * See parse_commit_bu
Re: Bug: git add --patch does not honor "diff.noprefix"
Christian Weiske writes: > When running "git add -p" on git version 2.19.2 and "diff.noprefix" set > to true, it still shows the "a/" and "b/" prefixes. > > This issue has been reported in 2016 already[1], but is still there in > 2.19.2. It is very likely because it is a non-issue. The reason why prefixes are customizable is to match the convention used to show your patch to others, but the patch to be immediately consumed within an "add -i/-p" session is viewed only by the user, so it is much much lower priority to change the code. I guess the reason why no such change was made is because nobody felt it worth the trouble to change the code to use a non-standard prefix when producing the patch to be shown, and then also change the code to accept a non-standard prefix when using the chosen patch to be applied.
Re: [PATCH] terminology tweak: prune -> path limiting
Matthew DeVore writes: > In the codebase, "prune" is a highly overloaded term, and it caused me a > lot of trouble to figure out what it meant when it was used in the > context of path limiting. Stop using the word "prune" when we really > mean "path limiting." path limiting is also used for two purposes. "pruning", which is to cull the side branches that do not contribute the changes made to the paths we are interested in, and showing only the changes to the paths that match pathspec. AFAIK, "prune" is also used to describe unreachable loose objects, but that use is fairly isolated and have little risk of being confusing too much. Are there other uses to make you consider it "highly overloaded"? My gut feeling is that the result is not reducing "overloading" in a meaningful way, and this change is not worth the churn, but it depends on the answer to the above question. Thanks.
Re: [PATCH v3 1/1] git clone C:\cygwin\home\USER\repo' is working (again)
tbo...@web.de writes: > - The "DOS" moniker is still used for 2 reasons: > Windows inherited the "drive letter" concept from DOS, > and everybody (tm) familar with the code and the path handling > in Git is used to that wording. Yeah, for the same reason as win32 can refer to their API that is used on platforms that are 64-bit, the fact that the "drive letter" concept came from DOS is so widely ingrained, I do not think it is a beter change to deviate from it. > And, before any cleanup is done, I sould like to ask if anybody > can build the code with VS and confirm that it works, please ? Yup, that is much more important. Thanks.
Re: why doesn't "git reset" mention optional pathspec?
Duy Nguyen writes: > Without --mixed, you're using the first form > > git reset [-q] [] [--] ... > > which accepts pathspec. If it's not clear, of course patches are welcome. Yup. The deprecation is about spelling with "--mixed" when invoking the "restore these paths out of tree-ish (or HEAD when omitted) only in the index" mode. The feature is of course not deprecated (but it might have been better if it were "git checkout --cached").
Re: [PATCH on master v2] revision: use commit graph in get_reference()
Junio C Hamano writes:
> Jonathan Tan writes:
>
>> When fetching into a repository, a connectivity check is first made by
>> check_exist_and_connected() in builtin/fetch.c that runs:
>> ...
>> Another way to accomplish this effect would be to modify parse_object()
>> to use the commit graph if possible; however, I did not want to change
>> parse_object()'s current behavior of always checking the object
>> signature of the returned object.
>
> Sounds good.
>
>> Signed-off-by: Jonathan Tan
>> ---
>> This patch is now on master.
>
> OK.
>
> Obviously that won't apply to the base for v1 without conflicts, and
> it of course applies cleanly on 'master', but the result of doing so
> will cause the same conflicts when sb/more-repo-in-api is merged on
> top, which means that the same conflicts need to be resolved if this
> wants to be merged to 'next' (or 'pu', FWIW).
So,... as I had to do the reverse rebase anyway, here is the
difference since the previous round, which I came up with by
comparing these two:
(A) merge 'sb/more-repo-in-api' to 'master' and then merge v1 of
this topic to the result.
(B) apply your patch to 'master', and then merge
'sb/more-repo-in-api' to the result.
diff --git a/commit-graph.c b/commit-graph.c
index f78a8e96b5..74a17789f8 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -286,7 +286,8 @@ void close_commit_graph(struct repository *r)
r->objects->commit_graph = NULL;
}
-static int bsearch_graph(struct commit_graph *g, struct object_id *oid,
uint32_t *pos)
+static int bsearch_graph(struct commit_graph *g, const struct object_id *oid,
+uint32_t *pos)
{
return bsearch_hash(oid->hash, g->chunk_oid_fanout,
g->chunk_oid_lookup, g->hash_len, pos);
@@ -377,26 +378,41 @@ static int find_commit_in_graph(struct commit *item,
struct commit_graph *g, uin
}
}
-static int parse_commit_in_graph_one(struct repository *r,
-struct commit_graph *g,
-struct commit *item)
+static struct commit *parse_commit_in_graph_one(struct repository *r,
+ struct commit_graph *g,
+ struct commit *shell,
+ const struct object_id *oid)
{
uint32_t pos;
- if (item->object.parsed)
- return 1;
+ if (shell && shell->object.parsed)
+ return shell;
- if (find_commit_in_graph(item, g, &pos))
- return fill_commit_in_graph(r, item, g, pos);
+ if (shell && shell->graph_pos != COMMIT_NOT_FROM_GRAPH) {
+ pos = shell->graph_pos;
+ } else if (bsearch_graph(g, shell ? &shell->object.oid : oid, &pos)) {
+ /* bsearch_graph sets pos */
+ } else {
+ return NULL;
+ }
- return 0;
+ if (!shell) {
+ shell = lookup_commit(r, oid);
+ if (!shell)
+ return NULL;
+ }
+
+ fill_commit_in_graph(r, shell, g, pos);
+ return shell;
}
-int parse_commit_in_graph(struct repository *r, struct commit *item)
+struct commit *parse_commit_in_graph(struct repository *r, struct commit
*shell,
+const struct object_id *oid)
{
if (!prepare_commit_graph(r))
return 0;
- return parse_commit_in_graph_one(r, r->objects->commit_graph, item);
+ return parse_commit_in_graph_one(r, r->objects->commit_graph, shell,
+oid);
}
void load_commit_graph_info(struct repository *r, struct commit *item)
@@ -1033,7 +1049,7 @@ int verify_commit_graph(struct repository *r, struct
commit_graph *g)
}
graph_commit = lookup_commit(r, &cur_oid);
- if (!parse_commit_in_graph_one(r, g, graph_commit))
+ if (!parse_commit_in_graph_one(r, g, graph_commit, NULL))
graph_report("failed to parse %s from commit-graph",
oid_to_hex(&cur_oid));
}
diff --git a/commit-graph.h b/commit-graph.h
index 9db40b4d3a..8b7b5985dc 100644
--- a/commit-graph.h
+++ b/commit-graph.h
@@ -13,16 +13,20 @@ struct commit;
char *get_commit_graph_filename(const char *obj_dir);
/*
- * Given a commit struct, try to fill the commit struct info, including:
+ * If the given commit (identified by shell->object.oid or oid) is in the
+ * commit graph, returns a commit struct (reusing shell if it is not NULL)
+ * including the following info:
* 1. tree object
* 2. date
* 3. parents.
*
- * Returns 1 if and only if the commit was found in the packed graph.
+ * If not, returns NULL. See parse_commit_buffer() for the fallback after this
+ * call.
*
- * See parse_commit_buffer() for the fallback after this call.
+ * Either shell or oid must be non-N
Re: [PATCH] terminology tweak: prune -> path limiting
Junio C Hamano writes: > AFAIK, "prune" is also used to describe unreachable loose objects, s/describe/& the act of culling/ > but that use is fairly isolated and have little risk of being > confusing too much. Are there other uses to make you consider it > "highly overloaded"?
Re: [PATCH] fetch: ensure submodule objects fetched
Stefan Beller writes: > Currently when git-fetch is asked to recurse into submodules, it dispatches > a plain "git-fetch -C " (with some submodule related options > such as prefix and recusing strategy, but) without any information of the > remote or the tip that should be fetched. > > But this default fetch is not sufficient, as a newly fetched commit in > the superproject could point to a commit in the submodule that is not > in the default refspec. This is common in workflows like Gerrit's. > When fetching a Gerrit change under review (from refs/changes/??), the > commits in that change likely point to submodule commits that have not > been merged to a branch yet. > > Fetch a submodule object by id if the object that the superproject > points to, cannot be found. For now this object is fetched from the > 'origin' remote as we defer getting the default remote to a later patch. > > A list of new submodule commits are already generated in certain > conditions (by check_for_new_submodule_commits()); this new feature > invokes that function in more situations. > > The submodule checks were done only when a ref in the superproject > changed, these checks were extended to also be performed when fetching > into FETCH_HEAD for completeness, and add a test for that too. > > Signed-off-by: Stefan Beller > --- > > Thanks Jonathan for the review! > So it looks like only the last patch needs some improvements, > which is why I'd only resend the last patch here. > Also note the test with interious superproject commits. Sorry, can't parse the last sentence. Anyway, will replace the last step with this. Thanks.
Re: Documentation: update "man git-add" to include "[]"
"Robert P. J. Day" writes: > Current "man git-add" emphasizes single letter interactive > shortcut commands with "[]". Not for me. These prefixes are instead painted in colors.
Re: [PATCH v3 2/3] commit-graph: fix buffer read-overflow
Josh Steadmon writes:
> diff --git a/t/t5318-commit-graph.sh b/t/t5318-commit-graph.sh
> index 5fe21db99f..5b6b44b78e 100755
> --- a/t/t5318-commit-graph.sh
> +++ b/t/t5318-commit-graph.sh
> @@ -366,24 +366,30 @@ GRAPH_OCTOPUS_DATA_OFFSET=$(($GRAPH_COMMIT_DATA_OFFSET
> + \
> GRAPH_BYTE_OCTOPUS=$(($GRAPH_OCTOPUS_DATA_OFFSET + 4))
> GRAPH_BYTE_FOOTER=$(($GRAPH_OCTOPUS_DATA_OFFSET + 4 * $NUM_OCTOPUS_EDGES))
>
> -# usage: corrupt_graph_and_verify
> +# usage: corrupt_graph_and_verify[]
> # Manipulates the commit-graph file at the position
> -# by inserting the data, then runs 'git commit-graph verify'
> +# by inserting the data, optionally zeroing the file
> +# starting at , then runs 'git commit-graph verify'
> # and places the output in the file 'err'. Test 'err' for
> # the given string.
> corrupt_graph_and_verify() {
> pos=$1
> data="${2:-\0}"
> grepstr=$3
> + orig_size=$(stat --format=%s $objdir/info/commit-graph)
"stat(1)" is not so portable, so you'll get complaints from minority
platform users later. So is "truncate(1)".
> + zero_pos=${4:-${orig_size}}
> cd "$TRASH_DIRECTORY/full" &&
> test_when_finished mv commit-graph-backup $objdir/info/commit-graph &&
> cp $objdir/info/commit-graph commit-graph-backup &&
> printf "$data" | dd of="$objdir/info/commit-graph" bs=1 seek="$pos"
> conv=notrunc &&
> + truncate --size=$zero_pos $objdir/info/commit-graph &&
> + truncate --size=$orig_size $objdir/info/commit-graph &&
> test_must_fail git commit-graph verify 2>test_err &&
> grep -v "^+" test_err >err
> test_i18ngrep "$grepstr" err
> }
>
> +
> test_expect_success 'detect bad signature' '
> corrupt_graph_and_verify 0 "\0" \
> "graph signature"
> @@ -484,6 +490,11 @@ test_expect_success 'detect invalid checksum hash' '
> "incorrect checksum"
> '
>
> +test_expect_success 'detect incorrect chunk count' '
> + corrupt_graph_and_verify $GRAPH_BYTE_CHUNK_COUNT "\xff" \
Implementations of printf(1) may not grok "\xff" as a valid
representation of "\377". The shell built-in of dash(1) for example
would not work with this.
> + "chunk lookup table entry missing" $GRAPH_CHUNK_LOOKUP_OFFSET
> +'
> +
> test_expect_success 'git fsck (checks commit-graph)' '
> cd "$TRASH_DIRECTORY/full" &&
> git fsck &&
[GIT PULL] l10n updates for 2.20.0 round 3
Hi Junio, Please pull the following git l10n updates for Git 2.20.0. The following changes since commit 8a0ba68f6dab2c8b1f297a0d46b710bb9af3237a: Git 2.20-rc2 (2018-12-01 21:44:56 +0900) are available in the Git repository at: g...@github.com:git-l10n/git-po.git tags/l10n-2.20.0-rnd3 for you to fetch changes up to 0688c551a3e0f812e2153b716b9674da5914122c: l10n: de.po: fix two messages (2018-12-07 19:43:07 +0100) l10n-2.20.0-rnd3 Alexander Shopov (3): l10n: bg.po: Updated Bulgarian translation (4185t) l10n: bg.po: Updated Bulgarian translation (4185t) l10n: bg.po: Updated Bulgarian translation (4187t) Christopher Díaz Riveros (2): l10n: es.po v2.20.0 round 1 l10n: es.po v2.20.0 round 3 Jean-Noël Avila (2): l10n: fr.po v2.20 rnd 1 l10n: fr.po v2.20.0 round 3 Jiang Xin (16): l10n: zh_CN: review for git v2.19.0 l10n Merge branch 'master' of https://github.com/Softcatala/git-po l10n: git.pot: v2.20.0 round 1 (254 new, 27 removed) Merge branch 'master' of git://github.com/git-l10n/git-po Merge branch 'fr_2.20_rnd1' of git://github.com/jnavila/git Merge branch 'master' of git://github.com/nafmo/git-l10n-sv Merge branch 'master' of git://github.com/alshopov/git-po Merge branch 'master' of git://github.com/git-l10n/git-po l10n: git.pot: v2.20.0 round 2 (2 new, 2 removed) Merge branch 'master' of https://github.com/vnwildman/git Merge branch 'master' of git://github.com/git-l10n/git-po l10n: git.pot: v2.20.0 round 3 (5 new, 3 removed) Merge branch 'master' of https://github.com/vnwildman/git Merge branch 'fr_2.20_round3' of git://github.com/jnavila/git Merge branch 'master' of git://github.com/alshopov/git-po l10n: zh_CN: for git v2.20.0 l10n round 1 to 3 Jordi Mas (2): l10n: Update Catalan translation l10n: Update Catalan translation Minh Nguyen (1): l10n: vi.po: fix typo in pack-objects Peter Krefting (2): l10n: sv.po: Update Swedish translation (4185t0f0u) l10n: sv.po: Update Swedish translation (4187t0f0u) Ralf Thielow (3): l10n: update German translation l10n: update German translation l10n: de.po: fix two messages Trần Ngọc Quân (2): l10n: vi(4185t): Updated Vietnamese translation for v2.20.0 l10n: vi(4187t): Updated Vietnamese translation for v2.20.0 rd3 po/bg.po| 7398 - po/ca.po| 14723 +- po/de.po| 10702 -- po/es.po| 7642 +- po/fr.po| 7344 + po/git.pot | 7243 + po/sv.po| 7324 + po/vi.po| 7357 + po/zh_CN.po | 7422 - 9 files changed, 46477 insertions(+), 30678 deletions(-) -- Jiang Xin
Re: [GIT PULL] l10n updates for 2.20.0 round 3
Jiang Xin writes: > Please pull the following git l10n updates for Git 2.20.0. > > The following changes since commit 8a0ba68f6dab2c8b1f297a0d46b710bb9af3237a: > > Git 2.20-rc2 (2018-12-01 21:44:56 +0900) > > are available in the Git repository at: > > g...@github.com:git-l10n/git-po.git tags/l10n-2.20.0-rnd3 > > for you to fetch changes up to 0688c551a3e0f812e2153b716b9674da5914122c: > > l10n: de.po: fix two messages (2018-12-07 19:43:07 +0100) Thanks, will do.
Re: Retrieving a file in git that was deleted and committed
>You can feed a set of revisions to git-blame with the "-S" option, but I >don't offhand know how it handles diffs (I think it would have to still >diff each commit against its parent, since history is non-linear, and a >list is inherently linear). You might want to experiment with that. >Other than that, you can play with git-replace to produce a fake >history, as if the deletion never happened. But note that will affect >all commands, not just one particular blame. It might be a neat way to >play with blame, but I doubt I'd leave the replacement in place in the >long term. > -Peff Ah I see. Will try git-replace. Thanks! On Fri, Dec 7, 2018 at 11:29 PM Jeff King wrote: > > On Fri, Dec 07, 2018 at 01:50:57PM -0800, biswaranjan panda wrote: > > > Thanks Jeff and Bryan! However, I am curious that if there were a way > > to tell git blame to skip a commit (the one which added the file again > > and maybe the one which deleted it originally) while it walks back > > through history, then it should just get back the > > entire history right ? > > Not easily. ;) > > You can feed a set of revisions to git-blame with the "-S" option, but I > don't offhand know how it handles diffs (I think it would have to still > diff each commit against its parent, since history is non-linear, and a > list is inherently linear). You might want to experiment with that. > > Other than that, you can play with git-replace to produce a fake > history, as if the deletion never happened. But note that will affect > all commands, not just one particular blame. It might be a neat way to > play with blame, but I doubt I'd leave the replacement in place in the > long term. > > -Peff -- Thanks, -Biswa
Re: [PATCH 1/4] submodule update: add regression test with old style setups
Stefan Beller writes: > As f178c13fda (Revert "Merge branch 'sb/submodule-core-worktree'", > 2018-09-07) was produced shortly before a release, nobody asked for > a regression test to be included. Add a regression test that makes sure > that the invocation of `git submodule update` on old setups doesn't > produce errors as pointed out in f178c13fda. > > The place to add such a regression test may look odd in t7412, but > that is the best place as there we setup old style submodule setups > explicitly. Very good first step. Thanks. > > Signed-off-by: Stefan Beller > --- > t/t7412-submodule-absorbgitdirs.sh | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/t/t7412-submodule-absorbgitdirs.sh > b/t/t7412-submodule-absorbgitdirs.sh > index ce74c12da2..1cfa150768 100755 > --- a/t/t7412-submodule-absorbgitdirs.sh > +++ b/t/t7412-submodule-absorbgitdirs.sh > @@ -75,7 +75,12 @@ test_expect_success 're-setup nested submodule' ' > GIT_WORK_TREE=../../../nested git -C sub1/.git/modules/nested config \ > core.worktree "../../../nested" && > # make sure this re-setup is correct > - git status --ignore-submodules=none > + git status --ignore-submodules=none && > + > + # also make sure this old setup does not regress > + git submodule update --init --recursive >out 2>err && > + test_must_be_empty out && > + test_must_be_empty err > ' > > test_expect_success 'absorb the git dir in a nested submodule' '
Re: [WIP RFC 1/5] Documentation: order protocol v2 sections
Jonathan Tan writes: >> > The git command line expects Git servers to follow a specific order of >> >> "Command line"? It sounds like you are talking about the order of >> command line arguments and options, but apparently that is not what >> you are doing. Is it "The git over-the-wire protocol"? > > I meant to say the current Git implementation, as opposed to what is > written in the specification. I'll replace it with "The current C Git > implementation". Yeah, that would avoid confusing future readers; sounds good. >> Earlier, we said that shallow-info is not given when packfile is not >> there. That is captured in the updated EBNF above. We don't have a >> corresponding removal of a bullet point for wanted-refs section below >> but probably that is because the original did not have corresponding >> bullet point to begin with. > > That's because the corresponding bullet point had other information. > Quoted in full below: > >> * This section is only included if the client has requested a >>ref using a 'want-ref' line and if a packfile section is also >>included in the response. > > I could reword it to "If a packfile section is included in the response, > this section is only included if the client has requested a ref using a > 'want-ref' line", but I don't think that is significantly clearer. I don't either. I didn't mean to suggest to change anything in this part. I was just giving an observation---two parallel things do not get updates in tandem, and that is because they were not described the same way to begin with, which was a good enough explanation.
Re: [PATCH] git-rebase.txt: update note about directory rename detection and am
Elijah Newren writes:
> On Fri, Dec 7, 2018 at 9:51 AM Johannes Sixt wrote:
>>
>> From: Elijah Newren
>>
>> In commit 6aba117d5cf7 ("am: avoid directory rename detection when
>> calling recursive merge machinery", 2018-08-29), the git-rebase manpage
>> probably should have also been updated to note the stronger
>> incompatibility between git-am and directory rename detection. Update
>> it now.
>>
>> Signed-off-by: Elijah Newren
>> Signed-off-by: Johannes Sixt
>> ---
>> Documentation/git-rebase.txt | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
>> index 41631df6e4..7bea21e8e3 100644
>> --- a/Documentation/git-rebase.txt
>> +++ b/Documentation/git-rebase.txt
>> @@ -569,8 +569,9 @@ it to keep commits that started empty.
>> Directory rename detection
>> ~~
>>
>> -The merge and interactive backends work fine with
>> -directory rename detection. The am backend sometimes does not.
>> +Directory rename heuristics are enabled in the merge and interactive
>> +backends. Due to the lack of accurate tree information, directory
>> +rename detection is disabled in the am backend.
>>
>> include::merge-strategies.txt[]
>
> I was intending to send this out the past couple days, was just kinda
> busy. Thanks for handling it for me.
Thanks, both. I can live with format=flowed, but would appreciate
if we can avoid it next time.
Re: [PATCH] mailmap: update brandon williams's email address
On Sat, Dec 8, 2018 at 7:09 AM Junio C Hamano wrote: > If this were "Jonathan asked Brandon if we want to record an address > we can reach him in our .mailmap file and sent a patch to add one", Not sure about Jonathan, but I did. > then the story is different, and I tend to agree with you that such > a patch is more or less pointless. That's not the purpose of the > mailmap file. Not directly, but when multiple commands use mailmap to show the canonical mail addresses, then it kinda is. When I look back at an old commit message, I may look up the author name and address, which is mapped. > Not until git-send-email learns to use that file to rewrite > To/cc/etc to the "canonical" addresses, anyway ;-) git-send-email does not have to when I copy/paste the address from git-log anyway. > I am not sure if there are people whose "canonical" address to be > used as the author is not necessarily the best address they want to > get their e-mails at, though. If we can be reasonably sure that the > set of such people is empty, then people can take the above mention > about send-email as a hint about a low-hanging fruit ;-) > > Thanks. > > -- Duy
Re: [PATCH] mailmap: update brandon williams's email address
On Sat, Dec 08 2018, Junio C Hamano wrote: > Stefan Beller writes: > >> On Fri, Dec 7, 2018 at 1:40 PM Jonathan Nieder wrote: >>> >>> Brandon Williams wrote: >>> >>> > Signed-off-by: Brandon Williams >>> > --- >>> > .mailmap | 1 + >>> > 1 file changed, 1 insertion(+) >>> >>> I can confirm that this is indeed the same person. >> >> What would be more of interest is why we'd be interested in this patch >> as there is no commit/patch sent by Brandon with this email in gits history. > > Once I "git am" the message that began this thread, there will be a > commit under this new ident, so that would be somewhat a moot point. "Get to the top of 'git shortlog -sn' with this one easy trick" :) (The patch makes sense, good to see you back on-list Brandon)
Documentation: update "man git-add" to include "[]"
Current "man git-add" emphasizes single letter interactive shortcut commands with "[]". Signed-off-by: Robert P. J. Day --- diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 45652fe4a6..ad9bd7c7a6 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -239,8 +239,8 @@ and type return, like this: *** Commands *** - 1: status 2: update 3: revert 4: add untracked - 5: patch6: diff 7: quit 8: help + 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked + 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp What now> 1 -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[PATCH v3 1/1] git clone C:\cygwin\home\USER\repo' is working (again)
From: Torsten Bögershausen
A regression for cygwin users was introduced with commit 05b458c,
"real_path: resolve symlinks by hand".
In the the commit message we read:
The current implementation of real_path uses chdir() in order to resolve
symlinks. Unfortunately this isn't thread-safe as chdir() affects a
process as a whole...
The old (and non-thread-save) OS calls chdir()/pwd() had been
replaced by a string operation.
The cygwin layer "knows" that "C:\cygwin" is an absolute path,
but the new string operation does not.
"git clone C:\cygwin\home\USER\repo" fails like this:
fatal: Invalid path '/home/USER/repo/C:\cygwin\home\USER\repo'
The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
in the same way as it is done in 'Git for Windows' in compat/mingw.[ch]
Extract the needed code into compat/win32/path-utils.[ch] and use it
for cygwin as well.
Reported-by: Steven Penny
Helped-by: Johannes Schindelin
Signed-off-by: Torsten Bögershausen
---
Changes since V2:
- Settled on a better name:
The common code is in compat/win32/path-utils.c/h
- Skip the 2 patches which "only" do a cleanup (for a moment)
put those cleanups onto the "todo stack".
- The "DOS" moniker is still used for 2 reasons:
Windows inherited the "drive letter" concept from DOS,
and everybody (tm) familar with the code and the path handling
in Git is used to that wording.
Even if there was a better name, it needed to be addressed
in a patch series different from this one.
Here I want to fix a reported regression.
And, before any cleanup is done, I sould like to ask if anybody
can build the code with VS and confirm that it works, please ?
Thanks for the reviews, testing and comment.
compat/cygwin.c | 19 ---
compat/cygwin.h | 2 --
compat/mingw.c| 29 +
compat/mingw.h| 20
compat/win32/path-utils.c | 28
compat/win32/path-utils.h | 20
config.mak.uname | 3 ++-
git-compat-util.h | 3 ++-
8 files changed, 53 insertions(+), 71 deletions(-)
delete mode 100644 compat/cygwin.c
delete mode 100644 compat/cygwin.h
create mode 100644 compat/win32/path-utils.c
create mode 100644 compat/win32/path-utils.h
diff --git a/compat/cygwin.c b/compat/cygwin.c
deleted file mode 100644
index b9862d606d..00
--- a/compat/cygwin.c
+++ /dev/null
@@ -1,19 +0,0 @@
-#include "../git-compat-util.h"
-#include "../cache.h"
-
-int cygwin_offset_1st_component(const char *path)
-{
- const char *pos = path;
- /* unc paths */
- if (is_dir_sep(pos[0]) && is_dir_sep(pos[1])) {
- /* skip server name */
- pos = strchr(pos + 2, '/');
- if (!pos)
- return 0; /* Error: malformed unc path */
-
- do {
- pos++;
- } while (*pos && pos[0] != '/');
- }
- return pos + is_dir_sep(*pos) - path;
-}
diff --git a/compat/cygwin.h b/compat/cygwin.h
deleted file mode 100644
index 8e52de4644..00
--- a/compat/cygwin.h
+++ /dev/null
@@ -1,2 +0,0 @@
-int cygwin_offset_1st_component(const char *path);
-#define offset_1st_component cygwin_offset_1st_component
diff --git a/compat/mingw.c b/compat/mingw.c
index 34b3880b29..27e397f268 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -350,7 +350,7 @@ static inline int needs_hiding(const char *path)
return 0;
/* We cannot use basename(), as it would remove trailing slashes */
- mingw_skip_dos_drive_prefix((char **)&path);
+ win_path_utils_skip_dos_drive_prefix((char **)&path);
if (!*path)
return 0;
@@ -2275,33 +2275,6 @@ pid_t waitpid(pid_t pid, int *status, int options)
return -1;
}
-int mingw_skip_dos_drive_prefix(char **path)
-{
- int ret = has_dos_drive_prefix(*path);
- *path += ret;
- return ret;
-}
-
-int mingw_offset_1st_component(const char *path)
-{
- char *pos = (char *)path;
-
- /* unc paths */
- if (!skip_dos_drive_prefix(&pos) &&
- is_dir_sep(pos[0]) && is_dir_sep(pos[1])) {
- /* skip server name */
- pos = strpbrk(pos + 2, "\\/");
- if (!pos)
- return 0; /* Error: malformed unc path */
-
- do {
- pos++;
- } while (*pos && !is_dir_sep(*pos));
- }
-
- return pos + is_dir_sep(*pos) - path;
-}
-
int xutftowcsn(wchar_t *wcs, const char *utfs, size_t wcslen, int utflen)
{
int upos = 0, wpos = 0;
diff --git a/compat/mingw.h b/compat/mingw.h
index 8c24ddaa3e..30d9fb3e36 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -443,32 +443,12 @@ HANDLE winansi_get_osfhandle(int fd);
* git specific compatibility
*/
-#
[wishlist] submodule.update config
Relates (but orthogonal) to my other thread
[wishlist] git submodule update --reset-hard
ATM, it possible to specify per submodule update strategy via
configuration variable submodule.SUBMODULE.update where SUBMODULE is the name
of the corresponding submodule. But I see no way to specify default update
strategy for all submodules.
>From our conversation in that other thread I have discovered to myself about
existence of submodule.recurse configuration, and there seems to be a few
more (.fetchJobs, .active) where e.g. .active seems to complement per-submodule
submodule.*.active:
yoh@debian:~/proj/misc/git$ git grep '[^.]submodule\.[a-z]' --
Documentation/
Documentation/RelNotes/2.14.0.txt: * Many commands learned to pay
attention to submodule.recurse
Documentation/RelNotes/2.15.0.txt: * "git -c submodule.recurse=yes
pull" did not work as if the
Documentation/config.txt:include::config/submodule.txt[]
Documentation/config/submodule.txt: update'. If neither
submodule..active or submodule.active are
Documentation/config/submodule.txt: interact with submodules;
settings like `submodule.active`
Documentation/config/submodule.txt: submodule.active config option.
See linkgit:gitsubmodules[7] for
Documentation/config/submodule.txt: as computed via
`submodule.alternateLocation`. Possible values are
Documentation/git-clone.txt:of multiple entries. The resulting
clone has `submodule.active` set to
Documentation/git-clone.txt:Defaults to the `submodule.fetchJobs`
option.
Documentation/git-submodule.txt:If no path is specified and
submodule.active has been configured, submodules
Documentation/git-submodule.txt:Defaults to the
`submodule.fetchJobs` option.
Documentation/gitsubmodules.txt:`submodule.foo.path = path/to/bar`.
Documentation/gitsubmodules.txt:The section `submodule.foo.*` in the
`.gitmodules` file gives additional
Documentation/gitsubmodules.txt:hints to Git's porcelain layer. For
example, the `submodule.foo.url`
Documentation/gitsubmodules.txt: b. if the submodule's path matches
the pathspec in `submodule.active`
Documentation/gitsubmodules.txt:submodule's path is excluded in the
pathspec in `submodule.active`, the
Documentation/gitsubmodules.txt: git config --global submodule.recurse
true
Documentation/gitsubmodules.txt:your working tree. Alternatively you
can set 'submodule.recurse' to have
Documentation/technical/api-config.txt:if
(!git_configset_get_bool(gm_config, "submodule.frotz.ignore", &b)) {
Documentation/technical/http-protocol.txt: $GIT_URL:
http://example.com/git/repo.git/path/submodule.git
Documentation/technical/http-protocol.txt: URL request:
http://example.com/git/repo.git/path/submodule.git/info/refs
I wondered, if you think it would be sensible to also add of
submodule.update which would be considered before submodule.SUBMODULE.update
variable possibly defined per submodule. That would be more inline with desire
to use any of the --merge, --rebase (and hopefully soon --reset-hard)
strategies specified as an option for submodule update, where no per-submodule
handling is happening.
Thanks in advance for the consideration!
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
why doesn't "git reset" mention optional pathspec?
from "man git-reset": SYNOPSIS git reset [-q] [] [--] ... git reset (--patch | -p) [] [--] [...] git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [] oddly, the third form says nothing about possible "", even though i'm pretty sure they're valid in that third case (at least for "--mixed"). thoughts? is that just an oversight in the man page? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: "git add -p" versus "git add -i", followed by "p"
On Sun, 2 Dec 2018, Duy Nguyen wrote: > On Sun, Dec 2, 2018 at 6:05 PM Robert P. J. Day wrote: > > > Patch update>> 2 > > > staged unstaged path > > > * 1:unchanged+1/-0 README.md > > > * 2:unchanged+1/-0 contrib/README > > > 3:unchanged+1/-0 t/README > > > Patch update>> > > > > > > Here I hit enter. Did you? > > > > perhaps i'm just not seeing it, but from "man git-add", it > > doesn't seem obvious that you would first select the files to work > > with, then hit a simple CR to get into actual patch mode. > > I think it's the same procedure as the "update" step, which > describes this in more detail. I agree that the "patch" section does > not make this obvious. when i get a chance, i'll try to reword it. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: [PATCH v3 1/1] git clone C:\cygwin\home\USER\repo' is working (again)
On Sat, Dec 8, 2018 at 9:11 AM wrote: > Changes since V2: latest patch still fixes original issue - thanks > - Settled on a better name: > The common code is in compat/win32/path-utils.c/h > [...] > - The "DOS" moniker is still used for 2 reasons: > Windows inherited the "drive letter" concept from DOS, > and everybody (tm) familar with the code and the path handling > in Git is used to that wording. > Even if there was a better name, it needed to be addressed > in a patch series different from this one. > Here I want to fix a reported regression. i still disagree with this - but i understand if naming argument is out of scope for thread > And, before any cleanup is done, I sould like to ask if anybody > can build the code with VS and confirm that it works, please ? sorry but i am decidedly *not* interested in doing this. i use cygwin specifically so that i can avoid VS. hopefully someone else will be able to test. cheers
[PATCH v4 0/7] %(trailers) improvements in pretty format
Updated since v3: * multiple 'key=' matches any * allow overriding implicit 'only' when using key * minor grammar and spelling fixes * documentation restructuring * Helper functions for parsing options Anders Waldenborg (7): doc: group pretty-format.txt placeholders descriptions pretty: allow %(trailers) options with explicit value pretty: single return path in %(trailers) handling pretty: allow showing specific trailers pretty: add support for "valueonly" option in %(trailers) strbuf: separate callback for strbuf_expand:ing literals pretty: add support for separator option in %(trailers) Documentation/pretty-formats.txt | 260 ++- pretty.c | 104 ++--- strbuf.c | 21 +++ strbuf.h | 8 + t/t4205-log-pretty-formats.sh| 111 + trailer.c| 25 ++- trailer.h| 4 + 7 files changed, 400 insertions(+), 133 deletions(-) -- 2.17.1
[PATCH v4 6/7] strbuf: separate callback for strbuf_expand:ing literals
Expanding '%n' and '%xNN' is generic functionality, so extract that from
the pretty.c formatter into a callback that can be reused.
No functional change intended
Signed-off-by: Anders Waldenborg
---
pretty.c | 16 +---
strbuf.c | 21 +
strbuf.h | 8
3 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/pretty.c b/pretty.c
index c508357606..50d0b5830d 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1133,9 +1133,13 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
const char *msg = c->message;
struct commit_list *p;
const char *arg;
- int ch;
+ size_t res;
/* these are independent of the commit */
+ res = strbuf_expand_literal_cb(sb, placeholder, NULL);
+ if (res)
+ return res;
+
switch (placeholder[0]) {
case 'C':
if (starts_with(placeholder + 1, "(auto)")) {
@@ -1154,16 +1158,6 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
*/
return ret;
}
- case 'n': /* newline */
- strbuf_addch(sb, '\n');
- return 1;
- case 'x':
- /* %x00 == NUL, %x0a == LF, etc. */
- ch = hex2chr(placeholder + 1);
- if (ch < 0)
- return 0;
- strbuf_addch(sb, ch);
- return 3;
case 'w':
if (placeholder[1] == '(') {
unsigned long width = 0, indent1 = 0, indent2 = 0;
diff --git a/strbuf.c b/strbuf.c
index f6a6cf78b9..78eecd29f7 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -380,6 +380,27 @@ void strbuf_expand(struct strbuf *sb, const char *format,
expand_fn_t fn,
}
}
+size_t strbuf_expand_literal_cb(struct strbuf *sb,
+ const char *placeholder,
+ void *context)
+{
+ int ch;
+
+ switch (placeholder[0]) {
+ case 'n': /* newline */
+ strbuf_addch(sb, '\n');
+ return 1;
+ case 'x':
+ /* %x00 == NUL, %x0a == LF, etc. */
+ ch = hex2chr(placeholder + 1);
+ if (ch < 0)
+ return 0;
+ strbuf_addch(sb, ch);
+ return 3;
+ }
+ return 0;
+}
+
size_t strbuf_expand_dict_cb(struct strbuf *sb, const char *placeholder,
void *context)
{
diff --git a/strbuf.h b/strbuf.h
index fc40873b65..52e44c9ab8 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -320,6 +320,14 @@ void strbuf_expand(struct strbuf *sb,
expand_fn_t fn,
void *context);
+/**
+ * Used as callback for `strbuf_expand` to only expand literals
+ * (i.e. %n and %xNN). The context argument is ignored.
+ */
+size_t strbuf_expand_literal_cb(struct strbuf *sb,
+ const char *placeholder,
+ void *context);
+
/**
* Used as callback for `strbuf_expand()`, expects an array of
* struct strbuf_expand_dict_entry as context, i.e. pairs of
--
2.17.1
[PATCH v4 5/7] pretty: add support for "valueonly" option in %(trailers)
With the new "key=" option to %(trailers) it often makes little sense to
show the key, as it by definition already is knows which trailer is
printed there. This new "valueonly" option makes it omit the key when
printing trailers.
E.g.:
$ git show -s --pretty='%s%n%(trailers:key=Signed-off-by,valueonly)' 88182
will show:
> upload-pack: fix broken if/else chain in config callback
> Jeff King
> Junio C Hamano
Signed-off-by: Anders Waldenborg
---
Documentation/pretty-formats.txt | 2 ++
pretty.c | 3 ++-
t/t4205-log-pretty-formats.sh| 6 ++
trailer.c| 6 --
trailer.h| 1 +
5 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index d6add831c0..a920dd15b1 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -243,6 +243,8 @@ endif::git-rev-list[]
option was given. In same way as to for `only` it can be followed
by an equal sign and explicit value. E.g.,
`%(trailers:only,unfold=true)` unfolds and shows all trailer lines.
+** 'valueonly[=val]': skip over the key part of the trailer line and only
+ show the value part. Also this optionally allows explicit value.
NOTE: Some placeholders may depend on other options given to the
revision traversal engine. For example, the `%g*` reflog options will
diff --git a/pretty.c b/pretty.c
index 541a553ccc..c508357606 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1383,7 +1383,8 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
opts.filter_data = &filter_list;
opts.only_trailers = 1;
} else if (!match_placeholder_bool_arg(arg,
"only", &arg, &opts.only_trailers) &&
- !match_placeholder_bool_arg(arg,
"unfold", &arg, &opts.unfold))
+ !match_placeholder_bool_arg(arg,
"unfold", &arg, &opts.unfold) &&
+ !match_placeholder_bool_arg(arg,
"valueonly", &arg, &opts.value_only))
break;
}
}
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 54239290cf..22336c5485 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -667,6 +667,12 @@ test_expect_success 'pretty format
%(trailers:key=foo,only=no) also includes non
test_cmp expect actual
'
+test_expect_success '%(trailers:key=foo,valueonly) shows only value' '
+ git log --no-walk --pretty="format:%(trailers:key=Acked-by,valueonly)"
>actual &&
+ echo "A U Thor " >expect &&
+ test_cmp expect actual
+'
+
test_expect_success 'trailer parsing not fooled by --- line' '
git commit --allow-empty -F - <<-\EOF &&
this is the subject
diff --git a/trailer.c b/trailer.c
index d6da555cd7..d0d9e91631 100644
--- a/trailer.c
+++ b/trailer.c
@@ -1150,8 +1150,10 @@ static void format_trailer_info(struct strbuf *out,
if (!opts->filter || opts->filter(&tok,
opts->filter_data)) {
if (opts->unfold)
unfold_value(&val);
-
- strbuf_addf(out, "%s: %s\n", tok.buf, val.buf);
+ if (!opts->value_only)
+ strbuf_addf(out, "%s: ", tok.buf);
+ strbuf_addbuf(out, &val);
+ strbuf_addch(out, '\n');
}
strbuf_release(&tok);
strbuf_release(&val);
diff --git a/trailer.h b/trailer.h
index 5255b676de..06d417fe93 100644
--- a/trailer.h
+++ b/trailer.h
@@ -72,6 +72,7 @@ struct process_trailer_options {
int only_input;
int unfold;
int no_divider;
+ int value_only;
int (*filter)(const struct strbuf *, void *);
void *filter_data;
};
--
2.17.1
[PATCH v4 1/7] doc: group pretty-format.txt placeholders descriptions
The placeholders can be grouped into three kinds:
* literals
* affecting formatting of later placeholders
* expanding to information in commit
Also change the list to a definition list (using '::')
Signed-off-by: Anders Waldenborg
---
Documentation/pretty-formats.txt | 235 ---
1 file changed, 125 insertions(+), 110 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 417b638cd8..86d804fe97 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -102,118 +102,133 @@ The title was >>t4119: test autocomputing -p for
traditional diff input.<<
+
The placeholders are:
-- '%H': commit hash
-- '%h': abbreviated commit hash
-- '%T': tree hash
-- '%t': abbreviated tree hash
-- '%P': parent hashes
-- '%p': abbreviated parent hashes
-- '%an': author name
-- '%aN': author name (respecting .mailmap, see linkgit:git-shortlog[1]
- or linkgit:git-blame[1])
-- '%ae': author email
-- '%aE': author email (respecting .mailmap, see
- linkgit:git-shortlog[1] or linkgit:git-blame[1])
-- '%ad': author date (format respects --date= option)
-- '%aD': author date, RFC2822 style
-- '%ar': author date, relative
-- '%at': author date, UNIX timestamp
-- '%ai': author date, ISO 8601-like format
-- '%aI': author date, strict ISO 8601 format
-- '%cn': committer name
-- '%cN': committer name (respecting .mailmap, see
- linkgit:git-shortlog[1] or linkgit:git-blame[1])
-- '%ce': committer email
-- '%cE': committer email (respecting .mailmap, see
- linkgit:git-shortlog[1] or linkgit:git-blame[1])
-- '%cd': committer date (format respects --date= option)
-- '%cD': committer date, RFC2822 style
-- '%cr': committer date, relative
-- '%ct': committer date, UNIX timestamp
-- '%ci': committer date, ISO 8601-like format
-- '%cI': committer date, strict ISO 8601 format
-- '%d': ref names, like the --decorate option of linkgit:git-log[1]
-- '%D': ref names without the " (", ")" wrapping.
-- '%e': encoding
-- '%s': subject
-- '%f': sanitized subject line, suitable for a filename
-- '%b': body
-- '%B': raw body (unwrapped subject and body)
+- Placeholders that expand to a single literal character:
+'%n':: newline
+'%%':: a raw '%'
+'%x00':: print a byte from a hex code
+
+- Placeholders that affect formatting of later placeholders:
+'%Cred':: switch color to red
+'%Cgreen':: switch color to green
+'%Cblue':: switch color to blue
+'%Creset':: reset color
+'%C(...)':: color specification, as described under Values in the
+"CONFIGURATION FILE" section of linkgit:git-config[1]. By
+default, colors are shown only when enabled for log output
+(by `color.diff`, `color.ui`, or `--color`, and respecting
+the `auto` settings of the former if we are going to a
+terminal). `%C(auto,...)` is accepted as a historical
+synonym for the default (e.g., `%C(auto,red)`). Specifying
+`%C(always,...) will show the colors even when color is
+not otherwise enabled (though consider just using
+`--color=always` to enable color for the whole output,
+including this format and anything else git might color).
+`auto` alone (i.e. `%C(auto)`) will turn on auto coloring
+on the next placeholders until the color is switched
+again.
+'%m':: left (`<`), right (`>`) or boundary (`-`) mark
+'%w([[,[,]]])':: switch line wrapping, like the -w option of
+linkgit:git-shortlog[1].
+'%<([,trunc|ltrunc|mtrunc])':: make the next placeholder take at
+ least N columns, padding spaces on
+ the right if necessary. Optionally
+ truncate at the beginning (ltrunc),
+ the middle (mtrunc) or the end
+ (trunc) if the output is longer than
+ N columns. Note that truncating
+ only works correctly with N >= 2.
+'%<|()':: make the next placeholder take at least until Nth
+ columns, padding spaces on the right if necessary
+'%>()', '%>|()':: similar to '%<()', '%<|()' respectively,
+but padding spaces on the left
+'%>>()', '%>>|()':: similar to '%>()', '%>|()'
+ respectively, except that if the next
+ placeholder takes more spaces than given and
+ there are spaces on its left, use those
+ spaces
+'%><()', '%><|()':: similar to '%<()', '%<|()'
+ respectively, but padding both sides
+ (i.e. the text is centered)
+
+- Placeholders that expand to information extracted from the commit:
+'%H':: commit hash
+'%h':: abbreviated commit hash
+'%T':: tree hash
+'%t':: abbreviated tree hash
+'%P':: parent hashe
[PATCH v4 2/7] pretty: allow %(trailers) options with explicit value
In addition to old %(trailers:only) it is now allowed to write
%(trailers:only=yes)
By itself this only gives (the not quite so useful) possibility to have
users change their mind in the middle of a formatting
string (%(trailers:only=true,only=false)). However, it gives users the
opportunity to override defaults from future options.
Signed-off-by: Anders Waldenborg
---
Documentation/pretty-formats.txt | 14 ++
pretty.c | 32 +++-
t/t4205-log-pretty-formats.sh| 18 ++
3 files changed, 55 insertions(+), 9 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 86d804fe97..d33b072eb2 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -225,10 +225,16 @@ endif::git-rev-list[]
linkgit:git-interpret-trailers[1]. The
`trailers` string may be followed by a colon
and zero or more comma-separated options:
-** 'only': omit non-trailer lines from the trailer block.
-** 'unfold': make it behave as if interpret-trailer's `--unfold`
- option was given. E.g., `%(trailers:only,unfold)` unfolds and
- shows all trailer lines.
+** 'only[=val]': select whether non-trailer lines from the trailer
+ block should be included. The `only` keyword may optionally be
+ followed by an equal sign and one of `true`, `on`, `yes` to omit or
+ `false`, `off`, `no` to show the non-trailer lines. If option is
+ given without value it is enabled. If given multiple times the last
+ value is used.
+** 'unfold[=val]': make it behave as if interpret-trailer's `--unfold`
+ option was given. In same way as to for `only` it can be followed
+ by an equal sign and explicit value. E.g.,
+ `%(trailers:only,unfold=true)` unfolds and shows all trailer lines.
NOTE: Some placeholders may depend on other options given to the
revision traversal engine. For example, the `%g*` reflog options will
diff --git a/pretty.c b/pretty.c
index b83a3ecd23..26efdba73a 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1074,6 +1074,31 @@ static int match_placeholder_arg(const char *to_parse,
const char *candidate,
return 0;
}
+static int match_placeholder_bool_arg(const char *to_parse, const char
*candidate,
+ const char **end, int *val)
+{
+ const char *p;
+ if (!skip_prefix(to_parse, candidate, &p))
+ return 0;
+
+ if (match_placeholder_arg(p, "=no", end) ||
+ match_placeholder_arg(p, "=off", end) ||
+ match_placeholder_arg(p, "=false", end)) {
+ *val = 0;
+ return 1;
+ }
+
+ if (match_placeholder_arg(p, "", end) ||
+ match_placeholder_arg(p, "=yes", end) ||
+ match_placeholder_arg(p, "=on", end) ||
+ match_placeholder_arg(p, "=true", end)) {
+ *val = 1;
+ return 1;
+ }
+
+ return 0;
+}
+
static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
const char *placeholder,
void *context)
@@ -1318,11 +1343,8 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
if (*arg == ':') {
arg++;
for (;;) {
- if (match_placeholder_arg(arg, "only", &arg))
- opts.only_trailers = 1;
- else if (match_placeholder_arg(arg, "unfold",
&arg))
- opts.unfold = 1;
- else
+ if (!match_placeholder_bool_arg(arg, "only",
&arg, &opts.only_trailers) &&
+ !match_placeholder_bool_arg(arg, "unfold",
&arg, &opts.unfold))
break;
}
}
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 978a8a66ff..63730a4ec0 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -578,6 +578,24 @@ test_expect_success '%(trailers:only) shows only "key:
value" trailers' '
test_cmp expect actual
'
+test_expect_success '%(trailers:only=yes) shows only "key: value" trailers' '
+ git log --no-walk --pretty=format:"%(trailers:only=yes)" >actual &&
+ grep -v patch.description expect &&
+ test_cmp expect actual
+'
+
+test_expect_success '%(trailers:only=no) shows all trailers' '
+ git log --no-walk --pretty=format:"%(trailers:only=no)" >actual &&
+ cat trailers >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success '%(trailers:only=no,only=true) shows only "key: value"
trailers' '
+ git log --no-walk --pretty=format:"%(trailers:only=yes)" >actual &&
+ grep -v patch.description expect &&
+
[PATCH v4 7/7] pretty: add support for separator option in %(trailers)
By default trailer lines are terminated by linebreaks ('\n'). By
specifying the new 'separator' option they will instead be separated by
user provided string and have separator semantics rather than terminator
semantics. The separator string can contain the literal formatting codes
%n and %xNN allowing it to be things that are otherwise hard to type
such as %x00, or comma and end-parenthesis which would break parsing.
E.g:
$ git log --pretty='%(trailers:key=Reviewed-by,valueonly,separator=%x00)'
Signed-off-by: Anders Waldenborg
---
Documentation/pretty-formats.txt | 9
pretty.c | 10 +
t/t4205-log-pretty-formats.sh| 36
trailer.c| 15 +++--
trailer.h| 1 +
5 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index a920dd15b1..ce087dee80 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -239,6 +239,15 @@ endif::git-rev-list[]
`false`, `off`, `no` to show the non-trailer lines. If option is
given without value it is enabled. If given multiple times the last
value is used.
+** 'separator=': specify a separator inserted between trailer
+ lines. When this option is not given each trailer line is
+ terminated with a line feed character. The string SEP may contain
+ the literal formatting codes described above. To use comma as
+ separator one must use `%x2C` as it would otherwise be parsed as
+ next option. If separator option is given multiple times only the
+ last one is used. E.g., `%(trailers:key=Ticket,separator=%x2C )`
+ shows all trailer lines whose key is "Ticket" separated by a comma
+ and a space.
** 'unfold[=val]': make it behave as if interpret-trailer's `--unfold`
option was given. In same way as to for `only` it can be followed
by an equal sign and explicit value. E.g.,
diff --git a/pretty.c b/pretty.c
index 50d0b5830d..c7609493ee 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1357,6 +1357,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
if (skip_prefix(placeholder, "(trailers", &arg)) {
struct process_trailer_options opts =
PROCESS_TRAILER_OPTIONS_INIT;
struct string_list filter_list = STRING_LIST_INIT_NODUP;
+ struct strbuf sepbuf = STRBUF_INIT;
size_t ret = 0;
opts.no_divider = 1;
@@ -1376,6 +1377,14 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
opts.filter = format_trailer_match_cb;
opts.filter_data = &filter_list;
opts.only_trailers = 1;
+ } else if (match_placeholder_arg_value(arg,
"separator", &arg, &argval, &arglen)) {
+ char *fmt;
+
+ strbuf_reset(&sepbuf);
+ fmt = xstrndup(argval, arglen);
+ strbuf_expand(&sepbuf, fmt,
strbuf_expand_literal_cb, NULL);
+ free(fmt);
+ opts.separator = &sepbuf;
} else if (!match_placeholder_bool_arg(arg,
"only", &arg, &opts.only_trailers) &&
!match_placeholder_bool_arg(arg,
"unfold", &arg, &opts.unfold) &&
!match_placeholder_bool_arg(arg,
"valueonly", &arg, &opts.value_only))
@@ -1387,6 +1396,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
ret = arg - placeholder + 1;
}
string_list_clear (&filter_list, 0);
+ strbuf_release(&sepbuf);
return ret;
}
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 22336c5485..282369dac0 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -673,6 +673,42 @@ test_expect_success '%(trailers:key=foo,valueonly) shows
only value' '
test_cmp expect actual
'
+test_expect_success 'pretty format %(trailers:separator) changes separator' '
+ git log --no-walk --pretty=format:"X%(trailers:separator=%x00,unfold)X"
>actual &&
+ printf "XSigned-off-by: A U Thor \0Acked-by: A U
Thor \0[ v2 updated patch description ]\0Signed-off-by: A U
Thor X" >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'pretty format %(trailers) combining
separator/key/valueonly' '
+ git commit --allow-empty -F - <<-\EOF &&
+ Important fix
+
+ The fix is explained here
+
+ Closes: #1234
+ EOF
+
+ git commit --allow-empty -F - <<-\EOF &&
+ Another fix
+
+ The fix is explained here
+
+ Clo
[PATCH v4 4/7] pretty: allow showing specific trailers
Adds a new "key=X" option to "%(trailers)" which will cause it to only
print trailer lines which match any of the specified keys.
Signed-off-by: Anders Waldenborg
---
Documentation/pretty-formats.txt | 8 +
pretty.c | 47 ++---
t/t4205-log-pretty-formats.sh| 51
trailer.c| 10 ---
trailer.h| 2 ++
5 files changed, 110 insertions(+), 8 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index d33b072eb2..d6add831c0 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -225,6 +225,14 @@ endif::git-rev-list[]
linkgit:git-interpret-trailers[1]. The
`trailers` string may be followed by a colon
and zero or more comma-separated options:
+** 'key=': only show trailers with specified key. Matching is done
+ case-insensitively and trailing colon is optional. If option is
+ given multiple times trailer lines matching any of the keys are
+ shown. This option automatically enables the `only` option so that
+ non-trailer lines in the trailer block are hidden. If that is not
+ desired it can be disabled with `only=false`. E.g.,
+ `%(trailers:key=Reviewed-by)` shows trailer lines with key
+ `Reviewed-by`.
** 'only[=val]': select whether non-trailer lines from the trailer
block should be included. The `only` keyword may optionally be
followed by an equal sign and one of `true`, `on`, `yes` to omit or
diff --git a/pretty.c b/pretty.c
index 07e6c0..541a553ccc 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1056,13 +1056,20 @@ static size_t parse_padding_placeholder(struct strbuf
*sb,
return 0;
}
-static int match_placeholder_arg(const char *to_parse, const char *candidate,
-const char **end)
+static int match_placeholder_arg_value(const char *to_parse, const char
*candidate,
+ const char **end, const char
**valuestart, size_t *valuelen)
{
const char *p;
if (!(skip_prefix(to_parse, candidate, &p)))
return 0;
+ if (valuestart) {
+ if (*p != '=')
+ return 0;
+ *valuestart = p + 1;
+ *valuelen = strcspn(*valuestart, ",)");
+ p = *valuestart + *valuelen;
+ }
if (*p == ',') {
*end = p + 1;
return 1;
@@ -1074,6 +1081,12 @@ static int match_placeholder_arg(const char *to_parse,
const char *candidate,
return 0;
}
+static int match_placeholder_arg(const char *to_parse, const char *candidate,
+const char **end)
+{
+ return match_placeholder_arg_value(to_parse, candidate, end, NULL,
NULL);
+}
+
static int match_placeholder_bool_arg(const char *to_parse, const char
*candidate,
const char **end, int *val)
{
@@ -1095,7 +1108,19 @@ static int match_placeholder_bool_arg(const char
*to_parse, const char *candidat
*val = 1;
return 1;
}
+ return 0;
+}
+static int format_trailer_match_cb(const struct strbuf *key, void *ud)
+{
+ const struct string_list *list = ud;
+ const struct string_list_item *item;
+
+ for_each_string_list_item (item, list) {
+ if (key->len == (uintptr_t)item->util &&
+ !strncasecmp (item->string, key->buf, key->len))
+ return 1;
+ }
return 0;
}
@@ -1337,6 +1362,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
if (skip_prefix(placeholder, "(trailers", &arg)) {
struct process_trailer_options opts =
PROCESS_TRAILER_OPTIONS_INIT;
+ struct string_list filter_list = STRING_LIST_INIT_NODUP;
size_t ret = 0;
opts.no_divider = 1;
@@ -1344,8 +1370,20 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
if (*arg == ':') {
arg++;
for (;;) {
- if (!match_placeholder_bool_arg(arg, "only",
&arg, &opts.only_trailers) &&
- !match_placeholder_bool_arg(arg, "unfold",
&arg, &opts.unfold))
+ const char *argval;
+ size_t arglen;
+
+ if (match_placeholder_arg_value(arg, "key",
&arg, &argval, &arglen)) {
+ uintptr_t len = arglen;
+ if (len && argval[len - 1] == ':')
+ len--;
+ string_list_append(&filter_list,
argval)->util = (char *)len;
+
+
[PATCH v4 3/7] pretty: single return path in %(trailers) handling
No functional change intended.
This change may not seem useful on its own, but upcoming commits will do
memory allocation in there, and a single return path makes deallocation
easier.
Signed-off-by: Anders Waldenborg
---
pretty.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/pretty.c b/pretty.c
index 26efdba73a..07e6c0 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1337,6 +1337,7 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
if (skip_prefix(placeholder, "(trailers", &arg)) {
struct process_trailer_options opts =
PROCESS_TRAILER_OPTIONS_INIT;
+ size_t ret = 0;
opts.no_divider = 1;
@@ -1350,8 +1351,9 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
}
if (*arg == ')') {
format_trailers_from_commit(sb, msg + c->subject_off,
&opts);
- return arg - placeholder + 1;
+ ret = arg - placeholder + 1;
}
+ return ret;
}
return 0; /* unknown placeholder */
--
2.17.1
Re: why doesn't "git reset" mention optional pathspec?
On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote: > > > from "man git-reset": > > SYNOPSIS > git reset [-q] [] [--] ... > git reset (--patch | -p) [] [--] [...] > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > [] > > oddly, the third form says nothing about possible "", even > though i'm pretty sure they're valid in that third case (at least for > "--mixed"). thoughts? is that just an oversight in the man page? --mixed prints a deprecation warning. I don't think it's worth making the synopsis more complicated for that. All other modes reject pathspec. -- Duy
Re: why doesn't "git reset" mention optional pathspec?
On Sat, 8 Dec 2018, Duy Nguyen wrote: > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote: > > > > > > from "man git-reset": > > > > SYNOPSIS > > git reset [-q] [] [--] ... > > git reset (--patch | -p) [] [--] [...] > > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > > [] > > > > oddly, the third form says nothing about possible "", even > > though i'm pretty sure they're valid in that third case (at least > > for "--mixed"). thoughts? is that just an oversight in the man > > page? > > --mixed prints a deprecation warning. I don't think it's worth > making the synopsis more complicated for that. All other modes > reject pathspec. i just tested this, and i don't see a deprecation warning. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: why doesn't "git reset" mention optional pathspec?
On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote: > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > wrote: > > > > > > > > > from "man git-reset": > > > > > > SYNOPSIS > > > git reset [-q] [] [--] ... > > > git reset (--patch | -p) [] [--] [...] > > > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > > > [] > > > > > > oddly, the third form says nothing about possible "", even > > > though i'm pretty sure they're valid in that third case (at least > > > for "--mixed"). thoughts? is that just an oversight in the man > > > page? > > > > --mixed prints a deprecation warning. I don't think it's worth > > making the synopsis more complicated for that. All other modes > > reject pathspec. > > i just tested this, and i don't see a deprecation warning. Hmm.. maybe I misread the code. I just tried it $ ./git reset --mixed HEAD foo warning: --mixed with paths is deprecated; use 'git reset -- ' instead. -- Duy
Re: why doesn't "git reset" mention optional pathspec?
On Sat, 8 Dec 2018, Duy Nguyen wrote: > On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote: > > > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > > wrote: > > > > > > > > > > > > from "man git-reset": > > > > > > > > SYNOPSIS > > > > git reset [-q] [] [--] ... > > > > git reset (--patch | -p) [] [--] [...] > > > > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > > > > [] > > > > > > > > oddly, the third form says nothing about possible "", even > > > > though i'm pretty sure they're valid in that third case (at least > > > > for "--mixed"). thoughts? is that just an oversight in the man > > > > page? > > > > > > --mixed prints a deprecation warning. I don't think it's worth > > > making the synopsis more complicated for that. All other modes > > > reject pathspec. > > > > i just tested this, and i don't see a deprecation warning. > > Hmm.. maybe I misread the code. I just tried it > > $ ./git reset --mixed HEAD foo > warning: --mixed with paths is deprecated; use 'git reset -- ' instead. weird ... i just tried this two ways, explicitly specifying "--mixed" and also without (which is the default mode, right?), and i got the deprecated message with the first but not the second. that seems ... odd. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: why doesn't "git reset" mention optional pathspec?
On Sat, 8 Dec 2018, Duy Nguyen wrote: > On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote: > > > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > > wrote: > > > > > > > > > > > > from "man git-reset": > > > > > > > > SYNOPSIS > > > > git reset [-q] [] [--] ... > > > > git reset (--patch | -p) [] [--] [...] > > > > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > > > > [] > > > > > > > > oddly, the third form says nothing about possible "", even > > > > though i'm pretty sure they're valid in that third case (at least > > > > for "--mixed"). thoughts? is that just an oversight in the man > > > > page? > > > > > > --mixed prints a deprecation warning. I don't think it's worth > > > making the synopsis more complicated for that. All other modes > > > reject pathspec. > > > > i just tested this, and i don't see a deprecation warning. > > Hmm.. maybe I misread the code. I just tried it > > $ ./git reset --mixed HEAD foo > warning: --mixed with paths is deprecated; use 'git reset -- ' instead. my test: Changes to be committed: (use "git reset HEAD ..." to unstage) modified: README.asc modified: Rakefile $ git reset -- README.asc Unstaged changes after reset: M README.asc $ git reset --mixed -- Rakefile warning: --mixed with paths is deprecated; use 'git reset -- ' instead. Unstaged changes after reset: M README.asc M Rakefile $ that definitely seems inconsistent. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: why doesn't "git reset" mention optional pathspec?
On Sat, Dec 8, 2018 at 6:37 PM Robert P. J. Day wrote: > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day > > wrote: > > > > > > On Sat, 8 Dec 2018, Duy Nguyen wrote: > > > > > > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day > > > > wrote: > > > > > > > > > > > > > > > from "man git-reset": > > > > > > > > > > SYNOPSIS > > > > > git reset [-q] [] [--] ... > > > > > git reset (--patch | -p) [] [--] [...] > > > > > git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] > > > > > [] > > > > > > > > > > oddly, the third form says nothing about possible "", even > > > > > though i'm pretty sure they're valid in that third case (at least > > > > > for "--mixed"). thoughts? is that just an oversight in the man > > > > > page? > > > > > > > > --mixed prints a deprecation warning. I don't think it's worth > > > > making the synopsis more complicated for that. All other modes > > > > reject pathspec. > > > > > > i just tested this, and i don't see a deprecation warning. > > > > Hmm.. maybe I misread the code. I just tried it > > > > $ ./git reset --mixed HEAD foo > > warning: --mixed with paths is deprecated; use 'git reset -- ' > > instead. > > weird ... i just tried this two ways, explicitly specifying > "--mixed" and also without (which is the default mode, right?), and i > got the deprecated message with the first but not the second. that > seems ... odd. Without --mixed, you're using the first form git reset [-q] [] [--] ... which accepts pathspec. If it's not clear, of course patches are welcome. -- Duy
[PATCH] rebase docs: drop stray word in merge command description
Delete a misplaced word introduced by caafecfcf1 (rebase --rebase-merges: adjust man page for octopus support, 2018-03-09). Signed-off-by: Kyle Meyer --- Documentation/git-rebase.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index dff17b3178..2ee535fb23 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -979,7 +979,7 @@ when the merge operation did not even start), it is rescheduled immediately. At this time, the `merge` command will *always* use the `recursive` merge strategy for regular merges, and `octopus` for octopus merges, -strategy, with no way to choose a different one. To work around +with no way to choose a different one. To work around this, an `exec` command can be used to call `git merge` explicitly, using the fact that the labels are worktree-local refs (the ref `refs/rewritten/onto` would correspond to the label `onto`, for example). -- 2.19.2
