I'm not altogether sure the best way to update the internal usage
from git-log -h, but this at least updates the man page.
Signed-off-by: Lawrence Siebert
---
Documentation/git-log.txt | 2 ++
Documentation/rev-list-options.txt | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
di
Moving commit counting from rev-list into list-object which is a step
toward letting git log do counting as well.
Signed-off-by: Lawrence Siebert
---
builtin/rev-list.c | 12 ++--
list-objects.c | 14 ++
list-objects.h | 1 +
3 files changed, 17 insertions(+), 10 del
adds --count from git rev-list to git log, without --use-bitmap-index
for the moment.
Signed-off-by: Lawrence Siebert
---
builtin/log.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/builtin/log.c b/builtin/log.c
index 8781049..ce6df1e 100644
--- a/builtin/log
added test comparing output between git log --count HEAD and
git rev-list --count HEAD
Signed-off-by: Lawrence Siebert
---
t/t4202-log.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 1b2e981..077952b 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-lo
On 07/01/2015 09:10 PM, Karsten Blees wrote:
Of course, it would be nice to hear other opinions as well - this
probably shouldn't be a discussion between the two of us :-)
Karsten
I like this paragraf from your previous mail, I think it can go
into i18n.txt "as is":
ISO-8859-x file names may
On Wed, Jul 1, 2015 at 9:07 PM, Duy Nguyen wrote:
> On Thu, Jul 2, 2015 at 12:13 AM, Eric Sunshine
> wrote:
>>>I noticed GIT_CHECKOUT_NEW_WORKTREE environment variabl that does
>>>not seem to be documented. Is this something we still need?
>>>The log message of 529fef20 (checkout: s
On Thu, Jul 2, 2015 at 12:13 AM, Eric Sunshine wrote:
>>I noticed GIT_CHECKOUT_NEW_WORKTREE environment variabl that does
>>not seem to be documented. Is this something we still need?
>>The log message of 529fef20 (checkout: support checking out into
>>a new working directory, 201
What's cooking in git.git (Jul 2015, #01; Wed, 1)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in
The first release candidate for the upcoming Git v2.5.0 is now
available for testing at the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the
'v2.5.0-rc1' tag and the 'master' branch that the
Matthieu Moy writes:
> Actually, we can do simpler: we still have the original line available,
> ...
>
> I took this (modulo s/line.len[0]/line.buf[0]/, and s/rtrim/trim/ to be
> robust to leading whitespace (not really important, but doesn't harm).
I'd prefer us to be more strict when we know w
Matthieu Moy writes:
> So activating --follow for all "git log" calls would prevent log from
> being used with several pathspecs.
>
> Or, do you have a preparation patch that allows --follow with multiple
> pathspecs? ;-)
>
> In any case, you have to test "git log -- path1 path2" with the option
David Turner writes:
> diff --git a/builtin/log.c b/builtin/log.c
> index 8781049..11b8d82 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -31,6 +31,7 @@ static const char *default_date_mode = NULL;
>
> static int default_abbrev_commit;
> static int default_show_root = 1;
> +static in
From: Guillaume Pagès
git status gives more information during rebase -i, about the list of
command that are done during the rebase. It displays the two last
commands executed and the two next lines to be executed. It also gives
hints to find the whole files in .git directory.
Signed-off-by: Gui
From: Guillaume Pagès
Expand test coverage with one or more than two commands done
and with zero, one or more than two commands remaining.
Signed-off-by: Guillaume Pagès
Signed-off-by: Junio C Hamano
Signed-off-by: Matthieu Moy
---
No modification.
t/t7512-status-help.sh | 87 ++
From: Guillaume Pagès
Signed-off-by: Guillaume Pagès
Signed-off-by: Junio C Hamano
Signed-off-by: Matthieu Moy
---
No modification.
t/t7512-status-help.sh | 28 ++--
wt-status.c| 5 -
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/t/
From: Guillaume Pagès
Signed-off-by: Guillaume Pagès
Signed-off-by: Junio C Hamano
Signed-off-by: Matthieu Moy
---
No modification.
wt-status.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index eaed4fe..8c4b
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> +strbuf_trim(split[1]);
>> +if (!get_sha1(split[1]->buf, sha1)) {
>> +abbrev = find_unique_abbrev(sha1, DEFAULT_ABBREV);
>> +strbuf_reset(split[1]);
>> +strbuf_a
Dave Borowitz writes:
>> I am moderately negative about this; wouldn't it make the end result
>> cleaner to fix the implementation?
>
> I'm not sure I understand your suggestion. Are you saying, you would
> prefer to make LFs optional in the push cert, for consistency with LFs
> being optional el
Junio C Hamano writes:
>> I am moderately negative about this; wouldn't it make the end result
>> cleaner to fix the implementation?
>
> I think that something like this should be sufficient. As the
> receiving end, we must not complain if there is no terminator.
> ...
And the change we are *no
Junio C Hamano writes:
> Dave Borowitz writes:
>
>> Signed-off-by: Dave Borowitz
>> ---
>> Documentation/technical/pack-protocol.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/technical/pack-protocol.txt
>> b/Documentation/technical/pack-protocol.txt
>> index
On Wed, Jul 1, 2015 at 1:00 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> Signed-off-by: Dave Borowitz
>> ---
>> Documentation/technical/pack-protocol.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/technical/pack-protocol.txt
>> b/Documentation/technic
Dave Borowitz writes:
> Signed-off-by: Dave Borowitz
> ---
> Documentation/technical/pack-protocol.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/technical/pack-protocol.txt
> b/Documentation/technical/pack-protocol.txt
> index 1386840..2d8b1a1 100644
> --- a/Docu
On Wed, Jul 1, 2015 at 12:39 PM, Jonathan Nieder wrote:
> Hi,
>
> Dave Borowitz wrote:
>
>> --- a/Documentation/technical/pack-protocol.txt
>> +++ b/Documentation/technical/pack-protocol.txt
>> @@ -14,6 +14,17 @@ data. The protocol functions to have a server tell a
>> client what is
>> currentl
Jonathan Nieder writes:
> The 'Reference Discovery' section says:
>
> Server SHOULD terminate each non-flush line using LF ("\n") terminator;
> client MUST NOT complain if there is no terminator.
I think these should be "sender/receiver", not "server/client".
--
To unsubscribe from t
Hi,
Dave Borowitz wrote:
> --- a/Documentation/technical/pack-protocol.txt
> +++ b/Documentation/technical/pack-protocol.txt
> @@ -14,6 +14,17 @@ data. The protocol functions to have a server tell a
> client what is
> currently on the server, then for the two to negotiate the smallest amount
>
On Wed, Jul 1, 2015 at 12:07 PM, Junio C Hamano wrote:
> Answering myself, the most trivial example is "git send-pack" ;-)
> It passes args that has a NULL in the .url field.
Well, the example I have involves an actual "git push" command. The
fact that .url is NULL in that case may be a separate
As a "distributed" VCS, git should better define the encodings of its core
textual data structures, in particular those that are part of the network
protocol.
That git is encoding agnostic is only really true for blob objects. E.g.
the 'non-NUL bytes' requirement of tree and commit objects exclude
Signed-off-by: Karsten Blees
---
...just changed wording as you suggested.
Documentation/technical/racy-git.txt | 8 ++--
Makefile | 9 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/technical/racy-git.txt
b/Documentation
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Dave Borowitz writes:
>>
>>> send-pack.c omits this field when args->url is null or empty. Fix the
>>> protocol specification to match reality.
>>
>> Do some clients omit this in the real world?
>>
>> As you say, send_pack() does omit it if a
Junio C Hamano writes:
> Dave Borowitz writes:
>
>> send-pack.c omits this field when args->url is null or empty. Fix the
>> protocol specification to match reality.
>
> Do some clients omit this in the real world?
>
> As you say, send_pack() does omit it if args->url is null or empty,
> but arg
On Wed, Jul 1, 2015 at 11:56 AM, Junio C Hamano wrote:
> Do some clients omit this in the real world?
I just sent you privately a trace where this happens using a recent
git client. With that in the wild, I think our server is going to have
to handle these even if there is a bug and it is fixed p
Many users prefer to always use --follow with logs. Rather than
aliasing the command, an option might be more convenient for some.
Signed-off-by: David Turner
---
Why not just alias log=log --follow?
At Twitter, we manage git config centrally, but we also allow users to
add their own aliases.
Jeff King writes:
> On Wed, Jul 01, 2015 at 08:19:40AM -0700, Junio C Hamano wrote:
>
>> Sounds good. While at it, perhaps add a mention (perhaps by
>> creating a BUGS section at the end of the file) that --count
>> with --use-bitmap-index ignores pathspec silently?
>
> I think we can just fix i
Dave Borowitz writes:
> This is sort of like a standard identity, except that RFC 4880 section
> 4.11 allows any UTF-8 text in the User ID packet. It is trivial to get
> gpg to pass arbitrary text when generating a push cert by setting
> user.signingKey to that arbitrary value (assuming it is an
Dave Borowitz writes:
> send-pack.c omits this field when args->url is null or empty. Fix the
> protocol specification to match reality.
Do some clients omit this in the real world?
As you say, send_pack() does omit it if args->url is null or empty,
but args is prepared in transport.c as a copy
Eric Sunshine writes:
> On Wed, Jul 1, 2015 at 1:13 PM, Eric Sunshine wrote:
>> On Wed, Jul 1, 2015 at 12:53 PM, Junio C Hamano wrote:
>>> * Duy seems to think "worktree add" is coming, too, so here is a
>>>trivial tweak of your patch from the last month, with test
>>>adjustments to 74
On Wed, Jul 1, 2015 at 11:21 AM, Stefan Beller wrote:
> I think the problem with this part of the documentation is its ambiguity on
> what exactly we want to document. The sender SHOULD put an LF, while
> the receiver MUST NOT assume the LF is there always, so I guess it's best
> to mark it option
On Wed, Jul 01, 2015 at 08:19:40AM -0700, Junio C Hamano wrote:
> Sounds good. While at it, perhaps add a mention (perhaps by
> creating a BUGS section at the end of the file) that --count
> with --use-bitmap-index ignores pathspec silently?
I think we can just fix it rather than documenting the
On Wed, Jul 1, 2015 at 11:08 AM, Dave Borowitz wrote:
> Signed-off-by: Dave Borowitz
> ---
> Documentation/technical/pack-protocol.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/technical/pack-protocol.txt
> b/Documentation/technical/pack-protocol.txt
On Wed, Jul 1, 2015 at 1:13 PM, Eric Sunshine wrote:
> On Wed, Jul 1, 2015 at 12:53 PM, Junio C Hamano wrote:
>> * Duy seems to think "worktree add" is coming, too, so here is a
>>trivial tweak of your patch from the last month, with test
>>adjustments to 7410 I sent earlier squashed in.
pack-protocol.txt does not list the nonce as optional. Fortunately, it
should be impossible to not have a nonce by this point in the code, as
the caller should have died on line 380 prior to generating a push
certificate with an empty nonce.
Nonetheless, having this explicit error handling in the
send-pack.c omits this field when args->url is null or empty. Fix the
protocol specification to match reality.
Signed-off-by: Dave Borowitz
---
Documentation/technical/pack-protocol.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/pack-protocol
We want to fix such inaccuracies, but there are a lot and there is no
guarantee at any particular point in time that this document will be
error-free.
Signed-off-by: Dave Borowitz
---
Documentation/technical/pack-protocol.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Docum
Signed-off-by: Dave Borowitz
---
Documentation/technical/pack-protocol.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index 66d2d95..1386840 100644
--- a/Documentation/technical/pack-pr
The signed push protocol documentation did not really match the reality of what
send-pack.c and receive-pack.c do, much to my chagrin as I attempted to
implement this protocol in JGit. This series covers most of the issues I found
on a first pass.
Dave Borowitz (7):
pack-protocol.txt: Add warnin
Signed-off-by: Dave Borowitz
---
Documentation/technical/pack-protocol.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index 1386840..2d8b1a1 100644
--- a/Documentation/technical/pack-protocol.txt
++
This is sort of like a standard identity, except that RFC 4880 section
4.11 allows any UTF-8 text in the User ID packet. It is trivial to get
gpg to pass arbitrary text when generating a push cert by setting
user.signingKey to that arbitrary value (assuming it is an actual user
ID associated with t
The use of "must" (albeit not in all caps) suggests that this is
actually a requirement of the protocol. As no implementation exists
that actually does this verification, this is misleading at best.
Signed-off-by: Dave Borowitz
---
Documentation/technical/pack-protocol.txt | 3 ++-
1 file change
Eric Sunshine writes:
> Thanks. I was planning on re-rolling to use the new name ...
> ...
> For the re-roll, I was planning on renaming it to
> GIT_NEW_WORKTREE_MODE or something (or add a private command-line
> option to checkout, but that may be overkill).
OK, thanks, then I'll stop worrying
On Wed, Jul 1, 2015 at 1:13 PM, Eric Sunshine wrote:
> On Wed, Jul 1, 2015 at 12:53 PM, Junio C Hamano wrote:
>> From: Eric Sunshine
>>
>> The command "git checkout --to " is something of an anachronism,
>> encompassing functionality somewhere between "checkout" and "clone".
>> The introduction
On Wed, Jul 1, 2015 at 12:53 PM, Junio C Hamano wrote:
> From: Eric Sunshine
>
> The command "git checkout --to " is something of an anachronism,
> encompassing functionality somewhere between "checkout" and "clone".
> The introduction of the git-worktree command, however, provides a proper
> and
On Wed, Jul 1, 2015 at 3:22 AM, Paul Tan wrote:
> On Tue, Jun 30, 2015 at 7:56 AM, Stefan Beller wrote:
>> I realize this was in am.sh as well, but I find the help strings a bit
>> unfortunate.
>> (Yes, you actually need to look them up at another place as most people are
>> not familiar with the
From: Eric Sunshine
The command "git checkout --to " is something of an anachronism,
encompassing functionality somewhere between "checkout" and "clone".
The introduction of the git-worktree command, however, provides a proper
and intuitive place to house such functionality. Consequently,
re-impl
On Wed, Jul 1, 2015 at 1:01 AM, Paul Tan wrote:
> On Tue, Jun 30, 2015 at 7:51 AM, Stefan Beller wrote:
>> I needed to read this patch a few times as this patch introduces
>> `sign_commit`
>> twice. This is mostly a review problem I'd guess as in the code it
>> just affects this
>> method and yo
On Wed, Jul 1, 2015 at 12:36 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> I was about to mention the same shortcoming, but you beat me to it.
>>
>>> Perhaps be more strict and do this instead (without
>>> leading strbuf_trim):
>>>
>>> if (!get_sha1_hex(split[1]->buf, sha1) &&
>>
Eric Sunshine writes:
> I was about to mention the same shortcoming, but you beat me to it.
>
>> Perhaps be more strict and do this instead (without
>> leading strbuf_trim):
>>
>> if (!get_sha1_hex(split[1]->buf, sha1) &&
>> !strcmp(split[1]->buf + 40, " ") {
>>
On Wed, Jul 1, 2015 at 12:18 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>> +/*
>> + * Turn
>> + * pick d6a2f0303e897ec257dd0e0a39a5ccb709bc2047 some message
>> + * into
>> + * pick d6a2f03 some message
>> + */
>> +static void abbrev_sha1_in_line(struct strbuf *line)
>> +{
>> + struct st
Thanks, will queue.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Matthieu Moy writes:
> +/*
> + * Turn
> + * pick d6a2f0303e897ec257dd0e0a39a5ccb709bc2047 some message
> + * into
> + * pick d6a2f03 some message
> + */
> +static void abbrev_sha1_in_line(struct strbuf *line)
> +{
> + struct strbuf **split;
> + int i;
> +
> + if (starts_with(line->buf
Lawrence Siebert writes:
> --count should be mentioned in the usage guide, this updates code and
> documentation.
>
> Signed-off-by: Lawrence Siebert
> ---
Sounds good. While at it, perhaps add a mention (perhaps by
creating a BUGS section at the end of the file) that --count
with --use-bitmap
Jeff King writes:
> Note that this would not work with, say:
>
> git rev-list --use-bitmap-index --count HEAD -- Makefile
>
> as the bitmap index does not have enough information to do path limiting
> (we should probably disallow this or fall back to the non-bitmap code
> path, but right now we
It is sometimes useful for importers to be able to read the SHA-1
corresponding to a mark that they have created via fast-import. For
example, they might want to embed the SHA-1 into the commit message of
a later commit. Or it might be useful for internal bookkeeping uses,
or for logging.
Add a "g
On Tue, Jun 30, 2015 at 08:00:53PM -0700, Lawrence Siebert wrote:
> The following doesn't currently run: `git rev-list --count
> --use-bitmap-index HEAD`
>
> This is an optional parameter for rev-list from commit
> aa32939fea9c8934b41efce56015732fa12b8247 which can't currently be used
> because
Dear
Good day
Pocket size mini foldable monopod selfie stick with bt shutter button on stick,
now only $3/pc ,only from us,the arcpeaks factory
http://arcpeaks.en.alibaba.com/product/60228194355-801021588/2015_original_factory_foldable_bluetooth_monopod_mini_selfie_stick.html
Please feel free to
Commit 28fcc0b (pathspec: avoid the need of "--" when wildcard is used -
2015-05-02) changes how the disambiguation rules work. This patch adds
some tests to demonstrate, basically, if wildcard characters are in an
argument:
- if the argument is valid extended sha-1 syntax, "--" must be used
- o
On Tue, Jun 30, 2015 at 11:33 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> I think this is like "git checkout -b" vs "git branch". We pack so
>> many things in 'checkout' that it's a source of both convenience and
>> confusion. I never use "git branch" to create a new branch and if I
>> ha
On Mon, Jun 29, 2015 at 11:13 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Commit 23af91d (prune: strategies for linked checkouts - 2014-11-30)
>> adds "--worktrees" to "git prune" without realizing that "git prune" is
>> for object database only. This patch moves the same funct
On Tue, Jun 30, 2015 at 7:56 AM, Stefan Beller wrote:
> I realize this was in am.sh as well, but I find the help strings a bit
> unfortunate.
> (Yes, you actually need to look them up at another place as most people are
> not familiar with the apply options).
Yeah I agree, it would be an improvem
On Wed, Jul 1, 2015 at 5:41 PM, Paul Tan wrote:
> Good point, I agree with this. I'll look into putting the error messages back.
This should work I think. It should take into account that O_RDONLY,
O_WRONLY, O_RDWR is defines as 0, 1, 2 on glibc, while the POSIX spec
also defines that O_RDONLY |
On Thu, Jun 25, 2015 at 2:39 AM, Johannes Schindelin
wrote:
> IMO the varargs make the code more cumbersome to read (and even fragile,
> because you can easily call `xopen(path, O_WRITE | O_CREATE)` and would not
> even get so much as a compiler warning!)
I think that since xopen() is a wrapper
--count should be mentioned in the usage guide, this updates code and
documentation.
Signed-off-by: Lawrence Siebert
---
Documentation/git-rev-list.txt | 1 +
builtin/rev-list.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-r
On Tue, Jun 30, 2015 at 4:32 AM, Stefan Beller wrote:
> On Mon, Jun 29, 2015 at 1:32 PM, Stefan Beller wrote:
>> On Sun, Jun 28, 2015 at 7:06 AM, Paul Tan wrote:
>>> + tz = tz / (60 * 60) * 100 + tz % (60 * 60);
>>
>> What happens if we have a negative input not matching a
On Tue, Jun 30, 2015 at 4:32 AM, Stefan Beller wrote:
> for calculating the minutes we would only need to take % 3600 (which
> you do), but
> then we still need to divide by 60 to convert seconds to minutes?
Whoops, yes we do. It should be:
tz = tz / 3600 * 100 + tz % 3600 / 60;
tz = -tz;
Howev
Remi Lespinet writes:
>> I'd vote for keeping it simple and not having the copyright notice. Most
>> t/*.sh do not have one. The Git history + mailing-list archives are much
>> better than in-code comments to keep track of who wrote what.
>
>> Remi: any objection on removing it?
>
> Sorry for not
From: Guillaume Pagès
Expand test coverage with one or more than two commands done
and with zero, one or more than two commands remaining.
Signed-off-by: Guillaume Pagès
Signed-off-by: Junio C Hamano
Signed-off-by: Matthieu Moy
---
Added --short where appropriate.
t/t7512-status-help.sh | 8
From: Guillaume Pagès
Signed-off-by: Guillaume Pagès
Signed-off-by: Junio C Hamano
Signed-off-by: Matthieu Moy
---
No change since v4.
t/t7512-status-help.sh | 28 ++--
wt-status.c| 5 -
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a
From: Guillaume Pagès
git status gives more information during rebase -i, about the list of
command that are done during the rebase. It displays the two last
commands executed and the two next lines to be executed. It also gives
hints to find the whole files in .git directory.
Signed-off-by: Gui
From: Guillaume Pagès
Signed-off-by: Guillaume Pagès
Signed-off-by: Junio C Hamano
Signed-off-by: Matthieu Moy
---
No change since v4.
wt-status.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index eaed4fe..8
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> This series makes "git status" provide an output like
>>
>> interactive rebase in progress; onto $ONTO
>> Last commands done (2 commands done):
>> pick $COMMIT2 two_commit
>> exec exit 15
>> Next commands to do (2 remaining comma
On Tue, Jun 30, 2015 at 7:51 AM, Stefan Beller wrote:
> I needed to read this patch a few times as this patch introduces `sign_commit`
> twice. This is mostly a review problem I'd guess as in the code it
> just affects this
> method and you'd see all the code of the method easily compared to hunks
> I'd vote for keeping it simple and not having the copyright notice. Most
> t/*.sh do not have one. The Git history + mailing-list archives are much
> better than in-code comments to keep track of who wrote what.
> Remi: any objection on removing it?
Sorry for not having resent the patches mysel
On Tue, Jun 30, 2015 at 5:39 AM, Junio C Hamano wrote:
> Not using any increment inside isspace(), like you showed, is the
> most readable.
Yup, I agree.
Thanks,
Paul
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majo
82 matches
Mail list logo
