On Tue, Feb 13, 2018 at 5:24 PM, Duy Nguyen wrote:
> I am worried that always doing the right thing may carry performance
> penalty (this is based purely on reading verify_path() code, no actual
> benchmarking). For safety, you can always set safe_path to zero. But
> if you do a lot of invalidatio
Signed-off-by: Robert P. J. Day
---
diff --git a/t/t7409-submodule-detached-work-tree.sh
b/t/t7409-submodule-detached-work-tree.sh
index c20717181..fc018e363 100755
--- a/t/t7409-submodule-detached-work-tree.sh
+++ b/t/t7409-submodule-detached-work-tree.sh
@@ -6,7 +6,7 @@
test_description='Te
On Wed, Feb 14, 2018 at 10:16 AM, Jeff King wrote:
> Hmm. That is not too bad, but somehow it feels funny to me to be
> polluting each test script with these annotations. And to be driving it
> from inside the test scripts.
>
> It seems like:
>
> make SANITIZE=leak test GIT_SKIP_TESTS="$(cat kno
On Wed, Feb 14, 2018 at 8:51 AM, Junio C Hamano wrote:
> * nd/parseopt-completion (2018-02-09) 42 commits
> - git-completion.bash: add GIT_COMPLETION_OPTIONS=all config
> - completion: use __gitcomp_builtin in _git_worktree
> - completion: use __gitcomp_builtin in _git_tag
> - completion: use
The title says it all.
If I run `git init --template=~/path/to/my/template` I get the following
message:
warning: templates not found ~/path/to/my/template
But, if I run:
$ env GIT_TEMPLATE_DIR=~/path/to/my/template git init
I don't get a warning and the template is used just f
Hi,
I've noticed that recent versions of git consume a lot of memory during
"git fsck", to the point where I've regularly had git fall victim to
Linux's OOM killer.
For example, if I clone torvalds/linux.git, and then run "git fsck
--connectivity-only" in the newly cloned repository, git will con
When you specify "--path ~/foo", the shell will automatically expand
~/foo to $HOME/foo before it's passed to git. The expansion is not done
on "--path=~/foo". An experienced user sees the difference but it could
still be confusing for others (especially when tab-completion still
works on --path=~/
OPTION_FILENAME has some magic behind the scene, like prefixing which is
useless for init-db. The $HOME expansion though does come handy and
makes --template more consistent with the rest (both env and config var
get $HOME expansion).
Noticed-by: Doron Behar
Signed-off-by: Nguyễn Thái Ngọc Duy
-
Among the "in progress" commands, only git-am and git-merge do not
support --quit. Support --quit in git-am too.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-am.txt | 6 +-
builtin/am.c | 12 ++--
contrib/completion/git-completion
Sent from my iPad
> I've noticed that recent versions of git consume a lot of memory during
> "git fsck", to the point where I've regularly had git fall victim to
> Linux's OOM killer.
>
> For example, if I clone torvalds/linux.git, and then run "git fsck
> --connectivity-only" in the newly cloned repository, git w
On Fri, Feb 9, 2018 at 12:01 PM, Nguyễn Thái Ngọc Duy wrote:
> The new completable options are:
>
> --directory
> --exclude
> --gpg-sign
> --include
> --keep-cr
> --keep-non-patch
> --message-id
> --no-keep-cr
> --patch-format
> --quiet
> --reject
> --resolvemsg=
>
> In-progress options like --con
> On 10 Feb 2018, at 10:48, Torsten Bögershausen wrote:
>
> On Fri, Feb 09, 2018 at 02:28:28PM +0100, lars.schnei...@autodesk.com wrote:
>> From: Lars Schneider
>>
>> ...
>>
>> +Please note that using the `working-tree-encoding` attribute may have a
>> +number of pitfalls:
>> +
>> +- Git clie
On Wed, Feb 14, 2018 at 01:48:28PM +0100, SZEDER Gábor wrote:
> > If I revert that commit (on top of current master) the memory
> > consumption goes down to 2GB again. The change looks relatively harmless
> > to me, so does anyone know what's going on here?
>
> I could reproduce the increased mem
On Wed, Feb 14, 2018 at 05:51:48PM +0700, Nguyễn Thái Ngọc Duy wrote:
> When you specify "--path ~/foo", the shell will automatically expand
> ~/foo to $HOME/foo before it's passed to git. The expansion is not done
> on "--path=~/foo". An experienced user sees the difference but it could
> still b
On Wed, Feb 14, 2018 at 05:51:49PM +0700, Nguyễn Thái Ngọc Duy wrote:
> OPTION_FILENAME has some magic behind the scene, like prefixing which is
> useless for init-db. The $HOME expansion though does come handy and
> makes --template more consistent with the rest (both env and config var
> get $HO
On 2/13/2018 8:51 PM, Junio C Hamano wrote:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding
On Fri, Feb 9, 2018 at 12:02 PM, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index c7b8b37f19..60127daebf 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@
Resending as Plain Text.
After upgrading to 2.16.1.windows.4, I have been unable to launch “C:\Program
Files\Git\git-bash.exe” from installed shortcut or from command line (cmd). In
both cases, the bash console flashes and closes immediately.
I am able to invoke “C:\Program Files\Git\bin\bash.
This appears to be covered by
https://github.com/git-for-windows/git/issues/1473. In particular, avih's
comment about git-bash working without a .minttyrc file applies to me.
Apologize for the noise; should have fully reading bug reporting instructions.
-Original Message-
From: greenw
On Fri, Jan 5, 2018 at 7:36 PM, Matthieu Moy wrote:
> create mode 100644 perl/Git/FromCPAN/Mail/Address.pm
> create mode 100755 perl/Git/Mail/Address.pm
I didn't notice this in my initial review, but just now when it's
landed in master and it's shiny-green in my terminal, this file should
be 6
On Fri, Feb 9, 2018 at 12:02 PM, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index c7b8b37f19..60127daebf 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -
Thanks for working on this. I anticipated that the completion script
lack some options, but wow, I didn't expect that there are so many
missing.
On Fri, Feb 9, 2018 at 12:01 PM, Nguyễn Thái Ngọc Duy wrote:
> This is a __gitcomp wrapper that will execute
>
> git ... --git-completion-helper
>
Remove the reference to setting core.fsmonitor to `true` (or `false`) as those
are not valid settings.
Signed-off-by: Ben Peart
---
Notes:
Base Ref: master
Web-Diff: https://github.com/benpeart/git/commit/4b7ec2c11e
Checkout: git fetch https://github.com/benpeart/git fsmonitor_docs-v
Hi my name is Benjamin Bales.
I am the founder and creator of CodeAI,
the first non-human contributor to your software project. CodeAI finds
and fixes security defects for you. It fixed 18. It wants to merge 5
commits - 1 Allocator sizeof() operand mismatch, 2 Null Pointer
Dereference issues and 2
On Wed, Feb 14, 2018 at 10:50:12AM -0500, Code AI wrote:
> Hi my name is Benjamin Bales.
>
> I am the founder and creator of CodeAI,
> the first non-human contributor to your software project. CodeAI finds
> and fixes security defects for you. It fixed 18. It wants to merge 5
> commits - 1 Alloca
Duy Nguyen writes:
>> Will see another reroll.
>> cf.
>
> Well, the next reroll would just drop 42/42, which may be easier for
> you to do it yourself. I don't think I can work out what all
> git-completion.bash needs to rewrite 42/42 in a couple days.
OK, I agree that I should have read the
Derrick Stolee writes:
> There have been a few "What's cooking" emails since I submitted v1 of
> "Serialized Git Commit Graph" and it has not appeared with a tracking
> branch. Is this a mistake, or is it something about the state of the
> review?
The latter.
Once I pick up a topic and have it
Jeff King writes:
> Here's the patch to make "show -B --stat" work. I'll give some more
> thought to whether this is a good idea and prepare a series.
>
> One downside is that in the common case it causes us to look up each
> object twice (once to get its size, and then again to load the content)
Duy Nguyen writes:
> On Wed, Feb 14, 2018 at 10:16 AM, Jeff King wrote:
>> Hmm. That is not too bad, but somehow it feels funny to me to be
>> polluting each test script with these annotations. And to be driving it
>> from inside the test scripts.
>>
>> It seems like:
>>
>> make SANITIZE=leak
On 2/14/2018 12:23 PM, Junio C Hamano wrote:
Derrick Stolee writes:
There have been a few "What's cooking" emails since I submitted v1 of
"Serialized Git Commit Graph" and it has not appeared with a tracking
branch. Is this a mistake, or is it something about the state of the
review?
The la
On Tue, Feb 13, 2018 at 11:23 PM, Eric Sunshine wrote:
> On Mon, Feb 12, 2018 at 10:55 PM, Eric Sunshine
> wrote:
>> On Mon, Feb 12, 2018 at 8:41 PM, Stefan Beller wrote:
>>> + * Output the formatted string in the specified color (and then reset to
>>> normal
>>> + * color so subsequent output
This series started with me fixing the sizeof() mismatch discussed in
https://public-inbox.org/git/20180214164628.ga...@sigill.intra.peff.net/
but I found a number of minor irritations. Most of them are cosmetic in
practice, but I think it's important for test-helper code like this to
model bes
These two array allocations have several minor flaws:
- they use bare malloc, rather than our error-checking
xmalloc
- they do a bare multiplication to determine the total
size (which in theory can overflow, though in this case
the sizes are all constants)
- they use sizeof(typ
When we allocate the test_entry flex-struct, we have to add
up all of the elements that go into the flex array. If these
were to overflow a size_t, this would allocate a too-small
buffer, which we would then overflow in our memcpy steps.
Since this is just a test-helper, it probably doesn't matter
Using fgets() with a fixed-size buffer can lead to lines
being accidentally split across two calls if they are larger
than the buffer size.
As this is just a test helper, this is unlikely to be a
problem in practice. But since people may look at test
helpers as reference code, it's a good idea for
In general, using a bare snprintf can truncate the resulting
buffer, leading to confusing results. In this case we know
that our buffer is sized large enough to accommodate our
loop, so there's no bug. However, we should use xsnprintf()
to document (and check) that assumption, and to model good
pra
This function takes two ptr/len pairs, which implies that
they can be arbitrary buffers. But internally, it assumes
that each "ptr" is NUL-terminated at "len" (because we
memcpy an extra byte to pick up the NUL terminator).
In practice this works because each caller only ever passes
strlen(ptr) as
On 02/14, Duy Nguyen wrote:
> On Tue, Feb 13, 2018 at 8:22 AM, Stefan Beller wrote:
> > Signed-off-by: Stefan Beller
> > ---
> > object-store.h | 3 +--
> > sha1_file.c| 21 +++--
> > 2 files changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/object-store.h b/ob
The hashmap API always use an unsigned value for storing
and comparing hashes. Whereas this test code uses "int".
This works out in practice since one can typically
round-trip between "int" and "unsigned int". But since this
is essentially reference code for the hashmap API, we should
model using t
On 2/13/2018 7:12 PM, Jonathan Tan wrote:
On Thu, 8 Feb 2018 15:37:35 -0500
Derrick Stolee wrote:
| Command | Before | After | Rel % |
|--|||---|
| log --oneline --topo-order -1000 | 5.9s | 0.7s | -88% |
| bran
On 02/13, Junio C Hamano wrote:
>
> * bw/c-plus-plus (2018-01-30) 37 commits
> - replace: rename 'new' variables
> - trailer: rename 'template' variables
> - tempfile: rename 'template' variables
> - wrapper: rename 'template' variables
> - environment: rename 'namespace' variables
> - diff:
Linus Torvalds writes:
> On Tue, Feb 13, 2018 at 9:18 AM, Junio C Hamano wrote:
>>
>> That makes me wonder if another heuristic I floated earlier is more
>> appropriate. When merging a tag object T, if refs/tags/T exists and
>> it is that tag object, then an updated "merge" would default to "--
There has been a lot of interesting discussion on this topic. Some of
that involves some decently significant changes from v3, so I wanted to
summarize my understanding of the feedback and seek out more feedback
from reviewers before rolling v4.
If we have consensus on these topics, then I'll
On Wed, Feb 14, 2018 at 10:11 AM, Brandon Williams wrote:
> On 02/13, Junio C Hamano wrote:
>>
>> * bw/c-plus-plus (2018-01-30) 37 commits
>> - replace: rename 'new' variables
>> - trailer: rename 'template' variables
>> - tempfile: rename 'template' variables
>> - wrapper: rename 'template' v
Jeff King writes:
>> Support $HOME expansion for all filename options. There are about seven
>> of them.
>
> I think this probably makes sense.
>
>> parse-options.c | 9 ++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> Should this be mentioned in the comment documenting OPT_FILEN
Ben Peart writes:
> Remove the reference to setting core.fsmonitor to `true` (or `false`) as those
> are not valid settings.
>
> Signed-off-by: Ben Peart
> ---
Thanks. It is a bit embarrassing that nobody caught it for this
long. Will apply.
>
> Notes:
> Base Ref: master
> Web-Diff:
On Wed, Feb 14, 2018 at 10:15 AM, Derrick Stolee wrote:
> There has been a lot of interesting discussion on this topic. Some of that
> involves some decently significant changes from v3, so I wanted to summarize
> my understanding of the feedback and seek out more feedback from reviewers
> before
Hi All,
I am facing this issue: I am ADDing some file with several pathspec, and one of
these fails. The results is that no file is added at all.
Simple test case:
$ git init .
$ touch 123.txt
$ git add "*.txt" "*.doc"
fatal: pathspec '*.doc' did not match any files
$ git status
[...]
Untracked
On Wed, Feb 14, 2018 at 10:03 AM, Jeff King wrote:
> This series started with me fixing the sizeof() mismatch discussed in
>
> https://public-inbox.org/git/20180214164628.ga...@sigill.intra.peff.net/
>
> but I found a number of minor irritations. Most of them are cosmetic in
> practice, but I th
Jeff,
Thanks for the feedback! Most of our users find CodeAI's fixes
useful, even if they are not exactly correct. However, we are
constantly working on improving the quality of CodeAI's fixes. The
more people who use it, the more we can improve it. We would love for
you to try the system dire
On Wed, Feb 14, 2018 at 10:41:35AM -0800, Stefan Beller wrote:
> I have lost track of the hashmap improvements lately, but with
> such a good test helper, we could reduce the amount of
> commented code in hashmap.h and just link to the test helper?
> (as an extra step after this series, I thought
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 143
1 file changed, 143 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index d045f0e31e..b22a9052b3 1007
In anticipation of more involved cleanup to come, make a helper function
for doing the cleanup at the end of handle_renames. Rename the already
existing cleanup_rename[s]() to final_cleanup_rename[s](), name the new
helper initial_cleanup_rename(), and leave the big comment in the code
about why w
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
merge-recursive.c | 25 ++---
t/t6043-merge-rename-directories.sh | 8
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 4532b982a
Before trying to apply directory renames to paths within the given
directories, we want to make sure that there aren't conflicts at the
directory level. There will be additional checks at the individual
file level too, which will be added later.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah N
This patchset introduces directory rename detection to merge-recursive. See
https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/
for the first series (including design considerations, etc.) This series
continues to depend on en/merge-recursive-fixes in next, at least
contextual
This populates a set of directory renames for us. The set of directory
renames is not yet used, but will be in subsequent commits.
Note that the use of a string_list for possible_new_dirs in the new
dir_rename_entry struct implies an O(n^2) algorithm; however, in practice
I expect the number of d
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 330
1 file changed, 330 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 713ad2b75e..b469c807c2 1007
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 458
1 file changed, 458 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index a6cd38336c..8ea9ec49bc 1007
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 442
1 file changed, 442 insertions(+)
create mode 100755 t/t6043-merge-rename-directories.sh
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge
Move this function so it can re-use some others (without either
moving all of them or adding an annoying split between function
declarations and definitions). Cheat slightly by adding a blank line
for readability, and in order to silence checkpatch.pl.
Reviewed-by: Stefan Beller
Signed-off-by: E
Create a new function, get_diffpairs() to compute the diff_filepairs
between two trees. While these are currently only used in
get_renames(), I want them to be available to some new functions. No
actual logic changes yet.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
merge-recur
I came up with the testcases in the first eight sections before coding up
the implementation. The testcases in this section were mostly ones I
thought of while coding/debugging, and which I was too lazy to insert
into the previous sections because I didn't want to re-label with all the
testcase re
Add a long note about why we are not considering "partial directory
renames" for the current directory rename detection implementation.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 115
1 file changed, 115
Previously, if !o->detect_rename then get_renames() would return an
empty string_list, and then process_renames() would have nothing to
iterate over. It seems more straightforward to simply avoid calling
either function in that case.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 336
1 file changed, 336 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index b469c807c2..9ae245a522 1007
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 153
1 file changed, 153 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index b22a9052b3..8049ed5fc9 1007
The amount of logic in merge_trees() relative to renames was just a few
lines, but split it out into new handle_renames() and cleanup_renames()
functions to prepare for additional logic to be added to each. No code or
logic changes, just a new place to put stuff for when the rename detection
gains
This commit hooks together all the directory rename logic by making the
necessary changes to the rename struct, it's dst_entry, and the
diff_filepair under consideration.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
merge-recursive.c | 187 ++
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 396
1 file changed, 396 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 9ae245a522..6db1439675 1007
When a file is present in HEAD before the merge and the other side of the
merge does not modify that file, we try to avoid re-writing the file and
making it stat-dirty. However, when a file is present in HEAD before the
merge and was in a directory that was renamed by the other side of the
merge,
get_renames() would look up stage data that already existed (populated
in get_unmerged(), taken from whatever unpack_trees() created), and if
it didn't exist, would call insert_stage_data() to create the necessary
entry for the given file. The insert_stage_data() fallback becomes
much more importa
directory renaming and merging can cause one or more files to be moved to
where an existing file is, or to cause several files to all be moved to
the same (otherwise vacant) location. Add checking and reporting for such
cases, falling back to no-directory-rename handling for such paths.
Reviewed-
get_renames() has always zero'ed out diff_queued_diff.nr while only
manually free'ing diff_filepairs that did not correspond to renames.
Further, it allocated struct renames that were tucked away in the
return string_list. Make sure all of these are deallocated when we
are done with them.
Reviewe
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
merge-recursive.c | 42 +++--
t/t6043-merge-rename-directories.sh | 6 +++---
2 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 404
1 file changed, 404 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 6db1439675..e211e8ca31 1007
This fixes an issue that existed before my directory rename detection
patches that affects both normal renames and renames implied by
directory rename detection. Additional codepaths that only affect
overwriting of dirty files that are involved in directory rename
detection will be added in a subs
If a file on one side of history was renamed, and merely modified on the
other side, then applying a directory rename to the modified side gives us
a rename/rename(1to2) conflict. We should only apply directory renames to
pairs representing either adds or renames.
Making this change means that a
Before trying to apply directory renames to paths within the given
directories, we want to make sure that there aren't conflicts at the
file level either. If there aren't any, then get the new name from
any directory renames.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
merge-re
Add a testcase showing spurious rename/rename(1to2) conflicts occurring
due to directory rename detection.
Also add a pair of testcases dealing with moving directory hierarchies
around that were suggested by Stefan Beller as "food for thought" during
his review of an earlier patch series, but whic
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 367
1 file changed, 367 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index cbbb949014..a6cd38336c 1007
One person was interested enough for me to go back through and also
rename all the paired 'old' variables to match the new names for the
variables which were named 'new'.
Brandon Williams (37):
object_info: change member name from 'typename' to 'type_name'
object: rename function 'typename' to
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
builtin/cat-file.c | 2 +-
cache.h| 2 +-
packfile.c | 6 +++---
sha1_file.c| 10 +-
4 files changed, 10 insertion
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
builtin/rev-parse.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/builtin/rev-parse.c b/builti
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
builtin/cat-file.c | 2 +-
builtin/diff-tree.c| 2 +-
builtin/fast-export.c | 8
bui
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
builtin/pack-objects.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
blame.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/blame.c b/blame.c
index 2893f3c10..21c867
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
builtin/reflog.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/reflog.c b/builtin/reflog.c
index 223372531..ac3dcd7
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
builtin/help.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index d3c8fc408..598867cfe
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
builtin/pack-redundant.c | 54
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/builtin/pack-redu
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
commit.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/commit.c b/commit.c
index cd9ace105..874b6e510 100644
---
Jeff King writes:
> This function takes two ptr/len pairs, which implies that
> they can be arbitrary buffers. But internally, it assumes
> that each "ptr" is NUL-terminated at "len" (because we
> memcpy an extra byte to pick up the NUL terminator).
Makes quite a lot of sense. In addition, get_
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
diff.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
index 0a9a0cdf1..d682d0d1f 100644
--- a/diff.c
+++ b/d
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
builtin/checkout.c | 196 ++---
1 file changed, 98 insertions(+), 98 deletions(-)
diff --git a/builtin/checkout.
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
read-cache.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/read-cache.c b/read-cache.c
i
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
http.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/http.c b/http.c
index 597771271..41cfa41a9 100644
--- a/http.c
+++
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
ref-filter.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c
index 9dae6cfe3..99a45beb1
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
imap-send.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 36c7c1b4f..ffb0a6eca 10064
Rename C++ keyword in order to bring the codebase closer to being able
to be compiled with a C++ compiler.
Signed-off-by: Brandon Williams
---
line-log.c | 56 +++---
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/line-log.c b/line
1 - 100 of 191 matches
Mail list logo