Re: [PATCH 3/3] parse-options: only insert newline in help text if needed

Junio C Hamano writes: > Brandon Casey writes: > >> Currently, when parse_options() produces a help message it always emits >> a blank line after the usage text to separate it from the options text. >> If the option spec does not define any switches, or

Re: [PATCH 3/3] parse-options: only insert newline in help text if needed

Brandon Casey writes: > Currently, when parse_options() produces a help message it always emits > a blank line after the usage text to separate it from the options text. > If the option spec does not define any switches, or only defines hidden > switches that will not be

Re* BUG: merge -s theirs is not in effect (does the same as -s ours)

Yaroslav Halchenko writes: > d'oh, indeed there is no git-merge-theirs neither in debian pkg or a freshly > built git and I found a rogue script in the PATH (which did nothing > apparently, sorry!). BUT I was originally mislead by the --help/manpage: Ahh, you're right.

Re: [PATCH v5 4/4] submodule: port submodule subcommand 'status' from shell to C

Prathamesh Chavan writes: > This aims to make git-submodule 'status' a built-in. Hence, the function > cmd_status() is ported from shell to C. This is done by introducing > three functions: module_status(), submodule_status() and print_status(). Well then it does not just aim

[PATCH 2/3] parse-options: write blank line to correct output stream

When commit 54e6dc7 added translation support to parse-options, an fprintf was mistakenly replaced by a call to putchar(). Let's use fputc instead. Fixes t0040.11, t0040.12, t0040.33, and t1502.8. Signed-off-by: Brandon Casey --- parse-options.c | 2 +-

[PATCH 3/3] parse-options: only insert newline in help text if needed

Currently, when parse_options() produces a help message it always emits a blank line after the usage text to separate it from the options text. If the option spec does not define any switches, or only defines hidden switches that will not be displayed, then the help text will end up with two

[PATCH 1/3] t0040,t1502: Demonstrate parse_options bugs

When the option spec contains no switches or only hidden switches, parse_options will emit an extra blank line at the end of help output so that the help text will end in two blank lines instead of one. When parse_options produces internal help output after an error has occurred it will emit

Re: [PATCH v5 3/4] submodule: port set_name_rev() from shell to C

Junio C Hamano writes: > Nicely done. > >> +if (!capture_command(, , 0) && sb.len) { > ... > So, while it is not wrong per-se, I do not think we need to check > revname[0] here. The helper never returns a non-NULL pointer that > points at an empty string, right? >

Re: [PATCH v5 3/4] submodule: port set_name_rev() from shell to C

Prathamesh Chavan writes: > +static char *compute_rev_name(const char *sub_path, const char* object_id) > +{ > + struct strbuf sb = STRBUF_INIT; > + const char ***d; > + > + static const char *describe_bare[] = { > + NULL > + }; > +... > +

how are you today?

I'm happy to inform you about my success in getting the fund transfered to a UK bank with the co-operation of a new company from Argentina. Presently I'm in Argentina for investment projects, I did not forget your company's past efforts in assisting me in transfering those funds

Re: [PATCH v5 2/4] submodule--helper: introduce for_each_listed_submodule()

Prathamesh Chavan writes: > Introduce function for_each_listed_submodule() and replace a loop > in module_init() with a call to it. > > The new function will also be used in other parts of the > system in later patches. > > Mentored-by: Christian Couder

Re: [PATCH v5 1/4] submodule--helper: introduce get_submodule_displaypath()

Prathamesh Chavan writes: > Introduce function get_submodule_displaypath() to replace the code > occurring in submodule_init() for generating displaypath of the > submodule with a call to it. > > This new function will also be used in other parts of the system > in later

Hello,

Hello, I'm Mr. Merle Butler the mega winner of $218M In Mega Millions Jackpot, I'm donating to 5 random individuals if you get this email then your email was selected after a spin ball.I have spread most of my wealth over a number of charities and organizations. I and my wife Patricia Butler have

Re: BUG: merge -s theirs is not in effect (does the same as -s ours)

On Mon, 25 Sep 2017, Junio C Hamano wrote: > Yaroslav Halchenko writes: > > My interest was to get remote branch "merge" the changes in the > > branch taking the branch's version (primarily alternative symlinks > > for git-annex'ed content) over the version in master

Re: BUG: merge -s theirs is not in effect (does the same as -s ours)

Yaroslav Halchenko writes: > My interest was to get remote branch "merge" the changes in the > branch taking the branch's version (primarily alternative symlinks > for git-annex'ed content) over the version in master (previous > merge of a similar branch). Unfortunately -s

Re: [PATCH] docs: improve discoverability of exclude pathspec

Manav Rathi writes: > The ability to exclude paths in pathspecs is not mentioned in the man > pages of git grep and other commands where it might be useful. My reading stutters around "exclude paths in pathspecs" in the above. Perhaps "exclude paths with a negative pathspec"

Re: What's cooking in git.git (Sep 2017, #03; Fri, 15)

Sahil Dua writes: > On Fri, Sep 22, 2017 at 5:39 AM, Junio C Hamano wrote: >> >> So here is such an update. As the topic is not in 'next' yet, it >> could also be implemented by replacing patch(es) in the series, but >> doing it as a follow-up fix

BUG: merge -s theirs is not in effect (does the same as -s ours)

