First, the commit message could probably be reordered to start with the
main point (reusing of packfiles at object granularity instead of
allowing reuse of only one contiguous region). To specific points:
> The dynamic array of `struct reused_chunk` is useful
> because we need to know not just the
> From: Jeff King
>
> In a following commit we will need to allocate a variable
> number of bitmap words, instead of always 32, so let's add
> bitmap_word_alloc() for this purpose.
>
> We will also always access at least one word for each bitmap,
> so we want to make sure that at least one is al
> From: Heba Waly
>
> This commit is copying and summarizing the documentation from
> documentation/technical/api-config.txt to comments in config.h
Thanks for this commit!
As for your commit message, as far as I know, the idea is to move the
documentation, not to copy it. Also, write this in i
that this patch is a net improvement.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 336 ---
1 file changed, 190 insertions(+), 146 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 31607a77fc..072592a35d 100644
--- a/bu
possible moment. This allowed the members of struct base_data to be
populated in any order, superficially useful when we have the object
contents before the struct object_entry. But this makes reasoning about
the state of struct base_data more complicated, hence this patch.
Signed-off-by: Jonathan Tan
A subsequent commit will make the quantum of work smaller, necessitating
more locking. This commit allows resolve_delta() to be called outside
the lock.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin/index
find_{ref,ofs}_delta_{,children} take an enum object_type parameter, but
the object type is already present in the name of the function. Remove
that parameter from these functions.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 26 --
1 file changed, 12
;
pointer is redundant even now, remove it so that the aforementioned
subsequent patch will be clearer. In the meantime, reclaim memory in the
reverse order of the "base" pointers.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 41 ++---
1 f
Clarify that core.deltaBaseCacheLimit is per-thread, as can be seen from
the fact that cache usage (base_cache_used in struct thread_local in
builtin/index-pack.c) is tracked individually for each thread and
compared against delta_base_cache_limit.
Signed-off-by: Jonathan Tan
---
Documentation
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 60a5591039..df6b3b8cf6 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1210,15 +1210,7 @@ static
ve
> puzzled all that out, it would be nice to make the argument in the
> commit message.
I've added an explanation in the commit message.
Jonathan Tan (7):
Documentation: deltaBaseCacheLimit is per-thread
index-pack: unify threaded and unthreaded code
index-pack: remove redundant parameter
ommit data between the changelog and the diffstat.
Oh! I had missed this on first reading because it was in an
attachment.
I have mixed feelings. Can you say a bit more about the advantages
and disadvantages relative to sending a git bundle? What happens if a
mail client or a box
> There was some discussion recently about converting these related
> #defines to enums [0]. We might consider doing that here.
>
> If you read through that entire thread, you'd see that there were some
> disagreements about whether using enums for sets of bits is a good idea
> ([1] and [2]), b
TTP protocol v2 (fetch_refs_via_pack() in transport.c sets
lock_pack) and with HTTP protocol v0/v1 (fetch_git() in remote-curl.c
passes "--lock-pack" to "fetch-pack").
Signed-off-by: Jonathan Tan
---
Changes from v1:
- commit message explains scope of change ("it knows the name of t
Thanks for your comments. Rearranging them:
> This makes me wonder why we don't also change index-pack to write a
> similar message to the .promisor. I guess there's potentially too much
> information to shove all the refs on the command-line?
index-pack already is capable of writing messages to
> > Well, I agree that it could be better, but with the C language as we
> > have it now, I still slightly prefer an enum to a list of #define. Both
> > ways, we still have to manually enter values for each flag, but with
> > enum, we get better debugger display (at least in gdb) and in the
> > fun
> Jonathan Tan writes:
>
> >> > Also, I have a slight preference for putting "= 02" on the BLAME_COPY
> >> > line but that is not necessary.
> >>
> >> That is absolutely necessary; it is not like "we do not care what
> >
> As a general rule (and why I'm raising this issue in reply to Jonathan's
> patch), I think most or all sites that want OBJECT_INFO_QUICK will want
> SKIP_FETCH_OBJECT as well, and vice versa. The reasoning is generally
> the same:
>
> - it's OK to racily have a false negative (we'll still be c
> > This makes sense - offsets may be different when we omit objects from
> > the packfile. I think this can be computed by calculating the number of
> > zero bits between the current object's index and the nth object prior
> > (where n is the offset) in the bitmap resulting from
> > reuse_partial_
> > Any reason why the names are renamed to omit "PICKAXE_"? In particular,
> > these names are still global, so it is good to retain the extra context.
> >
> > (This doesn't mean that you are wrong to remove them - I just gave my
> > opinion, and a reason for my opinion. If you had a reason to re
> Jonathan Tan writes:
>
> >> - if ((opt & PICKAXE_BLAME_COPY_HARDEST)
> >> - || ((opt & PICKAXE_BLAME_COPY_HARDER)
> >> + if ((opt & BLAME_COPY_HARDEST)
> >> + || ((opt & BLAME_COPY_HARDER)
> >
> > Any reason
I'm going to start with pack-bitmap.h, then builtin/pack-objects.c.
> int reuse_partial_packfile_from_bitmap(struct bitmap_index *,
> struct packed_git **packfile,
> -uint32_t *entries, off_t *up_to);
> +
> As we now allocate 2 more words than necessary for each
> bitmap to serve as marks telling us that we can stop
> iterating over the words, we don't need to rely on
> bitmap_git->reuse_objects to stop iterating over the words.
As Peff states [1], this justification is probably incorrect as well.
> From: Jeff King
>
> In a following patch we will allocate a variable number
> of words in some bitmaps. When iterating over the words we
> will need a mark to tell us when to stop iterating. Let's
> always allocate 2 more words, that will always contain 0,
> as that mark.
[snip]
> if (b
contributors to
> setup lightweight clones and pull in history on an as-needed
> basis w/o hacks like shallow cloning.
Does "git clone --filter=blob:none" do what you're looking for?
Thanks,
Jonathan
can learn from each other?
Thanks,
Jonathan
[1]
https://lore.kernel.org/workflows/20191010144150.hqiosvwolm3lmzp5@chatter.i7.local/
2 files changed, 130 insertions(+), 13 deletions(-)
Interesting! I'm cc-ing the Git mailing list in case "git am" might
wnat to learn the same support.
Thanks,
Jonathan
(patch left unsnipped for reference)
> diff --git a/patchwork/parser.py b/patchwork/parser.py
> in
> On 10/9/2019 7:44 PM, Jonathan Tan wrote:
> > Instead, recompute ancestry if we ever need to reclaim memory.
>
> I find this message lacking in important details:
>
> 1. Where do we recompute ancestry?
> 2. What are the performance implications of this change?
> 3. W
> Hello Jonathan!
> My name is Wambui and I'm one of the applicants in the current round of
> Outreachy applications. I wanted to write an initial email to introduce
> myself since I'm interested in working on your mentored projects!
>
> I have been going through th
> Convert pickaxe_blame preprocessor constants in blame.h to an enum.
> Also replace previous instances of the constants with the new enum values.
First of all, thanks for your initiative in finding a microproject and
making a patch for it!
About your commit message title, I know that 50 characte
Whenever we make a struct base_data, immediately calculate its delta
children. This eliminates confusion as to when the
{ref,ofs}_{first,last} fields are initialized.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 125 +--
1 file changed, 61
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 1a2600d4b3..99f6e2957f 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -614,7
Instead, recompute ancestry if we ever need to reclaim memory.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 99f6e2957f
A subsequent commit will make the quantum of work smaller, necessitating
more locking. This commit allows resolve_delta() to be called outside
the lock.
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin/index
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index a23454da6e..1a2600d4b3 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1210,15 +1210,7 @@ static
ens during repack.
[1]
https://public-inbox.org/git/20190926003300.195781-1-jonathanta...@google.com/
[2] https://public-inbox.org/git/20190704100530.smn4rpiekwtfy...@glandium.org/
Jonathan Tan (6):
index-pack: unify threaded and unthreaded code
index-pack: remove redundant parameter
index-
Signed-off-by: Jonathan Tan
---
builtin/index-pack.c | 267 ---
1 file changed, 127 insertions(+), 140 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 3908cd3115..f6318037ca 100644
--- a/builtin/index-pack.c
+++ b/builtin/index
ral case, there's been some discussion of fetching
and pushing symrefs on-list before. [1] discusses one possible UI.
[...]
> The third solution has several problems. The first one is the created
> default local branch. So delete it.
Hm, I don't follow. Does "git checkout --or
ould see once such a series
> lands).
Acked-by: Jonathan Nieder
Thanks for your thoughtful work.
o not help at all in the typical case where the client is
up-to-date with the upstream of the branch being pushed.
Ensure that these lazy fetches do not occur.
Signed-off-by: Jonathan Tan
---
> For example, would this change mean that the resulting pack may
> include stuff that are re
> Changes since V1:
> * Use the repository struct argument in transport_push(), rather than
> the global the_repository.
Thanks, the patches now look good to me. I verified that the repository
argument to the trace functions just cause a different repo ID to be
printed, which is what we want (e.
> We'd like to collect better statistics about where the time is spent in
> fetches and pushes so that we can hopefully identify some areas for
> future optimization. So let's add some trace2 regions around some of the
> fetch/push phases so we can break down their timing.
Thanks.
Patch 1 looks g
ch. Ensure that this lazy fetch does not occur.
Signed-off-by: Jonathan Tan
---
send-pack.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/send-pack.c b/send-pack.c
index 6dc16c3211..34c77cbb1a 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -40,7 +40,8 @@ int option_parse_p
When running "git fetch" in a partial clone with no blobs, for example,
by:
git clone --filter=blob:none --no-checkout \
https://kernel.googlesource.com/pub/scm/git/git
git -C git fetch
"git fetch" will fail to load the config blob object, printing "unable
to load config blob object".
Th
> For those who want to know, this question was motivated by a big delta
> tree occurring in [1].
Forgot to mention: this is not an issue of the server not repacking with
a chain length limit. The tree in question is indeed not tall, but it is
very wide.
Does anyone have ideas or plans for this? I know that (at least) "grep"
and "index-pack" have their own implementations, and it would be great
to just have one that all code can use.
For those who want to know, this question was motivated by a big delta
tree occurring in [1]. index-pack does paral
s stated better what I would have
said, so to this patch:
Acked-by: Jonathan Tan
> On Mon, Sep 23, 2019 at 01:38:54PM -0700, Jonathan Tan wrote:
>
> > I didn't have any concrete ideas so I didn't include those, but some
> > unrefined ideas:
>
> One risk to a mentoring project like this is that the intern does a good
> job of steps 1-5, a
> I approved this. I did leave some comments elsewhere in the thread, but
> I think we can continue to iterate on the idea.
Thanks.
> > There was a "How can applicants make a contribution to your project?"
> > question and a few questions about communication channels. I answered
> > them as best
> I think this is an OK level of detail. I'm not sure quite sure about the
> goal of the project, though. In particular:
>
> - I'm not clear what we'd hope to gain. I.e., what richer information
> would we want to pass back and forth between index-pack and the
> other processes? It might
> No need for user-facing benefits. Refactoring or improving the code in
> other useful ways are very good subjects (as I already said in my
> reply to Emily and Dscho).
Thanks!
> I think this is really great, both the idea and the description! No
> need for more details.
Thanks! I've just submi
> Jonathan Tan writes:
>
> >> OK. We notice that we need to newly create foo/bar but we
> >> incorrectly find that there is "foo/bar" already because of the
> >> careless use of bare lstat(2) makes "bar" visible as if it were also
> >&
> OK. We notice that we need to newly create foo/bar but we
> incorrectly find that there is "foo/bar" already because of the
> careless use of bare lstat(2) makes "bar" visible as if it were also
> "foo/bar". I wonder if the current code would be confused the same
> way if the side branch added
> Prospective mentors need to sign up on that site, and should propose a
> project they'd be willing to mentor.
[snip]
> I'm happy to discuss possible projects if anybody has an idea but isn't
> sure how to develop it into a proposal.
I'm new to Outreachy and programs like this, so does anyone h
> * jt/cache-tree-avoid-lazy-fetch-during-merge (2019-09-09) 1 commit
> - cache-tree: do not lazy-fetch tentative tree
>
> The cache-tree code has been taught to be less aggressive in
> attempting to see if a tree object it computed already exists in
> the repository.
>
> Waiting for a respo
Helped-by: Elijah Newren
Signed-off-by: Jonathan Tan
---
Changes from v1:
- Used has_symlink_leading_path(). This drastically shortens the diff.
- Updated commit message following suggestions from Junio, Szeder Gábor,
and Elijah Newren.
- Updated test to add prereq and verification that the workin
> Yeah, I recall having to add has_symlink_leading_path() long time
> ago in different codepaths (including "apply"). It is not surprising
> to see a similar glitch remaining in merge-recursive (it's a tricky
> issue, and it's a tricky code).
Thanks for the pointer to has_symlink_leading_path() -
> Jonathan Tan writes:
>
> > When the working tree has:
> > - foo (symlink)
> > - foo/bar (directory)
>
> Whoa, wait. I assume, since this is about merge, the assumption is
> that the working tree is clean with respect to the index, so 'foo'
>
one", and will handle it as "Add/delete" or
"Modify/delete" appropriately (including reinstatement of the previously
unlinked symlink with a new unique filename if necessary, again, just
like if "foo" were a regular file instead).
Helped-by: Elijah Newren
S
Jonathan Tan wrote:
> This was raised by a coworker at $DAYJOB. I run the following script:
[reproduction recipe from (*) snipped]
> The cherry-pick must be manually resolved, when I would expect it to
> happen without needing user intervention.
>
> You can see that at the poin
ng
in parallel already, so this isn't a huge win for the time to complete
a normal test run. It helps more with expensive runs like --valgrind.
Thanks,
Jonathan
This was raised by a coworker at $DAYJOB. I run the following script:
$GIT init test && cd test
ln -s . foo
mkdir bar && touch bar/file
$GIT add foo bar/file
$GIT commit -m "foo symlink"
$GIT checkout -b branch1
$GIT commit --allow-empty -m "empty commit"
$GIT checkout master
(+cc: Thomas Gummerer)
Hi Johannes,
Johannes Schindelin wrote:
> On Fri, 13 Jul 2018, Jonathan Nieder wrote:
>> Some of us have been informally doing a "git standup" on #git-devel on
>> irc.freenode.net on IRC every two weeks at 17:00-17:30 UTC. It's a
>>
> Do we have interested mentors for the next round of Outreachy?
>
> The deadline for Git to apply to the program is September 5th. The
> deadline for mentors to have submitted project descriptions is September
> 24th. Intern applications would start on October 1st.
>
> If there are mentors who w
> Sidenote, just curious: did you originally intend to add this test
> before the test script sources 'lib-httpd.sh', or you were about to
> append it at the end as usual, but then noticed the warning comment
> telling you not to do so?
Honestly, I don't remember. I do try to put tests near simila
> Junio C Hamano writes:
>
> > Isn't that what is going on? I thought I dug up the original that
> > introduced the has_object_file() call to this codepath to make sure
> > we understand why we make the check (and I expected the person who
> > is proposing this change to do the same and record t
is both unnecessary (because we have the tree in the struct
strbuf) and likely to fail (because the remote probably doesn't have
this tree).
Do not lazy fetch in this situation.
Signed-off-by: Jonathan Tan
---
As requested in What's Cooking [1], here's a patch with an updated
> I'm not really opposed to what you're doing here, but I did recently
> think of another possible use for .promisor files. So it seems like a
> good time to bring it up, since presumably we'd have to choose one or
> the other.
Thanks for bringing it up - yes, we should discuss this.
> I noticed
> On 9/3/2019 3:42 PM, Jonathan Tan wrote:
> > When cherry-picking (for example), new trees may be constructed. During
> > this process, Git checks whether these trees exist. However, in a
> > partial clone, this causes a lazy fetch to occur, which is both
> > unnecessa
) and likely to fail (because the remote
probably doesn't have this tree).
Do not lazy fetch in this situation.
Signed-off-by: Jonathan Tan
---
Another partial clone bug.
This raises the issue that failed fetches are currently fatal - if they
weren't fatal, this cherry-pick would h
> Jonathan Tan writes:
>
> > As written in the NEEDSWORK comment, repack does not preserve the
> > contents of .promisor files, but I thought I'd send this out anyway as
> > this change is already useful for users who don't run repack much.
>
> What
hashes
against what the promisor remote reports now.
Signed-off-by: Jonathan Tan
---
As written in the NEEDSWORK comment, repack does not preserve the
contents of .promisor files, but I thought I'd send this out anyway as
this change is already useful for users who don't run r
> This probably is totally off-tangent, but do any of these "let's
> advertise fewer" changes at the protocol level have to take into
> account the use of --prune option on the client side?
I don't think so. According to what I understand from the documentation,
the prune option prunes based on th
> I wondered what would happen when it does not succeed. It looks like the
> whole diff process just dies.
>
> The batch fetch is purely an optimization, because we'd eventually fetch
> the individual objects on demand. If the batch one fails, should we
> continue with the operation? That leaves a
The only transport that does not allow fetch() to be called before
get_refs_list() is the bundle transport. Clean up the code by teaching
the bundle transport the ability to do this, and removing support for
transports that don't support this order of invocation.
Signed-off-by: Jonatha
re of the value of the test in patch 2, but that test does
fail if I don't update fetch_refs_from_bundle() to first call
get_refs_from_bundle() if it hasn't already been called.
Jonathan Tan (2):
transport-helper: skip ls-refs if unnecessary
transport: teach all vtables to allow fetch
if needed). If not, the remote helper interface will invoke
get_refs_list() if it hasn't been invoked yet, preserving existing
behavior.
Signed-off-by: Jonathan Tan
---
t/t5702-protocol-v2.sh | 13 +
transport-helper.c | 39 +--
2 file
> Jonathan Tan writes:
>
> > In 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08),
> > diff was taught to batch the fetching of missing objects when operating
> > on a partial clone, but was not taught to refrain from fetching
> > GITLINK
In 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08),
diff was taught to batch the fetching of missing objects when operating
on a partial clone, but was not taught to refrain from fetching
GITLINKs. Teach diff to check if an object is a GITLINK before including
it in the set to be f
XP_QPAT in subevalvar, 2013-08-23).
Signed-off-by: Jonathan Nieder
---
t/test-lib-functions.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 7860491660..de58e8b502 100644
--- a/t/test-lib-functions.sh
+++ b/t/te
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Lukas Gross wrote:
>>> I had intended to stage commits but forgot to do so. Git responded
>>> with a normal commit creation message, so I pushed to the remote to
>>> begin a CI build. When the build failed
nally. So I think there's room for a simple improvement here.
Care to take a stab at it? builtin/commit.c would be the place to
start.
Thanks and sorry for the roller-coaster,
Jonathan
it is a mistake, allowing
a warning or even an error.
Of these three, the first seems most compelling to me. Others may
have other ideas.
Thoughts?
Thanks,
Jonathan
hat were you trying to do when
you performed this operation? What happened instead?
Thanks,
Jonathan
something like the
following:
- add entries to config.mak.uname to set the compiler e.g. to 6c
when appropriate
- make appropriate compatibility fixes in git-compat-util.h
- add any necessary helpers to the compat/ directory
- use gmake to build
Would that work?
Thanks,
Jonathan
SZEDER Gábor wrote:
> On Fri, Aug 02, 2019 at 09:59:13AM -0700, Jonathan Nieder wrote:
>> In the short term, we can run tests internally to check that Git keeps
>> following the schema. Let's not block patches 1 and 2 by this ---
>
> To my understanding patch 2 is o
SZEDER Gábor wrote:
> On Thu, Aug 01, 2019 at 06:52:47PM -0700, Jonathan Nieder wrote:
>> Gábor, if we introduce such a parameter, do you think it would make
>> sense for us to set up a worker that passes it?
>
> That would be even worse than the current approach of the third
Hi,
Johannes Schindelin wrote:
> On Thu, 1 Aug 2019, Jonathan Nieder wrote:
>> What do you think of making the validation disabled by default and
>> using a parameter (see "Running tests with special setups" in
>> t/README) to turn it on? That way, it should be ok
sha1 and then try the full
set of patterns from ref_rev_parse_rules. What do you think? Would
you be interested in taking a stab at it?
Thanks,
Jonathan
and hope that helps,
Jonathan
). We can simplify further by removing the "-1" case --- we do
not need to distinguish between "on" and "unspecified" any more.
We'll also want to update the docs. And as Todd suggests, we should
cover how to disable mailmap in tests.
Signed-off-by: Jonathan Nied
ot; means that I can rely on the whole community to
> identify important code paths, both now and in the future.
I agree.
> As always, I am open to other approaches to make sure the schema stays
> up-to-date.
It sounds like the codegen approach would be a nice way to do that,
but that doesn't need to block this step in the right direction.
Thanks for your thoughtfulness,
Jonathan
Jeff King wrote:
> This seems OK to me, though I kind of wonder if anybody really wants
> "auto".
Sure. It's just the usual way of handling the lack of support for an
"unset" directive in git's config syntax (for example, if a script
author wants to test the default behavior).
Thanks,
Jonathan
w log.mailmap setting "auto" that can be used to
explicitly request the new automatic behavior (so that e.g. if
log.mailmap is set to "true" system-side, I can set it to "auto" in my
per-user configuration).
Reported-by: Johannes Schindelin
Signed-of
Thanks - I think this is a useful guide to what can be a complicated
topic. It looks good overall; I just have some minor comments below.
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 76f2ecfc1b..91e5da67c4 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefi
> When cloning a repo with a --filter and with --recurse-submodules
> enabled, the partial clone filter only applies to the top-level repo.
> This can lead to unexpected bandwidth and disk usage for projects which
> include large submodules.
>
> Fix this by plumbing the --filter argument from git-
s, and see test_lazy_prereq in case
you'd like the test to use an external tool like tar2sqfs that not all
users may have.)
Thanks,
Jonathan
(patch left unsnipped for reference)
> diff --git a/archive-tar.c b/archive-tar.c
> index 3e53aac1e6..f9a157bfd1 100644
> --- a/archive-tar.c
APH=1
> export GIT_TEST_MULTI_PACK_INDEX=1
> make test
> -fi
> + ;;
> +linux-gcc-4.8)
> + # Don't run the tests; we only care about whether Git can be
> + # built with GCC 4.8, as it errors out on some undesired (C99)
> + # constructs that newer compilers seem to quietly accept.
> + ;;
> +*)
> + make test
> + ;;
> +esac
Does what it says on the tin.
Reviewed-by: Jonathan Nieder
at it, extend the existing variable declaration rule a bit to
> read better with the newly spelled out rule for the for loop.
>
> Signed-off-by: Junio C Hamano
> ---
> Documentation/CodingGuidelines | 25 ++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
Reviewed-by: Jonathan Nieder
Thanks.
ning of the block, before
> + the first statement (i.e. -Wdeclaration-after-statement).
> +
> + - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
> + is still not allowed in this codebase.
Nice.
Reviewed-by: Jonathan Nieder
Thanks.
1 - 100 of 4556 matches
Mail list logo
