[Market Info] Now is your chance to exhibit in Japan!

Dear International Sales & Marketing Director Zhejiang Wuchuan Industrial Co., Ltd, Hello, this is Eiichi Hasegawa from LIFESTYLE EXPO TOKYO 2019 Show Management. Today, I would like to share the information of the growing Japanese gift market, and the buyers that you can meet at our show.

[PATCH v4 1/3] repack: point out a bug handling stale shallow info

From: Johannes Schindelin A `git fetch --prune` can turn previously-reachable objects unreachable, even commits that are in the `shallow` list. A subsequent `git repack -ad` will then unceremoniously drop those unreachable commits, and the `shallow` list will become stale. This means that when

Re: [PATCH v3 1/3] repack: point out a bug handling stale shallow info

Hi Junio, me again. I was wrong. On Wed, 24 Oct 2018, Johannes Schindelin wrote: > On Wed, 24 Oct 2018, Junio C Hamano wrote: > > > "Johannes Schindelin via GitGitGadget" > > writes: > > > > > +... > > > + d="$(git -C shallow-server rev-parse --verify D)" && > > > + git -C shallow-server

Re: [PATCH v3 1/3] repack: point out a bug handling stale shallow info

Hi Junio, On Wed, 24 Oct 2018, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > +... > > + d="$(git -C shallow-server rev-parse --verify D)" && > > + git -C shallow-server checkout master && > > + > > +... > > + ! grep $d shallow-client/.git/shallow && > >

Re: [PATCH v3 1/3] repack: point out a bug handling stale shallow info

"Johannes Schindelin via GitGitGadget" writes: > From: Johannes Schindelin > > A `git fetch --prune` can turn previously-reachable objects unreachable, > even commits that are in the `shallow` list. A subsequent `git repack > -ad` will then unceremoniously drop those unreachable commits, and

Re: [PATCH 1/3] gpg-interface.c: use flags to determine key/signer info presence

"brian m. carlson" writes: > On Mon, Oct 22, 2018 at 06:38:19PM +0200, Michał Górny wrote: >> Replace the logic used to determine whether key and signer information >> is present to use explicit flags in sigcheck_gpg_status[] array. This >> is more future-proof, since it makes it possible to

Re: [PATCH 1/3] gpg-interface.c: use flags to determine key/signer info presence

On Mon, Oct 22, 2018 at 06:38:19PM +0200, Michał Górny wrote: > Replace the logic used to determine whether key and signer information > is present to use explicit flags in sigcheck_gpg_status[] array. This > is more future-proof, since it makes it possible to add additional > statuses without

[PATCH v3 1/3] repack: point out a bug handling stale shallow info

From: Johannes Schindelin A `git fetch --prune` can turn previously-reachable objects unreachable, even commits that are in the `shallow` list. A subsequent `git repack -ad` will then unceremoniously drop those unreachable commits, and the `shallow` list will become stale. This means that when

[PATCH 1/3] gpg-interface.c: use flags to determine key/signer info presence

Replace the logic used to determine whether key and signer information is present to use explicit flags in sigcheck_gpg_status[] array. This is more future-proof, since it makes it possible to add additional statuses without having to explicitly update the conditions. Signed-off-by: Michał Górny

wrong info from 'git remote show ' about 'git push' configuration

"git remote show " shows wrong information about not yet configured for 'git push' local ref. steps to reproduce: $ git init $ git remote add origin https://github.com/git/git # for example $ git pull origin master $ git remote show origin ... Local ref configured for 'git push': master

[PATCH v4 2/3] git.c: handle_alias: prepend alias info when first argument is -h

Most git commands respond to -h anywhere in the command line, or at least as a first and lone argument, by printing the usage information. For aliases, we can provide a little more information that might be useful in interpreting/understanding the following output by prepending a line telling that

Info

Let's work together to execute this Business ,contact ( dongeh...@hotmail.com) for more details

[PATCH v3 2/3] git.c: handle_alias: prepend alias info when first argument is -h