My interest was to get remote branch "merge" the changes in the branch taking the branch's version (primarily alternative symlinks for git-annex'ed content) over the version in master (previous merge of a similar branch). Unfortunately -s theirs seems to do actually -s ours -- symlinks and

Re: [RFC v2] refs: strip out not allowed flags from ref_transaction_update

On 09/21, Michael Haggerty wrote: > On 09/13/2017 12:59 AM, Thomas Gummerer wrote: > > Callers are only allowed to pass certain flags into > > ref_transaction_update, other flags are internal to it. To prevent > > mistakes from the callers, strip the internal only flags out before > > continuing.

Re: [PATCH v2 0/6] reroll ma/plugleaks; more `object_array`-fixes

On 24 September 2017 at 09:01, Junio C Hamano wrote: > Martin Ågren writes: > >> Since Junio collected my "independent" patches into ma/leakplugs, this >> is a re-roll of that whole topic. I got the first two patches from >> Junio's tree. The only

Re: [PATCH v2 0/6] reroll ma/plugleaks; more `object_array`-fixes

On 23 September 2017 at 18:38, Jeff King wrote: > On Sat, Sep 23, 2017 at 12:13:16PM -0400, Jeff King wrote: > >> In theory you should be able to just add "log_path=/tmp/lsan/output" to >> that, which should put all the logs in a convenient place (and stop the >> extra output from

[PATCH] docs: improve discoverability of exclude pathspec

The ability to exclude paths in pathspecs is not mentioned in the man pages of git grep and other commands where it might be useful. Add a pointer to the pathspec syntax and a quick example in the git grep man page to help the user to discover this ability. Add similar pointers from the git-add

Re: What's cooking in git.git (Sep 2017, #03; Fri, 15)

On Fri, Sep 22, 2017 at 5:39 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> My understanding of the next step was for those who are interested >> in moving this topic forward to update these patches in that >> direction. > > Well, I am one of those

Re: [PATCH 1/3] refs: make sha1 output parameter of refs_resolve_ref_unsafe() optional

Am 24.09.2017 um 03:26 schrieb Junio C Hamano: > I wonder if we want a dedicated helper for them (perhaps about a > dozen callers we have that fall into this pattern?) to call for the > exact purpose, implemented as a thin-wrapper around the > resolve_ref_unsafe() function, though.

[PATCH v5 2/4] submodule--helper: introduce for_each_listed_submodule()

Introduce function for_each_listed_submodule() and replace a loop in module_init() with a call to it. The new function will also be used in other parts of the system in later patches. Mentored-by: Christian Couder Mentored-by: Stefan Beller

[PATCH v5 1/4] submodule--helper: introduce get_submodule_displaypath()

Introduce function get_submodule_displaypath() to replace the code occurring in submodule_init() for generating displaypath of the submodule with a call to it. This new function will also be used in other parts of the system in later patches. Mentored-by: Christian Couder

[PATCH v5 3/4] submodule: port set_name_rev() from shell to C

Function set_name_rev() is ported from git-submodule to the submodule--helper builtin. The function compute_rev_name() generates the value of the revision name as required. The function get_rev_name() calls compute_rev_name() and receives the revision name, and later handles its formatting and

[PATCH v5 0/4] Incremental rewrite of git-submodules

Changes in v5: * in print_status() function, we now call compute_rev_name() directly instead of doing the argv setup and calling get_rev_name() function. * Since we no longer use the helper function get_rev_name(), we have removed it from the code base after porting submodule subcommand

[PATCH v5 4/4] submodule: port submodule subcommand 'status' from shell to C

This aims to make git-submodule 'status' a built-in. Hence, the function cmd_status() is ported from shell to C. This is done by introducing three functions: module_status(), submodule_status() and print_status(). The function module_status() acts as the front-end of the subcommand. It parses

Re: [PATCH] git: add --no-optional-locks option

On Thursday 21 September 2017 10:02 AM, Jeff King wrote: > Some tools like IDEs or fancy editors may periodically run > commands like "git status" in the background to keep track > of the state of the repository. I might be missing something, shouldn't the IDEs be encouraged to use libgit2

Re: [PATCH v2] doc: camelCase the config variables to improve readability

On Sun, 2017-09-24 at 09:28 +0900, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > A few configuration variable names of Git are composite words. References > > to such variables in manpages are hard to read because they use > > all-lowercase > > names,

Re: [PATCH v2 0/9] Teach 'run' perf script to read config files

Christian Couder writes: > (It looks like smtp.gmail.com isn't working anymore for me, so I am > trying to send this using Gmail for the cover letter and Submitgit for > the patches.) SubmitGit may want to learn the "change the timestamps of the individual patches by

Re: [PATCH v2 0/6] reroll ma/plugleaks; more `object_array`-fixes

Martin Ågren writes: > Since Junio collected my "independent" patches into ma/leakplugs, this > is a re-roll of that whole topic. I got the first two patches from > Junio's tree. The only difference there is "builtin/" at the very start > of the first commit message.

Re: [PATCH v2 13/21] packed_ref_cache: keep the `packed-refs` file mmapped if possible

Michael Haggerty writes: >> +struct stat st; >> +size_t size, bytes_read; > > Coverity helpfully pointed out that `bytes_read` has to be signed: > `ssize_t`. I'll fix that in the next round after waiting for other comments. Thanks. The macOS build at Travis also