It's expected that Git commands support '-h' in order to provide a
consistent user experience (and this expectation is enforced by the
test suite). '-h' is captured by parse_options() by default; in order to
support this flag, we add a short usage text to walken.c and invo
On Thu, Jun 27, 2019 at 12:47:25AM -0400, Eric Sunshine wrote:
> On Wed, Jun 26, 2019 at 7:51 PM Emily Shaffer wrote:
> > It's expected that Git commands support '-h' in order to provide a
> > consistent user experience (and this expectation is enforced by the
> &
On Wed, Jun 26, 2019 at 7:51 PM Emily Shaffer wrote:
> It's expected that Git commands support '-h' in order to provide a
> consistent user experience (and this expectation is enforced by the
> test suite). '-h' is captured by parse_options() by default; in orde
On Wed, Jun 26, 2019 at 7:51 PM Emily Shaffer wrote:
> It's expected that Git commands support '-h' in order to provide a
> consistent user experience (and this expectation is enforced by the
> test suite). '-h' is captured by parse_options() by default; in orde
It's expected that Git commands support '-h' in order to provide a
consistent user experience (and this expectation is enforced by the
test suite). '-h' is captured by parse_options() by default; in order to
support this flag, we add a short usage text to walken.c and invo
As fetch_objects() is now used only in promisor-remote.c
and should't be used outside it, let's move it into
promisor-remote.c, make it static there, and remove
fetch-object.{c,h}.
Signed-off-by: Christian Couder
---
Makefile | 1 -
fetch-object
One requirement of the Git test suite is that all commands support '-h',
which is captured by parse_options(). In order to support this flag, add
a short usage text to walken.c and invoke parse_options().
With this change, we can now add cmd_walken to the builtins set and
expect tests t
Jeff King writes:
> So it sounds like you did that and the result is not _too_ bad. But I'm
> not sure about doing it automatically with sed. For example...
>
>> diff --git a/packfile.h b/packfile.h
>> index d70c6d9afb..dab50405e0 100644
>> --- a/packfile.h
>> +++ b/packfile.h
>> [...]
>> @@ -43,
On Fri, Apr 12, 2019 at 04:48:21PM -0700, Denton Liu wrote:
> Junio mentioned that there was a push to drop extern from function
> declarations in headers[1]. I decided to do a mass refactoring so we
> could get rid of everything at once, although I'm not sure if that's
> welcome. But I'll send th
As fetch_objects() is now used only in promisor-remote.c
and should't be used outside it, let's move it into
promisor-remote.c, make it static there, and remove
fetch-object.{c,h}.
Signed-off-by: Christian Couder
---
Makefile | 1 -
fetch-object
ffs,
> so for that particular command, I'd want to know if the option
> (e.g. --stat) is applied to the inner or outer diff.
Yeah I'll probably should send "git diff --no-index -h" instead.
> Now back to your topic: Are you planning to send patches that
> autogenera
On Wed, Dec 12, 2018 at 11:47 AM Duy Nguyen wrote:
>
> I'm not going to bother you with patches (yet) but I could use a few
> eyeballs to check the help usage (and perhaps the option grouping) for
> commands that take diff options.
The grouping looks good from a cursory view, but ...
> Forget ab
I'm not going to bother you with patches (yet) but I could use a few
eyeballs to check the help usage (and perhaps the option grouping) for
commands that take diff options.
Forget about hiding irrelevant options for this particular command for
now. This is something we can do later.
usage: git ra
Back when bw/config-h was developed (and backported to Git for Windows), I
came up with a patch to use git_dir if commondir is NULL, and contributed
that as v1 of this patch. However, it was deemed a bug if that happens, so
let's instead detect that condition and report it.
Change sin
On Wed, Nov 14, 2018 at 02:52:24PM +0900, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > Back when bw/config-h was developed (and backported to Git for Windows), I
> > came up with this patch. It seems to not be strictly necessar
"Johannes Schindelin via GitGitGadget"
writes:
> Back when bw/config-h was developed (and backported to Git for Windows), I
> came up with this patch. It seems to not be strictly necessary, but I like
> the safety of falling back to the Git directory when no common directory i
Back when bw/config-h was developed (and backported to Git for Windows), I
came up with this patch. It seems to not be strictly necessary, but I like
the safety of falling back to the Git directory when no common directory is
configured (for whatever reason).
Johannes Schindelin (1
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
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
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
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
The -h output has been referring to the --force command as forcing the
overwriting of local branches, but since "fetch" more generally
fetches all sorts of references in all refs/ namespaces, let's talk
about forcing the update of a a "reference" instead.
This wording wa
The -h output has been referring to the --force command as forcing the
overwriting of local branches, but since "fetch" more generally
fetches all sorts of references in all refs/ namespaces, let's talk
about forcing the update of a a "reference" instead.
This wording wa
red as its base.
So "delta islands" is a way to store objects from
different forks in the same repo and packfile without
having deltas between objects from different forks.
This patch implements the delta islands mechanism in
"delta-islands.{c,h}", but does not yet make u
On Mon, Aug 13, 2018 at 9:00 PM, Jeff King wrote:
> On Mon, Aug 13, 2018 at 05:33:59AM +0200, Christian Couder wrote:
>
>> >> + memcpy(&sha_core, oid->hash, sizeof(uint64_t));
>> >> + rl->hash += sha_core;
>> >
>> > Hmm, so the first 64-bits of the oid of each ref that is part of
>> > this
On Mon, Aug 13, 2018 at 8:11 PM, Jeff King wrote:
> On Mon, Aug 13, 2018 at 01:17:18PM +0100, Ramsay Jones wrote:
>
>> >>> +struct island_bitmap {
>> >>> + uint32_t refcount;
>> >>> + uint32_t bits[];
>> >>
>> >> Use FLEX_ARRAY here? We are slowly moving toward requiring
>> >> certain C99
Reviewed-by: Jonathan Nieder
Signed-off-by: Elijah Newren
---
compat/precompose_utf8.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/precompose_utf8.h b/compat/precompose_utf8.h
index a94e7c4342..6f843d3e1a 100644
--- a/compat/precompose_utf8.h
+++ b/compat
Elijah Newren wrote:
> Signed-off-by: Elijah Newren
> ---
> compat/precompose_utf8.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Jonathan Nieder
The more unusual style is less likely to be recognized by compilers, so
we can waste some I/O re-reading t
On Mon, Aug 13, 2018 at 05:33:59AM +0200, Christian Couder wrote:
> >> + memcpy(&sha_core, oid->hash, sizeof(uint64_t));
> >> + rl->hash += sha_core;
> >
> > Hmm, so the first 64-bits of the oid of each ref that is part of
> > this island is added together as a 'hash' for the island. And t
On Mon, Aug 13, 2018 at 01:17:18PM +0100, Ramsay Jones wrote:
> >>> +struct island_bitmap {
> >>> + uint32_t refcount;
> >>> + uint32_t bits[];
> >>
> >> Use FLEX_ARRAY here? We are slowly moving toward requiring
> >> certain C99 features, but I can't remember a flex array
> >> weather-bal
Signed-off-by: Elijah Newren
---
compat/precompose_utf8.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/precompose_utf8.h b/compat/precompose_utf8.h
index a94e7c4342..6f843d3e1a 100644
--- a/compat/precompose_utf8.h
+++ b/compat/precompose_utf8.h
@@ -1,4 +1,6
On 13/08/18 04:33, Christian Couder wrote:
> On Mon, Aug 13, 2018 at 3:14 AM, Ramsay Jones
[snip]
>> And neither the sha1 or str hash-maps are destroyed here.
>> (That is not necessarily a problem, of course! ;-) )
>
> The instances are declared as static:
>
> static khash_sha1 *island_marks
On Mon, Aug 13, 2018 at 3:14 AM, Ramsay Jones
wrote:
> On 12/08/18 06:11, Christian Couder wrote:
>> Because the inefficiency primarily arises when an
>> object is delitified against another object that does
>
> s/delitified/deltified/ ?
Ok, this will be in the next reroll if any.
>> not exist
rks in the same repo and packfile without
> having deltas between objects from different forks.
>
> This patch implements the delta islands mechanism in
> "delta-islands.{c,h}", but does not yet make use of it.
>
> A few new fields are added in 'struct object_
red as its base.
So "delta islands" is a way to store objects from
different forks in the same repo and packfile without
having deltas between objects from different forks.
This patch implements the delta islands mechanism in
"delta-islands.{c,h}", but does not yet make u
On Sat, Aug 11, 2018 at 4:12 PM, Jeff King wrote:
> On Sat, Aug 11, 2018 at 12:32:32PM +0200, Christian Couder wrote:
>
>> Ok, I have made the following changes in the branch I will send next.
>>
>> diff --git a/delta-islands.c b/delta-islands.c
>> index 92137f2eca..22e4360810 100644
>> --- a/delt
Signed-off-by: Elijah Newren
---
compat/precompose_utf8.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/precompose_utf8.h b/compat/precompose_utf8.h
index a94e7c4342..6f843d3e1a 100644
--- a/compat/precompose_utf8.h
+++ b/compat/precompose_utf8.h
@@ -1,4 +1,6
On Sat, Aug 11, 2018 at 12:32:32PM +0200, Christian Couder wrote:
> Ok, I have made the following changes in the branch I will send next.
>
> diff --git a/delta-islands.c b/delta-islands.c
> index 92137f2eca..22e4360810 100644
> --- a/delta-islands.c
> +++ b/delta-islands.c
> @@ -322,8 +322,7 @@
On Sat, Aug 11, 2018 at 11:04 AM, SZEDER Gábor wrote:
>> diff --git a/delta-islands.c b/delta-islands.c
>> new file mode 100644
>> index 00..448ddcbbe4
>> --- /dev/null
>> +++ b/delta-islands.c
>
>> +static void deduplicate_islands(void)
>> +{
>> + struct remote_island *island, *core =
> diff --git a/delta-islands.c b/delta-islands.c
> new file mode 100644
> index 00..448ddcbbe4
> --- /dev/null
> +++ b/delta-islands.c
> +static void deduplicate_islands(void)
> +{
> + struct remote_island *island, *core = NULL, **list;
> + unsigned int island_count, dst, src, ref,
Signed-off-by: Elijah Newren
---
compat/precompose_utf8.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/precompose_utf8.h b/compat/precompose_utf8.h
index a94e7c4342..6f843d3e1a 100644
--- a/compat/precompose_utf8.h
+++ b/compat/precompose_utf8.h
@@ -1,4 +1,6
Signed-off-by: Elijah Newren
---
sha1dc/sha1.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/sha1dc/sha1.h b/sha1dc/sha1.h
index 1e4e94be54..e9ca7a83ac 100644
--- a/sha1dc/sha1.h
+++ b/sha1dc/sha1.h
@@ -14,6 +14,7 @@ extern "C" {
#ifndef SHA1DC_NO_STANDARD_INCLUDES
#include
red as its base.
So "delta islands" is a way to store objects from
different forks in the same repo and packfile without
having deltas between objects from different forks.
This patch implements the delta islands mechanism in
"delta-islands.{c,h}", but does not yet make u
On Mon, Aug 6, 2018 at 8:54 PM Christian Couder
wrote:
> > Is it worth it? The "pahole" comment in this file is up to date. We
> > use 80 bytes per object. This series makes the struct 88 bytes (I've
> > just rerun pahole).
>
> Did you run it on V1 or on V2? I guess on V2, but then what do you
> t
On Mon, Aug 6, 2018 at 5:53 PM, Duy Nguyen wrote:
> On Sun, Aug 5, 2018 at 8:53 PM Christian Couder
> wrote:
>>
>> As you can see the patch 6/6 (in the v2 of this patch series that I
>> just sent) moves `unsigned int tree_depth` from 'struct object_entry'
>> to 'struct packing_data'. I am not sur
On Sun, Aug 5, 2018 at 8:53 PM Christian Couder
wrote:
>
> On Sun, Jul 22, 2018 at 10:50 AM, Duy Nguyen wrote:
> > On Sun, Jul 22, 2018 at 7:51 AM Christian Couder
> > wrote:
>
> >> diff --git a/pack-objects.h b/pack-objects.h
> >> index edf74dabdd..8eecd67991 100644
> >> --- a/pack-objects.h
>
On Sun, Aug 05, 2018 at 08:53:19PM +0200, Christian Couder wrote:
> - 'layer' is used in add_to_write_order() which is called from many
> places in add_descendants_to_write_order() and compute_write_order()
> for example like this:
>
> for (s = DELTA_SIBLING(e); s; s = DELTA_SIBLING(s
On Sun, Jul 22, 2018 at 10:50 AM, Duy Nguyen wrote:
> On Sun, Jul 22, 2018 at 7:51 AM Christian Couder
> wrote:
>> diff --git a/pack-objects.h b/pack-objects.h
>> index edf74dabdd..8eecd67991 100644
>> --- a/pack-objects.h
>> +++ b/pack-objects.h
>> @@ -100,6 +100,10 @@ struct object_entry {
>>
red as its base.
So "delta islands" is a way to store objects from
different forks in the same repo and packfile without
having deltas between objects from different forks.
This patch implements the delta islands mechanism in
"delta-islands.{c,h}", but does not yet make u
On Tue, Jul 24, 2018 at 09:47:29AM -0700, Junio C Hamano wrote:
> > +/*
> > + * Allocate a new bitmap; if "old" is not NULL, the new bitmap will be a
> > copy
> > + * of "old". Otherwise, the new bitmap is empty.
> > + */
> > +static struct island_bitmap *island_bitmap_new(const struct island_bit
On Sun, Jul 22, 2018 at 07:48:33AM +0200, Christian Couder wrote:
> + /*
> + * We process only trees, as commits and tags have already been handled
> + * (and passed their marks on to root trees, as well. We must make sure
> + * to process them in descending tree-depth order so
Christian Couder writes:
> From: Jeff King
>
> Hosting providers that allow users to "fork" existing
> repos want as much as possible those forks to use a
> small amount of disk space.
"... want those forks to consume as little amount of disk space as
possible?" Or perhaps "... want those fork
On Sun, Jul 22, 2018 at 10:50 AM, Duy Nguyen wrote:
> On Sun, Jul 22, 2018 at 7:51 AM Christian Couder
> wrote:
>> +pack.island::
>> + A regular expression configuring a set of delta islands. See
>> + "DELTA ISLANDS" in linkgit:git-pack-objects[1] for details.
>> +
>
> That section i
On Sun, Jul 22, 2018 at 7:51 AM Christian Couder
wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index a32172a43c..f682e92a1a 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2542,6 +2542,10 @@ Note that changing the compression level will
islands is a way to store objects from
different forks in the same repo and packfile without
having deltas between objects from different forks.
This patch implements the delta islands mechanism in
"delta-islands.{c,h}", but does not yet make use of it.
A few new fields are added in
ess things to go through,
>> that they wouldn't necessarily care about.
>
> Yup, sounds like a sensible criterion to choose between <*.h> and
> <*.c>.
Yes this makes sense. Thanks both. I misunderstood the idiom. Makes
sense in hindsight (& with both of your advices) only to put structs in
the *.h if it's actually used outside of that API. Will move this around
in v5.
be helpful?
>
> I feel like having only the "public" part in the header file also
> helps developers that are just looking for documentation of the
> functions they are looking at, by having less things to go through,
> that they wouldn't necessarily care about.
Yup, sou
On 05/31, Ævar Arnfjörð Bjarmason wrote:
> Move the tracking_name_data struct used in checkout.c into its
> corresponding header file. This wasn't done in 7c85a87c54 ("checkout:
> factor out functions to new lib file", 2017-11-26) when checkout.[ch]
> were created, and is more consistent with the r
Move the tracking_name_data struct used in checkout.c into its
corresponding header file. This wasn't done in 7c85a87c54 ("checkout:
factor out functions to new lib file", 2017-11-26) when checkout.[ch]
were created, and is more consistent with the rest of the codebase.
Signed-off-by: Ævar Arnfjör
On 05/24, Stefan Beller wrote:
> On Thu, May 24, 2018 at 6:37 AM, Robert P. J. Day
> wrote:
> >
> > maybe this is deliberate, but it's confusing that, with git 2.17.0,
> > the output of both "git log -h" and "git show -h" is exactly
On Thu, 24 May 2018, Stefan Beller wrote:
> On Thu, May 24, 2018 at 6:37 AM, Robert P. J. Day
> wrote:
> >
> > maybe this is deliberate, but it's confusing that, with git 2.17.0,
> > the output of both "git log -h" and "git show -h" is exactly
On Thu, May 24, 2018 at 6:37 AM, Robert P. J. Day wrote:
>
> maybe this is deliberate, but it's confusing that, with git 2.17.0,
> the output of both "git log -h" and "git show -h" is exactly the same:
>
> $ git log -h
> usage: git log [] [] [[-
maybe this is deliberate, but it's confusing that, with git 2.17.0,
the output of both "git log -h" and "git show -h" is exactly the same:
$ git log -h
usage: git log [] [] [[--] ...]
or: git show [] ...
-q, --quiet suppress diff output
--source
ing.sh| 197 +
utf8.c | 37 +++
utf8.h | 25 +
12 files changed, 549 insertions(+), 30 deletions(-)
create mode 100755 t/t0028-checkout-encoding.sh
--
2.16.0.rc0.4.ga4e00d4fa4
ounting right. A little bit of OCD perhaps?
> The fact that "-?" already works for most things is good, but the
> transition pain still remains, as what's costly is to transition
> people's expectation (i.e. "'-?' and not '-h' is the way to get
uot;-?", and somehow forgot that it "works" more or
less already.
The fact that "-?" already works for most things is good, but the
transition pain still remains, as what's costly is to transition
people's expectation (i.e. "'-?' and not '-h' is the way to get
short help from any subcommand"), not the implementation to fill the
gaps for those that do not yet support '-?', I am afraid.
that the option
is unknown and then show the short help text.
If we removed the special handling for "-h" from parse-options it would
do the same for most commands, i.e. we'd get an additional error
message, followed by the short help text that we're used to see. We
could ch
René Scharfe writes:
> FWIW, I use "-?" for that everywhere. I have yet to find a command or
> environment where it does something dangerous.
Yeah, it would have made the world a better place if we made that
choice back in 2008. If we start a transition to make it so right
now, we might be abl
Am 20.10.2017 um 07:35 schrieb Junio C Hamano:
> Jeff King writes:
>
>> It seems weird and inconsistent to me that the meaning of "-h"
>> depends on the position and presence of other unrelated options.
The position is relevant with parse-options for *each* flag fo
On Fri, Oct 20, 2017 at 02:35:36PM +0900, Junio C Hamano wrote:
> I may be biased as every time I think about this one, the first one
> that comes to my mind is how "grep -h" (not "git grep", but GNU
> grep) behaves. Yes, "-h" means something else, but
Jeff King writes:
> It seems weird and inconsistent to me that the meaning of "-h"
> depends on the position and presence of other unrelated options. Maybe
> it's just me. I know _why_ it's that way, but this seems like one of
> those weird corners of the interf
On Fri, Oct 20, 2017 at 10:04:23AM +0900, Junio C Hamano wrote:
> > Yuck. This "we only treat -h as special in certain cases" rule is
> > sufficiently magical that I don't think we want to advertise and lock
> > ourselves into it.
>
> Hmph. I think it is w
++ b/Documentation/git-ls-remote.txt
>> @@ -29,6 +29,9 @@ OPTIONS
>> These options are _not_ mutually exclusive; when given
>> both, references stored in refs/heads and refs/tags are
>> displayed.
>> ++
>> +*NOTE*: -h without any other parameters shows
29,9 @@ OPTIONS
> These options are _not_ mutually exclusive; when given
> both, references stored in refs/heads and refs/tags are
> displayed.
> ++
> +*NOTE*: -h without any other parameters shows a short help text instead
> +of any refs.
Yuck. This "we only treat -
Am 18.10.2017 um 01:22 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Stop advertising -h as the short equivalent of --heads, because it's
>> used for showing a short help text for almost all other git commands.
>> Since the ba5f28bf79 (ls-remote: use parse-opt
René Scharfe writes:
> Stop advertising -h as the short equivalent of --heads, because it's
> used for showing a short help text for almost all other git commands.
> Since the ba5f28bf79 (ls-remote: use parse-options api) it has only
> been working when used together with other
René Scharfe wrote:
> Stop advertising -h as the short equivalent of --heads, because it's
> used for showing a short help text for almost all other git commands.
> Since the ba5f28bf79 (ls-remote: use parse-options api) it has only
> been working when used together with other
On 17 October 2017 at 17:39, René Scharfe wrote:
> Stop advertising -h as the short equivalent of --heads, because it's
> used for showing a short help text for almost all other git commands.
> Since the ba5f28bf79 (ls-remote: use parse-options api) it has only
> been working w
Stop advertising -h as the short equivalent of --heads, because it's
used for showing a short help text for almost all other git commands.
Since the ba5f28bf79 (ls-remote: use parse-options api) it has only
been working when used together with other parameters anyway.
Signed-off-by: Rene Sc
Am 15.10.2017 um 13:08 schrieb Martin Ågren:
> On 15 October 2017 at 12:02, Thomas Rikl wrote:
>> Example:
>>
>> tom1 ~/emacs/spacemacs/.emacs.d $ export LANG=en_US.utf8
>>
>> tom1 ~/emacs/spacemacs/.emacs.d $ git ls-remote -h
>> usage: git ls-remote [--
On 15 October 2017 at 12:02, Thomas Rikl wrote:
> Example:
>
> tom1 ~/emacs/spacemacs/.emacs.d $ export LANG=en_US.utf8
>
> tom1 ~/emacs/spacemacs/.emacs.d $ git ls-remote -h
> usage: git ls-remote [--heads] [--tags] [--refs] [--upload-pack=]
> [-q |
Example:
tom1 ~/emacs/spacemacs/.emacs.d $ export LANG=en_US.utf8
tom1 ~/emacs/spacemacs/.emacs.d $ git ls-remote -h
usage: git ls-remote [--heads] [--tags] [--refs] [--upload-pack=]
[-q | --quiet] [--exit-code] [--get-url]
[--symref] [ [...]]
-q
Hi Jonathan,
> > This regression was fixed in 91a640ffb6d9 ("ls-remote: a lone "-h" is
> > [...]
>
> Without this patch, I'm able to run
>
> git ls-remote -h .
>
> This patch removes that support. Intended?
*hihi* okay it was to counte
Hi,
Silvio Fricke wrote:
> This regression was fixed in 91a640ffb6d9 ("ls-remote: a lone "-h" is
> asking for help") and the wrong help text was introduced in ba5f28bf79ea
> ("ls-remote: use parse-options api").
> This patch removes the "-h"
This regression was fixed in 91a640ffb6d9 ("ls-remote: a lone "-h" is
asking for help") and the wrong help text was introduced in ba5f28bf79ea
("ls-remote: use parse-options api").
This patch removes the "-h" on the help text.
Signed-off-by: Silvio Fricke
On Tue, Jun 13, 2017 at 04:08:03PM -0700, Jonathan Nieder wrote:
> > +test_expect_success 'generate builtin list' '
> > + git --list-builtins >builtins
> > +'
> > +
> > +while read builtin
> > +do
> > + test_expect_success &q
> + git --list-builtins >builtins
> +'
> +
> +while read builtin
> +do
> + test_expect_success "$builtin can handle -h" '
> + test_expect_code 129 git $builtin -h >output 2>&1 &&
> + test_i18ngrep usage output
> + '
> +done
Jeff King writes:
> If we don't mind a one-time pain, I think we can just convert the
> existing usage() to something more like usage_with_options(). The patch
> below does that (and teaches the latter to handle a NULL options field).
>
> The diff is ugly, and the conversion is mostly mechanical.
; >
> > -- >8 --
> > Subject: [PATCH] diff- and log- family: handle "git cmd -h" early
> > ...
>
> And then the check_help_option() thing may look like this.
>
> I am not proud of the way it "unifies" the two styles of usage
> strings,
On Thu, Jun 01, 2017 at 02:42:13PM +0900, Junio C Hamano wrote:
> For now, I will mix this in when queuing the whole thing in 'pu', as
> I hate to push out something that does not even work for me to the
> general public.
>
> -- >8 --
> Subject: [PATCH] diff- and
Junio C Hamano writes:
> For now, I will mix this in when queuing the whole thing in 'pu', as
> I hate to push out something that does not even work for me to the
> general public.
>
> -- >8 --
> Subject: [PATCH] diff- and log- family: handle "g
Junio C Hamano writes:
> Heh, I found another ;-)
>
> 95e98cd9 ("revision.c: use refs_for_each*() instead of
> for_each_*_submodule()", 2017-04-19), which is in the middle of
> Duy's nd/prune-in-worktree series, does this:
> ...
> when jk/consistent-h is mer
On Thu, Jun 01, 2017 at 01:17:55PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Anyway, the problem is sk/dash-is-previous, specifically fc5684b47
> > (revision.c: args starting with "-" might be a revision, 2017-02-25). It
> > looks like the revisi
Jeff King writes:
> Anyway, the problem is sk/dash-is-previous, specifically fc5684b47
> (revision.c: args starting with "-" might be a revision, 2017-02-25). It
> looks like the revision parser used to just bail on "-h", because
> revision.c would say &
Jeff King writes:
> And the idea is that ranges like "-.." should work. TBH, I'm not sure
> how I feel about that, for exactly the reason that came up here: it
> makes it hard to syntactically differentiate the "-" shorthand from
> actual options. We do have @{-1} already for this purpose. I don'
[+cc Siddharth, so quoting copiously]
On Tue, May 30, 2017 at 11:27:56AM -0400, Jeff King wrote:
> > Travis seems to be seeing the same failure. Curiously, the topic by
> > itself passes for me; iow, pu fails, pu^2 doesn't fail.
> >
> > git.git/pu$
you?
>
> Travis seems to be seeing the same failure. Curiously, the topic by
> itself passes for me; iow, pu fails, pu^2 doesn't fail.
>
> git.git/pu$ ./git rev-list -h
> BUG: environment.c:173: setup_git_env called without repository
> Aborted (core dumped)
es for me; iow, pu fails, pu^2 doesn't fail.
git.git/pu$ ./git rev-list -h
BUG: environment.c:173: setup_git_env called without repository
Aborted (core dumped)
Hmph...
-builtins >builtins
> >> > +'
> >> > +
> >> > +while read builtin
> >> > +do
> >> > +test_expect_success "$builtin can handle -h" '
> >> > +test_expect_code 129 git $builtin -h >
Jeff King writes:
> On Tue, May 30, 2017 at 03:03:18PM +0900, Junio C Hamano wrote:
>
>> > +test_expect_success 'generate builtin list' '
>> > + git --list-builtins >builtins
>> > +'
>> > +
>> > +while
1 - 100 of 159 matches
Mail list logo