Most git commands respond to -h anywhere in the command line, or at least as a first and lone argument, by printing the usage information. For aliases, we can provide a little more information that might be useful in interpreting/understanding the following output by prepending a line telling that

Re: [PATCH v2 2/3] git.c: handle_alias: prepend alias info when first argument is -h

On Mon, Oct 01, 2018 at 01:21:06PM +0200, Rasmus Villemoes wrote: > Most git commands respond to -h anywhere in the command line, or at > least as a first and lone argument, by printing the usage > information. For aliases, we can provide a little more information that > might be useful in

[PATCH v2 2/3] git.c: handle_alias: prepend alias info when first argument is -h

Most git commands respond to -h anywhere in the command line, or at least as a first and lone argument, by printing the usage information. For aliases, we can provide a little more information that might be useful in interpreting/understanding the following output by prepending a line telling that

Contact this Email for your payment; info...@consultant.com

in any part of the world, and the maximum daily limit is two thousand united states dollars($2,000.00) valued sum of five million united states dollars ($5m), if you desire to receive your fund this way, kindly re-confirm your info: Thanks for your understanding. Mrs Selin UBA Manager Contact

[PATCH 1/9] multi-pack-index: provide more helpful usage info

The multi-pack-index builtin has a very simple command-line interface. Instead of simply reporting usage, give the user a hint to why the arguments failed. Reported-by: Eric Sunshine Signed-off-by: Derrick Stolee --- builtin/multi-pack-index.c | 16 1 file changed, 8

Unable to build Info pages using "make info"

Hello, I have updated to the latest master and trying to build git plus its Info manuals. I am on RHEL 6.8. It does not have docbook2x-texi, but I was able to install docbook2texi from https://sourceforge.net/p/docbook2x. The whole git build goes fine except when it reaches the "make info&

Re: [PATCH] update-index: there no longer is `apply --index-info`

On Wed, Aug 08, 2018 at 02:35:18PM -0700, Junio C Hamano wrote: > Back when we removed `git apply --index-info` in 2007, we forgot to > adjust the documentation for update-index that reads its output. > > Let's reorder the description of three formats to present the other &

[PATCH] update-index: there no longer is `apply --index-info`

Back when we removed `git apply --index-info` in 2007, we forgot to adjust the documentation for update-index that reads its output. Let's reorder the description of three formats to present the other two formats that are still generated by git commands before this format, and stop mentioning

[PATCH v2 1/2] repack: point out a bug handling stale shallow info

From: Johannes Schindelin A `git fetch --prune` can turn previously-reachable objects unreachable, even commits that are in the `shallow` list. A subsequent `git repack -ad` will then unceremoniously drop those unreachable commits, and the `shallow` list will become stale. This means that when

Re: [PATCH 2/2] fsck: downgrade gitmodulesParse default to "info"

Jeff King writes: > I think you missed it. In the paragraph above the one you > quoted, I said: > >The cgit repository, for example, has a file named >.gitmodules from a pre-submodule attempt at sharing code, >but does not actually have any gitlinks. Indeed. > So I'm curious if you

Re: [PATCH 2/2] fsck: downgrade gitmodulesParse default to "info"

d, I said: The cgit repository, for example, has a file named .gitmodules from a pre-submodule attempt at sharing code, but does not actually have any gitlinks. > > So we're being unnecessarily restrictive without actually > > improving the security in a meaningful way. It woul

Re: [PATCH 2/2] fsck: downgrade gitmodulesParse default to "info"

Is that the "cgit has a file called .gitmodules that predates the submodule support on our side?" thing? > So we're being unnecessarily restrictive without actually > improving the security in a meaningful way. It would be more > convenient to downgrade this check to &q

Re: [PATCH 2/2] fsck: downgrade gitmodulesParse default to "info"

> Considering both sets of arguments, it makes sense to loosen > this check for now. > I agree with this reasoning, > > Signed-off-by: Jeff King This and the previous patch are Reviewed-by: Stefan Beller

[PATCH 1/2] repack: point out a bug handling stale shallow info

From: Johannes Schindelin A `git fetch --prune` can turn previously-reachable objects unreachable, even commits that are in the `shallow` list. A subsequent `git repack -ad` will then unceremoniously drop those unreachable commits, and the `shallow` list will become stale. This means that when

[PATCH 2/2] fsck: downgrade gitmodulesParse default to "info"

t actually improving the security in a meaningful way. It would be more convenient to downgrade this check to "info", which means we'd still comment on it, but not reject a push. Site admins can already do this via config, but we should ship sensible defaults. There are a few counterpoints

info!!

Top of the day to you, this is in respect of a very beneficial transaction which you would not want to let go reply for more details, Regards, Lee

Re: [PATCH 2/3] ls-tree: update usage info

On Mon, Jul 2, 2018 at 11:58 PM Joshua Nelson wrote: > show [tree-ish] and [--] as optional > --- > diff --git builtin/ls-tree.c builtin/ls-tree.c > @@ -26,7 +26,7 @@ static int chomp_prefix; > static const char * const ls_tree_usage[] = { > - N_("git ls-tree [] [...]"), > +

Re: [PATCH 2/3] ls-tree: update usage info

Hi Joshua, On Mon, Jul 2, 2018 at 8:58 PM, Joshua Nelson wrote: > show [tree-ish] and [--] as optional You're missing a Signed-off-by tag here. > --- > builtin/ls-tree.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git builtin/ls-tree.c builtin/ls-tree.c No

[PATCH 2/3] ls-tree: update usage info

show [tree-ish] and [--] as optional --- builtin/ls-tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git builtin/ls-tree.c builtin/ls-tree.c index 14102b052..c5649b09c 100644 --- builtin/ls-tree.c +++ builtin/ls-tree.c @@ -26,7 +26,7 @@ static int chomp_prefix; static const

[PATCH v6 7/8] fetch-pack: put shallow info in output parameter

ccount for additional information which may be provided +* by the transport (e.g. shallow info). +*/ + free_refs(ref_map); + ref_map = get_ref_map(transport->remote, updated_remote_refs, rs, +

Re: [PATCH v5 7/8] fetch-pack: put shallow info in output parameter

On 06/26, Junio C Hamano wrote: > Brandon Williams writes: > > > Expand the transport fetch method signature, by adding an output > > parameter, to allow transports to return information about the refs they > > have fetched. Then communicate shallow status information through this > > mechanism

Re: [PATCH v5 7/8] fetch-pack: put shallow info in output parameter

Brandon Williams writes: > Expand the transport fetch method signature, by adding an output > parameter, to allow transports to return information about the refs they > have fetched. Then communicate shallow status information through this > mechanism instead of by modifying the input list of

[PATCH v5 7/8] fetch-pack: put shallow info in output parameter

ccount for additional information which may be provided +* by the transport (e.g. shallow info). +*/ + free_refs(ref_map); + ref_map = get_ref_map(transport->remote, updated_remote_refs, rs, +

[PATCH v4 7/8] fetch-pack: put shallow info in output parameter

ccount for additional information which may be provided +* by the transport (e.g. shallow info). +*/ + free_refs(ref_map); + ref_map = get_ref_map(transport->remote, updated_remote_refs, rs, +

Re: [PATCH v3 7/8] fetch-pack: put shallow info in output parameter

On 06/25, Jonathan Tan wrote: > > static void update_shallow(struct fetch_pack_args *args, > > - struct ref **sought, int nr_sought, > > + struct ref *refs, > > update_shallow() now takes in a linked list of refs instead of an array. > I see that the

Re: [PATCH v3 7/8] fetch-pack: put shallow info in output parameter

> static void update_shallow(struct fetch_pack_args *args, > -struct ref **sought, int nr_sought, > +struct ref *refs, update_shallow() now takes in a linked list of refs instead of an array. I see that the translation of this function is

[PATCH v3 7/8] fetch-pack: put shallow info in output parameter

ided +* by the transport (e.g. shallow info). +*/ + free_refs(ref_map); + ref_map = get_ref_map(transport->remote, updated_remote_refs, rs, + tags, ); + free_refs(updated_remote_ref

Re: [PATCH v2 7/8] fetch-pack: put shallow info in output parameter

On 06/14, Jonathan Tan wrote: > > @@ -1122,6 +1124,7 @@ static int do_fetch(struct transport *transport, > > int autotags = (transport->remote->fetch_tags == 1); > > int retcode = 0; > > const struct ref *remote_refs; > > + struct ref *new_remote_refs = NULL; > > Above, you use the

Re: [PATCH v2 7/8] fetch-pack: put shallow info in output parameter

> @@ -1122,6 +1124,7 @@ static int do_fetch(struct transport *transport, > int autotags = (transport->remote->fetch_tags == 1); > int retcode = 0; > const struct ref *remote_refs; > + struct ref *new_remote_refs = NULL; Above, you use the name "updated_remote_refs" - it's

Re: [PATCH v2 7/8] fetch-pack: put shallow info in output parameter

> + !oidcmp(>peer_ref->old_oid, >old_oid)) { > + /* > +* These need to be reported as fetched, but we don > not do not or don't; there is no middle way. ;)

[PATCH v2 7/8] fetch-pack: put shallow info in output parameter

Expand the transport fetch method signature, by adding an output parameter, to allow transports to return information about the refs they have fetched. Then communicate shallow status information through this mechanism instead of by modifying the input list of refs. This does require clients to

[PATCH 7/8] fetch-pack: put shallow info in output parameter

Expand the transport fetch method signature, by adding an output parameter, to allow transports to return information about the refs they have fetched. Then communicate shallow status information through this mechanism instead of by modifying the input list of refs. This does require clients to

Re: format-patch: no 'prerequisite-patch-id' info when specifying commit range

On 06/04, Junio C Hamano wrote: >Ye Xiaolong writes: > >> I narrowed down the problem to revision walk, if users specify the commit >> range >> via "Z..C" pattern, the first prepare_revision_walk function called in >> cmd_format_patch would mark all parents (ancestors) of Z to be uninteresting,

Re: format-patch: no 'prerequisite-patch-id' info when specifying commit range

Ye Xiaolong writes: > I narrowed down the problem to revision walk, if users specify the commit > range > via "Z..C" pattern, the first prepare_revision_walk function called in > cmd_format_patch would mark all parents (ancestors) of Z to be uninteresting, > thus the next revision walk in

Re: format-patch: no 'prerequisite-patch-id' info when specifying commit range

Hi, Junio On 05/29, Eduardo Habkost wrote: >Hi, > >I'm trying to use git-format-patch --base to generate the list of >prerequisite patches for a series, but the behavior of git >doesn't seem to match the documentation: > >When using a commit count (e.g.: "-2"), git-format-patch generates the

Re: format-patch: no 'prerequisite-patch-id' info when specifying commit range

Hi, Eduardo On 05/29, Eduardo Habkost wrote: >Hi, > >I'm trying to use git-format-patch --base to generate the list of >prerequisite patches for a series, but the behavior of git >doesn't seem to match the documentation: > >When using a commit count (e.g.: "-2"), git-format-patch generates the

format-patch: no 'prerequisite-patch-id' info when specifying commit range

Hi, I'm trying to use git-format-patch --base to generate the list of prerequisite patches for a series, but the behavior of git doesn't seem to match the documentation: When using a commit count (e.g.: "-2"), git-format-patch generates the prerequisite-patch-id lines as expected. But when

Re: [GSoC] Info: Week 02 Blog Post

On Thu, May 10, 2018 at 11:35 PM, Stefan Beller wrote: > Hi Pratik, Hi Stefan, > On Wed, May 9, 2018 at 8:07 PM, Pratik Karki wrote: >> Hi, >> >> The week 02 blog post[1] is live. This post is part I out of II and this >> time it will be biweekly.

Re: [GSoC] Info: Week 02 Blog Post

Hi Pratik, On Wed, May 9, 2018 at 8:07 PM, Pratik Karki wrote: > Hi, > > The week 02 blog post[1] is live. This post is part I out of II and this > time it will be biweekly. The part II of will come in 2-3 days which > will describe the current `git-rebase.sh`. Cool

[PATCH v7 00/13] Keep all info in command-list.txt in git binary

v7 is mostly code cleanup plus one more change: git-completion.bash now always checks completion.commands config key. This makes it much more convenient to customize the command complete list. You only have to fall back to setting $GIT_COMPLETION_CMD_GROUPS when you have very special needs.

[GSoC] Info: Week 02 Blog Post

Hi, The week 02 blog post[1] is live. This post is part I out of II and this time it will be biweekly. The part II of will come in 2-3 days which will describe the current `git-rebase.sh`. Do give me feedback. Thanks to all the awesome Git contributors for this awesome tool. :-) [1]:

[PATCH v6 00/13] Keep all info in command-list.txt in git binary

b/command-list.txt index 40776b9587..3e21ddfcfb 100644 --- a/command-list.txt +++ b/command-list.txt @@ -1,3 +1,47 @@ +# Command classification list +# --- +# All supported commands, builtin or external, must be described in +# here. This info is used to list commands in vari

Re: [GSoC] Info: new blog series of my work on Git GSoC '18

On Thu, May 3, 2018 at 6:31 AM, Andrew Ardill wrote: > On 2 May 2018 at 17:12, Johannes Schindelin > wrote: >> Hi Pratik, >> >> On Wed, 2 May 2018, Pratik Karki wrote: >> >>> As promised in my proposal, I've started >>> to write a blog series

Re: [GSoC] Info: new blog series of my work on Git GSoC '18

On 2 May 2018 at 17:12, Johannes Schindelin wrote: > Hi Pratik, > > On Wed, 2 May 2018, Pratik Karki wrote: > >> As promised in my proposal, I've started >> to write a blog series of GSoC '18 with Git. The initial blog is up. >> You can find it here[1]. The initial one

Re: [GSoC] Info: new blog series of my work on Git GSoC '18

Hi Pratik, On Wed, 2 May 2018, Pratik Karki wrote: > As promised in my proposal, I've started > to write a blog series of GSoC '18 with Git. The initial blog is up. > You can find it here[1]. The initial one is just to get started and > from next iterations, I'll start detailing of my work

[GSoC] Info: new blog series of my work on Git GSoC '18

Hello mentors, As promised in my proposal, I've started to write a blog series of GSoC '18 with Git. The initial blog is up. You can find it here[1]. The initial one is just to get started and from next iterations, I'll start detailing of my work towards converting rebase to builtin. [1]:

[PATCH v2 02/42] server-info: remove unused members from struct pack_info

The head member of struct pack_info is completely unused and the nr_heads member is used only in one place, which is an assignment. This member was last usefully used in 3e15c67c90 (server-info: throw away T computation as well, 2005-12-04). Since this structure member is not useful, remove

Re: [PATCH 02/41] server-info: remove unused members from struct pack_info

could add that their last use was in 3e15c67c90 (server-info: throw away T computation as well. - 2005-12-04) -- Duy

Re: [PATCH v5 00/10] Keep all info in command-list.txt in git binary

. There will be some special handling for advice.* or color but overall I still think it's a net gain. Listing all recognizable config variables from "git config" (or "git help") would be lovely, but I don't think it helps unless we could print a short summary line each var

[PATCH v5 00/10] Keep all info in command-list.txt in git binary

I think v5 is getting close to what I wanted to achieve from the RFC version (I skip v4 since I sent out v4/wip and another v4 may confuse people). Interdiff is too large to be helpful, but the summary of changes compared to v3 is: - common-cmds.h is renamed to command-list.h - the common group

[Re-send PATCH v7 00/12] Deprecate .git/info/grafts

replace: avoid using die() to indicate a bug replace: "libify" create_graft() and callees replace: prepare create_graft() for converting graft files wholesale replace: introduce --convert-graft-file Add a test for `git replace --convert-graft-file` Deprecate support for .git/

[PATCH v7 08/12] Deprecate support for .git/info/grafts

_header_lines(const char *buf, size_t len, const char **); @@ -176,6 +177,15 @@ static int read_graft_file(const char *graft_file) struct strbuf buf = STRBUF_INIT; if (!fp) return -1; + if (advice_graft_file_deprecated) + advise(_("Support

[PATCH v6 07/11] Deprecate support for .git/info/grafts

_header_lines(const char *buf, size_t len, const char **); @@ -176,6 +177,15 @@ static int read_graft_file(const char *graft_file) struct strbuf buf = STRBUF_INIT; if (!fp) return -1; + if (advice_graft_file_deprecated) + advise(_("Support

[PATCH v6 00/11] Deprecate .git/info/grafts

lace --convert-graft-file` Deprecate support for .git/info/grafts filter-branch: stop suggesting to use grafts technical/shallow: stop referring to grafts technical/shallow: describe why shallow cannot use replace refs Remove obsolete script to convert grafts to replace refs Docu

Re: [PATCH v5 00/11] Deprecate .git/info/grafts

Hi Junio, On Thu, 26 Apr 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > - if (export_object(_oid, type, raw, tmpfile)) > > - return -1; > > - if (launch_editor(tmpfile, NULL, NULL) < 0) > > - return error("editing object file

Re: [PATCH v5 00/11] Deprecate .git/info/grafts

Johannes Schindelin writes: > -if (export_object(_oid, type, raw, tmpfile)) > -return -1; > -if (launch_editor(tmpfile, NULL, NULL) < 0) > -return error("editing object file failed"); > -if (import_object(_oid, type, raw,

[PATCH v4/wip 00/12] Keep all info in command-list.txt in git binary

This is not exactly v4 and likely broken. But I've made several debatable changes and would like your opinions before making even more changes in this direction. In 03/12 I made a format change in command-list.txt. The group description is no longer in this file but in help.c instead. This

[PATCH v5 07/11] Deprecate support for .git/info/grafts

_header_lines(const char *buf, size_t len, const char **); @@ -176,6 +177,15 @@ static int read_graft_file(const char *graft_file) struct strbuf buf = STRBUF_INIT; if (!fp) return -1; + if (advice_graft_file_deprecated) + advise(_("Support

[PATCH v5 00/11] Deprecate .git/info/grafts

replace: "libify" create_graft() and callees replace: introduce --convert-graft-file Add a test for `git replace --convert-graft-file` Deprecate support for .git/info/grafts filter-branch: stop suggesting to use grafts technical/shallow: stop referring to grafts technical/s

Re: [PATCH 02/41] server-info: remove unused members from struct pack_info

em. Good catch. > @@ -228,7 +226,6 @@ static void init_pack_info(const char *infofile, int > force) > for (i = 0; i < num_pack; i++) { > if (stale) { > info[i]->old_num = -1; > - info[i]->nr_heads = 0; &

[PATCH 02/41] server-info: remove unused members from struct pack_info

ad)[20]; } **info; static int num_pack; static const char *objdir; @@ -228,7 +226,6 @@ static void init_pack_info(const char *infofile, int force) for (i = 0; i < num_pack; i++) { if (stale) { info[i]->old_num = -1; - info[

Re: [PATCH v4 00/11] Deprecate .git/info/grafts

On Sat, Apr 21, 2018 at 2:43 AM, Johannes Schindelin wrote: > It is fragile, as there is no way for the revision machinery to say "but > now I want to traverse the graph ignoring the graft file" e.g. when > pushing commits to a remote repository (which, as a

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On 22/04/18 17:12, Duy Nguyen wrote: > On Sun, Apr 22, 2018 at 5:58 PM, Ramsay Jones > wrote: I think you need to try a little harder than this! ;-) >>> >>> Yeah. I did think about grepping the output but decided not to because >>> of gettext poison stuff and

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On Sun, Apr 22, 2018 at 5:58 PM, Ramsay Jones wrote: >>> I think you need to try a little harder than this! ;-) >> >> Yeah. I did think about grepping the output but decided not to because >> of gettext poison stuff and column output in "git help". If we do want >> to

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On 22/04/18 16:22, Duy Nguyen wrote: > On Sun, Apr 22, 2018 at 4:45 PM, Ramsay Jones > wrote: >> >> >> On 21/04/18 17:56, Duy Nguyen wrote: >>> On Sat, Apr 21, 2018 at 06:54:08PM +0200, Nguyễn Thái Ngọc Duy wrote: Changes: - remove the deprecated

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On Sun, Apr 22, 2018 at 4:45 PM, Ramsay Jones wrote: > > > On 21/04/18 17:56, Duy Nguyen wrote: >> On Sat, Apr 21, 2018 at 06:54:08PM +0200, Nguyễn Thái Ngọc Duy wrote: >>> Changes: >>> >>> - remove the deprecated column in command-list.txt. My change break it >>>

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

that git build without error and then the test-suite sailed through with nary a squeak of complaint). Viz: $ ./git help usage: git [--version] [--help] [-C ] [-c =] [--exec-path[=]] [--html-path] [--man-path] [--info-path] [-p | --paginate | --no-pager] [--no-replace-ob

Re: [PATCH v3 0/6] Keep all info in command-list.txt in git binary

On Sat, Apr 21, 2018 at 06:54:08PM +0200, Nguyễn Thái Ngọc Duy wrote: > Changes: > > - remove the deprecated column in command-list.txt. My change break it > anyway if anyone uses it. > - fix up failed tests that I marked in the RFC and kinda forgot about it. > - fix bashisms in

[PATCH v3 0/6] Keep all info in command-list.txt in git binary

Changes: - remove the deprecated column in command-list.txt. My change break it anyway if anyone uses it. - fix up failed tests that I marked in the RFC and kinda forgot about it. - fix bashisms in generate-cmdlist.sh - fix segfaul in "git help" Nguyễn Thái Ngọc Duy (6): git.c: convert

[PATCH v4 07/11] Deprecate support for .git/info/grafts

_header_lines(const char *buf, size_t len, const char **); @@ -176,6 +177,15 @@ static int read_graft_file(const char *graft_file) struct strbuf buf = STRBUF_INIT; if (!fp) return -1; + if (advice_graft_file_deprecated) + advise(_("Support

[PATCH v4 00/11] Deprecate .git/info/grafts

espace commit: Let the callback of for_each_mergetag return on error replace: avoid using die() to indicate a bug replace: "libify" create_graft() and callees replace: introduce --convert-graft-file Add a test for `git replace --convert-graft-file` Deprecate support for .g

[PATCH v3 07/11] Deprecate support for .git/info/grafts

_header_lines(const char *buf, size_t len, const char **); @@ -176,6 +177,15 @@ static int read_graft_file(const char *graft_file) struct strbuf buf = STRBUF_INIT; if (!fp) return -1; + if (advice_graft_file_deprecated) + advise(_("Support

[PATCH v3 00/11] Deprecate .git/info/grafts

array: offer to split a string by whitespace commit: Let the callback of for_each_mergetag return on error replace: avoid using die() to indicate a bug replace: "libify" create_graft() and callees replace: introduce --convert-graft-file Add a test for `git replace --convert-graft

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

On Thu, Apr 19, 2018 at 01:26:18PM +0200, SZEDER Gábor wrote: > On Thu, Apr 19, 2018 at 12:37 PM, Simon Ruderich wrote: >> This doesn't occur on a non-parallel build. > > It does occur in non-parallel builds, too. > > See: > > >

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

On Thu, Apr 19, 2018 at 12:37 PM, Simon Ruderich wrote: > When running make -j$(nproc) with the current pu f9f8c1f765 > (Merge branch 'hn/bisect-first-parent' into pu) I see the > following error: > > GIT_VERSION = 2.17.0.732.gf9f8c1f765 > * new build flags > * new

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

Hello, When running make -j$(nproc) with the current pu f9f8c1f765 (Merge branch 'hn/bisect-first-parent' into pu) I see the following error: GIT_VERSION = 2.17.0.732.gf9f8c1f765 * new build flags * new prefix flags GEN common-cmds.h * new link flags CC ident.o CC hex.o

[PATCH v2 4/7] Deprecate support for .git/info/grafts

_header_lines(const char *buf, size_t len, const char **); @@ -176,6 +177,15 @@ static int read_graft_file(const char *graft_file) struct strbuf buf = STRBUF_INIT; if (!fp) return -1; + if (advice_graft_file_deprecated) + advise(_("Support

[PATCH v2 0/7] Deprecate .git/info/grafts

graft-file` Deprecate support for .git/info/grafts filter-branch: stop suggesting to use grafts technical/shallow: describe the relationship with replace refs technical/shallow: describe why shallow cannot use replace refs Documentation/git-filter-branch.txt | 2 +- Documentation/git

Re: [PATCH] Deprecate support for .git/info/grafts

Hi Stefan, On Fri, 13 Apr 2018, Stefan Beller wrote: > On Fri, Apr 13, 2018 at 3:35 PM, Johannes Schindelin > wrote: > > >> I wonder if we want to offer a migration tool or just leave it at > >> this hint. > > > > There is contrib/convert-grafts-to-replace-refs.sh.

Re: [PATCH] Deprecate support for .git/info/grafts

+ > > 4 files changed, 21 insertions(+) > > Perhaps, as part of this deprecation, the example in > Documentation/git-filter-branch.txt should be updated to suggest > git-replace instead of .git/info/grafts. Good point! > Maybe, also, Documentation/shallow.txt should tal

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

From: "Duy Nguyen" On Wed, Apr 18, 2018 at 12:47 AM, Philip Oakley wrote: > Is that something I should add to my todo to add a 'guide' category > > etc.? I added it too [1]. Not sure if you want anything more on top though. What I've seen is

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

On Wed, Apr 18, 2018 at 12:47 AM, Philip Oakley wrote: >>> > Is that something I should add to my todo to add a 'guide' category > >>> > etc.? >>> >>> I added it too [1]. Not sure if you want anything more on top though. > > > What I've seen is looking good - I've not had as

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

From: "Philip Oakley" : Tuesday, April 17, 2018 11:47 PM From: "Duy Nguyen" : Tuesday, April 17, 2018 5:48 PM On Tue, Apr 17, 2018 at 06:24:41PM +0200, Duy Nguyen wrote: On Sun, Apr 15, 2018 at 11:21 PM, Philip Oakley wrote: >

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

From: "Duy Nguyen" : Tuesday, April 17, 2018 5:48 PM On Tue, Apr 17, 2018 at 06:24:41PM +0200, Duy Nguyen wrote: On Sun, Apr 15, 2018 at 11:21 PM, Philip Oakley wrote: > From: "Duy Nguyen" : Saturday, April 14, 2018 4:44 > PM > >>

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

On Tue, Apr 17, 2018 at 06:24:41PM +0200, Duy Nguyen wrote: > On Sun, Apr 15, 2018 at 11:21 PM, Philip Oakley wrote: > > From: "Duy Nguyen" : Saturday, April 14, 2018 4:44 PM > > > >> On Thu, Apr 12, 2018 at 12:06 AM, Philip Oakley

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

On Sun, Apr 15, 2018 at 11:21 PM, Philip Oakley wrote: > From: "Duy Nguyen" : Saturday, April 14, 2018 4:44 PM > >> On Thu, Apr 12, 2018 at 12:06 AM, Philip Oakley >> wrote: >>> >>> I'm only just catching up, but does/can this

Re: [PATCH/RFC 0/5] Keep all info in command-list.txt in git binary

From: "Duy Nguyen" : Saturday, April 14, 2018 4:44 PM On Thu, Apr 12, 2018 at 12:06 AM, Philip Oakley wrote: I'm only just catching up, but does/can this series also capture the non-command guides that are available in git so that the 'git help -g' can

[PATCH v2 0/6] Keep all info in command-list.txt in git binary

v2 changes - bug fixes spotted by Eric - keep 'git help -av' layout close to what's in git.txt - enable pager for 'git help -av' because it's usually long - move guide list (aka 'help -g') to command-list.txt Nguyễn Thái Ngọc Duy (6): git.c: convert --list-builtins to --list-cmds=builtins

  1   2   3   4   5   6   7   >