--
We have been trying to reach you.
On Tue, Jul 24, 2018 at 2:49 PM Junio C Hamano wrote:
>
> But lack of TZ does not give me enough hint about which content it
> happened. The fact that this was done late at night on weekend is
> indeed interesting, and I may not care what time it locally was for
> me, so perhaps this is an
Hello,
On 24.07.2018 21:55, Alban Gruin wrote:
Hi,
I published a new blog post here:
https://blog.pa1ch.fr/posts/2018/07/24/en/gsoc2018-week12.html
Cheers,
Alban
Great!
Mine is also up:
https://ungps.github.io/2018/07/22/week-12/
Best,
Paul
On Tue, Jul 24, 2018 at 3:09 PM Jonathan Nieder wrote:
> Hm. Looks like dimmed_zebra was introduced in v2.15.0-rc0~16^2~2
> (2017-06-30), so it has been around for a while (about a year). But I
> would like to be able to simplify by getting rid of it.
>
>
Brandon Williams wrote:
> If so I suggest we move away from the term "pack" protocol. Mostly
> because maybe at some future date we don't only want to communicate to
> transfer packs. So at the risk of bikeshedding (and because naming is
> hard) I think we should begin talking about the over
On Mon, Jun 11, 2018 at 03:47:43AM -0400, Eric Sunshine wrote:
> Here's what I had envisioned when reading your emails about OID lookup
> table functionality:
>
> --- >8 ---
> test_detect_hash () {
> test_hash_algo=...
> }
>
> test_oid_cache () {
> while read tag rest
> do
>
On Tue, Jul 24, 2018 at 02:13:07PM -0700, Junio C Hamano wrote:
> Yup. I actually was leaning toward saying "all of them are OK in
> practice, so the person who is actually spear-heading the work gets
> to choose", but if we picked SHA-256 now, that would not be a choice
> that Brian has to later
Eric Sunshine wrote:
> Subject: diff: --color-moved: rename "dimmed_zebra" to "dimmed-zebra"
It would be clearer to say something like
diff --color-moved: add "dimmed-zebra" synonym for "dimmed_zebra"
> The --color-moved "dimmed_zebra" mode (with an underscore) is an
> anachronism.
Hi Jonathan
On 24.07.18 23:59, Jonathan Nieder wrote:
> Hi,
>
> Beat Bolli wrote:
>
>> When compiling under Apple LLVM version 9.1.0 (clang-902.0.39.2) with
>> "make DEVELOPER=1 DEVOPTS=pedantic", the compiler says
>>
>> remote-odb.c:87:2: error: static function 'remote_odb_do_init' is
>>
Hi,
Beat Bolli wrote:
> When compiling under Apple LLVM version 9.1.0 (clang-902.0.39.2) with
> "make DEVELOPER=1 DEVOPTS=pedantic", the compiler says
>
> remote-odb.c:87:2: error: static function 'remote_odb_do_init' is
> used in an inline function with external linkage
>
The --color-moved "dimmed_zebra" mode (with an underscore) is an
anachronism. Most options and modes are hyphenated. It is more difficult
to type and somewhat more difficult to read than those which are
hyphenated. Therefore, rename it to "dimmed-zebra", and nominally
deprecate "dimmed_zebra".
Hi,
Beat Bolli wrote:
> --- a/packfile.h
> +++ b/packfile.h
> @@ -6,7 +6,6 @@
> /* in object-store.h */
> struct packed_git;
> struct object_info;
> -enum object_type;
>
> /*
> * Generate the filename to be used for a pack file with checksum "sha1" and
Good catch. This means packfile.h
Following up on my previous series bb/pedantic for gcc, here are two
fixes for pedantic compilation under MacOS 10.13.6 (High Sierra) with
the command line tools of Xcode Version 9.4.1 (9F2000).
Beat Bolli (2):
packfile: drop a repeated enum declaration
remote-odb: un-inline function
When compiling under Apple LLVM version 9.1.0 (clang-902.0.39.2) with
"make DEVELOPER=1 DEVOPTS=pedantic", the compiler says
remote-odb.c:87:2: error: static function 'remote_odb_do_init' is
used in an inline function with external linkage
[-Werror,-Wstatic-in-inline]
Remove the
When compiling under Apple LLVM version 9.1.0 (clang-902.0.39.2) with
"make DEVELOPER=1 DEVOPTS=pedantic", the compiler says
error: redeclaration of already-defined enum 'object_type' is a GNU
extension [-Werror,-Wgnu-redeclared-enum]
According to
Linus Torvalds writes:
> From: Linus Torvalds
>
> This adds --date=human, which skips the timezone if it matches the
> current time-zone, and doesn't print the whole date if that matches (ie
> skip printing year for dates that are "this year", but also skip the
> whole date itself if it's in
Please did you recieve the email i sent you ?
On Tue, Jul 24, 2018 at 05:13:36PM +0200, Duy Nguyen wrote:
> I guess you have the starting points you need after Jeff's and Junio's
> explanation (and it would be great if cache-tree could actually be for
> for this two-way merge). But to make it easier for new people in
> future, maybe we
On Tue, Jul 24, 2018 at 10:18:03AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >I think this is inherent in the scheme (we're losing some delta
> >opportunities). But I think it's also made worse because the delta
> >window gets clogged with candidates that are forbidden by
Linus Torvalds writes:
> On Tue, Jul 24, 2018 at 12:01 PM Edward Thomson
> wrote:
>>
>> Switching gears, if I look at this from the perspective of the libgit2
>> project, I would also prefer SHA-256 or SHA3 over blake2b. To support
>> blake2b, we'd have to include - and support - that code
Hi,
frede...@ofb.net wrote:
> Next week I should have time to send you a patch with the manual page
> reordered...
Yay!
> although, unless you have a special 'diff' which can
> detect when text has been moved from one place to another, I'm
> guessing it would take you even longer
Hi,
Linus Torvalds wrote:
> On Tue, Jul 24, 2018 at 12:01 PM Edward Thomson
> wrote:
>> Switching gears, if I look at this from the perspective of the libgit2
>> project, I would also prefer SHA-256 or SHA3 over blake2b. To support
>> blake2b, we'd have to include - and support - that code
On 7/24/2018 3:21 PM, Junio C Hamano wrote:
Ben Peart writes:
From: Ben Peart
If the new core.optimizecheckout config setting is set to true, speed up
"git checkout -b foo" by avoiding the work to merge the working tree. This
is valid because no merge needs to occur - only creating the
On 07/24, Junio C Hamano wrote:
> Brandon Williams writes:
>
> >> Not about this patch, but I wonder if an organization along the
> >> following lines would make sense?
> >>
> >> 1. Rename pack-protocol.txt to protocol-v1.txt. Rename
> >> protocol-v2.txt to pack-protocol.txt.
> >>
> >>
On Tue, Jul 24, 2018 at 12:01 PM Edward Thomson
wrote:
>
> Switching gears, if I look at this from the perspective of the libgit2
> project, I would also prefer SHA-256 or SHA3 over blake2b. To support
> blake2b, we'd have to include - and support - that code ourselves. But
> to support
Stefan Beller writes:
> On Mon, Jul 23, 2018 at 9:41 PM Jonathan Nieder wrote:
>>
>> Hi,
>>
>> Stefan Beller wrote:
>>
>> > As a user I wondered what the diff algorithms are about. Offer at least
>> > a basic explanation on the differences of the diff algorithms.
>>
>> Interesting. Let's see.
Brandon Williams writes:
>> Not about this patch, but I wonder if an organization along the
>> following lines would make sense?
>>
>> 1. Rename pack-protocol.txt to protocol-v1.txt. Rename
>> protocol-v2.txt to pack-protocol.txt.
>>
>> 2. Make pack-protocol.txt self-contained, and
On Tue, Jul 24, 2018 at 03:30:10PM +, g...@jeffhostetler.com wrote:
> From: Jeff Hostetler
>
> In commit fb0dc3bac135e9f6243bd6d293e8c9293c73b9cd code was added
> to builtin/config.c to define a new function and a forward declaration
> for an array of unknown size. This causes a compile
Hello Jonathan,
Thank you for replying to me earlier. I just wanted to follow up on
this thread. Did you decide not to go with my proposal?
Next week I should have time to send you a patch with the manual page
reordered... although, unless you have a special 'diff' which can
detect when text has
On 7/24/2018 2:42 PM, Eric Sunshine wrote:
On Tue, Jul 24, 2018 at 2:01 PM Ben Peart wrote:
If the new core.optimizecheckout config setting is set to true, speed up
Maybe:
Add core.optimizeCheckout config setting which, when true, speeds up
Sure
"git checkout -b foo" by
On 07/24, Junio C Hamano wrote:
> Jonathan Tan writes:
>
> >> 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
Jonathan Tan writes:
>> 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 onto them.
On 07/17, Brandon Williams wrote:
> Signed-off-by: Brandon Williams
> ---
>
> Since introducing protocol v2 and enabling fetch I've been thinking
> about what its inverse 'push' would look like. After talking with a
> number of people I have a longish list of things that could be done to
>
In the interest of code hygiene, make it easier to compile Git with the
flag -pedantic.
Pure pedantic compilation with GCC 7.3 results in one warning per use of
the translation macro `N_`:
warning: array initialized from parenthesized string constant [-Wpedantic]
Therefore also disable the
Ben Peart writes:
> From: Ben Peart
>
> If the new core.optimizecheckout config setting is set to true, speed up
> "git checkout -b foo" by avoiding the work to merge the working tree. This
> is valid because no merge needs to occur - only creating the new branch/
> updating the refs. Any
On 24.07.18 20:50, Junio C Hamano wrote:
> Beat Bolli writes:
>
>> On 24.07.18 20:22, Junio C Hamano wrote:
>>
This was already fixed (differently) in
<20180705183445.30901-1-dev+...@drbeat.li>.
>>>
>>> Thanks for saving me from having to dig the list archive myself.
>>> Yes, it is
On Fri, Jul 20, 2018 at 09:52:20PM +, brian m. carlson wrote:
>
> To summarize the discussion that's been had in addition to the above,
> Ævar has also stated a preference for SHA-256 and I would prefer BLAKE2b
> over SHA-256 over SHA3-256, although any of them would be fine.
>
> Are there
On 07/20, Jeff Hostetler wrote:
>
>
> On 7/18/2018 1:15 PM, Brandon Williams wrote:
> > On 07/18, Stefan Beller wrote:
> > > On Wed, Jul 18, 2018 at 6:31 AM Derrick Stolee wrote:
> > > >
> > > > On 7/17/2018 7:25 PM, Stefan Beller wrote:
> > > > > On Tue, Jul 17, 2018 at 2:09 PM Brandon
Hi,
I published a new blog post here:
https://blog.pa1ch.fr/posts/2018/07/24/en/gsoc2018-week12.html
Cheers,
Alban
Beat Bolli writes:
> On 24.07.18 20:22, Junio C Hamano wrote:
>
>>> This was already fixed (differently) in
>>> <20180705183445.30901-1-dev+...@drbeat.li>.
>>
>> Thanks for saving me from having to dig the list archive myself.
>> Yes, it is already applied to the tip of the topic that
On Tue, Jul 24, 2018 at 2:01 PM Ben Peart wrote:
> If the new core.optimizecheckout config setting is set to true, speed up
Maybe:
Add core.optimizeCheckout config setting which, when true, speeds up
> "git checkout -b foo" by avoiding the work to merge the working tree. This
> is valid
On 24.07.18 20:22, Junio C Hamano wrote:
> Beat Bolli writes:
>
>> Hi Jeff
>>
>> On 24.07.18 17:30, g...@jeffhostetler.com wrote:
>>> From: Jeff Hostetler
>>>
>>> In commit fb0dc3bac135e9f6243bd6d293e8c9293c73b9cd code was added
>>> to builtin/config.c to define a new function and a forward
Beat Bolli writes:
> Hi Jeff
>
> On 24.07.18 17:30, g...@jeffhostetler.com wrote:
>> From: Jeff Hostetler
>>
>> In commit fb0dc3bac135e9f6243bd6d293e8c9293c73b9cd code was added
>> to builtin/config.c to define a new function and a forward declaration
>> for an array of unknown size. This
On 07/23, Jonathan Nieder wrote:
> Hi,
>
> Brandon Williams wrote:
>
> > --- a/Documentation/technical/pack-protocol.txt
> > +++ b/Documentation/technical/pack-protocol.txt
> > @@ -50,7 +50,8 @@ Each Extra Parameter takes the form of `=` or
> > ``.
> >
> > Servers that receive any such Extra
Hi Jeff
On 24.07.18 17:30, g...@jeffhostetler.com wrote:
> From: Jeff Hostetler
>
> In commit fb0dc3bac135e9f6243bd6d293e8c9293c73b9cd code was added
> to builtin/config.c to define a new function and a forward declaration
> for an array of unknown size. This causes a compile error under MSVC.
Hi Jeff
On 24.07.18 16:42, g...@jeffhostetler.com wrote:
> From: Jeff Hostetler
>
> Replace non-standard "\e" escape sequence with "\x1B".
This was already fixed in <20180708144342.11922-4-dev+...@drbeat.li>.
Cheers,
Beat
>
> In commit 7a17918c34f4e83982456ffe22d880c3cda5384f a trace
g...@jeffhostetler.com writes:
> From: Jeff Hostetler
>
> In commit fb0dc3bac135e9f6243bd6d293e8c9293c73b9cd code was added
> to builtin/config.c to define a new function and a forward declaration
> for an array of unknown size. This causes a compile error under MSVC.
>
> Reorder the code to
g...@jeffhostetler.com writes:
> From: Jeff Hostetler
>
> Replace non-standard "\e" escape sequence with "\x1B".
>
> In commit 7a17918c34f4e83982456ffe22d880c3cda5384f a trace message with
> several "\e" escape sequences was added. This causes a compiler warning
> under MSVC.
>
> According to
From: Ben Peart
If the new core.optimizecheckout config setting is set to true, speed up
"git checkout -b foo" by avoiding the work to merge the working tree. This
is valid because no merge needs to occur - only creating the new branch/
updating the refs. Any other options force it through the
On Mon, Jul 23, 2018 at 9:41 PM Jonathan Nieder wrote:
>
> Hi,
>
> Stefan Beller wrote:
>
> > As a user I wondered what the diff algorithms are about. Offer at least
> > a basic explanation on the differences of the diff algorithms.
>
> Interesting. Let's see.
>
> [...]
> > ---
On Tue, Jul 24, 2018 at 10:43 AM wrote:
> Replace non-standard "\e" escape sequence with "\x1B".
>
> In commit 7a17918c34f4e83982456ffe22d880c3cda5384f a trace message with
> several "\e" escape sequences was added. This causes a compiler warning
> under MSVC.
Wrong commit. That code was
On Tue, Jul 24, 2018 at 5:26 AM Jeff King wrote:
> 1. We'll only trigger with -Wimplicit-function-declaration
> (and only stop compilation with -Werror). These are
> generally enabled by DEVELOPER=1. If you _don't_ have
> that set, we'll still catch the problem, but only at
>
On Tue, Jul 24, 2018 at 2:58 AM Jeff King wrote:
>
> On Mon, Jul 23, 2018 at 11:52:49AM -0700, Stefan Beller wrote:
>
> > > +DELTA ISLANDS
> > > +-
> > [...]
> >
> > I had to read all of this [background information] to understand the
> > concept and I think it is misnamed, as my gut
Jeff King writes:
>I think this is inherent in the scheme (we're losing some delta
>opportunities). But I think it's also made worse because the delta
>window gets clogged with candidates that are forbidden by the island
>config.
Hmph, and the reason why objects that do not even
In the interest of code hygiene, make it easier to compile Git with the
flag -pedantic.
Pure pedantic compilation with GCC 7.3 results in one warning per use of
the translation macro `N_`:
warning: array initialized from parenthesized string constant [-Wpedantic]
Therefore also disable the
Junio C Hamano writes:
>> +---
>> +[pack]
>> +island = refs/virtual/([0-9]+)/heads/
>> +island = refs/virtual/([0-9]+)/tags/
>> +island = refs/virtual/([0-9]+)/(pull)/
>> +---
>
> It becomes clear only from this
Christian Couder writes:
> +Islands are configured via the `pack.island` option, which can be
> +specified multiple times. Each value is a left-anchored regular
> +expressions matching refnames. For example:
> +
> +---
> +[pack]
> +island = refs/heads/
>
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
This rewrites the submodes of interactive rebase (`--continue`,
`--skip`, `--edit-todo`, and `--show-current-patch`) in C.
git-rebase.sh is then modified to call directly git-rebase--interactive2
instead of git-rebase--interactive.sh.
Signed-off-by: Alban Gruin
---
This moves the rebase--helper modes still used by
git-rebase--preserve-merges.sh (`--shorten-ids`, `--expand-ids`,
`--check-todo-list`, `--rearrange-squash` and `--add-exec-commands`) to
rebase--interactive.c.
git-rebase--preserve-merges.sh is modified accordingly, and
rebase--helper.c is removed
This rewrites checkout_onto() from shell to C.
A new command (“checkout-onto”) is added to rebase--helper.c. The shell
version is then stripped.
Signed-off-by: Alban Gruin
---
No changes since v3.
builtin/rebase--helper.c | 7 ++-
git-rebase--interactive.sh | 25
This rewrites (the misnamed) setup_reflog_action() from shell to C. The
new version is called prepare_branch_to_be_rebased().
A new command is added to rebase--helper.c, “checkout-base”, as well as
a new flag, “verbose”, to avoid silencing the output of the checkout
operation called by
This adds a new function, run_command_silent_on_success(), to
redirect the stdout and stderr of a command to a strbuf, and then to run
that command. This strbuf is printed only if the command fails. It is
functionnaly similar to output() from git-rebase.sh.
run_git_commit() is then refactored to
As part of the rewrite of interactive rebase, the sequencer will need to
open the sequence editor to allow the user to edit the todo list.
Instead of duplicating the existing launch_editor() function, this
refactors it to a new function, launch_specified_editor(), which takes
the editor as a
This rewrites the part of interactive rebase which initializes the
basic state, make the script and complete the action, as a buitin, named
git-rebase--interactive2 for now. Others modes (`--continue`,
`--edit-todo`, etc.) will be rewritten in the next commit.
git-rebase--interactive.sh is
This removes the modes `--skip-unnecessary-picks`, `--append-todo-help`,
and `--checkout-onto` from rebase--helper.c, the functions of
git-rebase--interactive.sh that were rendered useless by the rewrite of
complete_action(), and append_todo_help_to_file() from
rebase-interactive.c.
This rewrites the part of init_revisions_and_shortrevisions() needed by
`--complete-action` (which initialize $shortrevisions) from shell to C.
When `upstream` is empty, it means that the user launched a `rebase
--root`, and `onto` contains the ID of an empty commit. As a range
between an empty
This rewrites the part of init_revisions_and_shortrevisions() needed by
`--make-script` from shell to C. The new version is called
get_revision_ranges(), and is a static function inside of
rebase--helper.c. As this does not initialize $shortrevision, the
original shell version is not yet
This removes git-rebase--interactive.sh, as its functionnality has been
replaced by git-rebase--interactive2.
git-rebase--interactive2.c is then renamed to git-rebase--interactive.c.
Signed-off-by: Alban Gruin
---
.gitignore| 1 -
Makefile
This rewrites write_basic_state() from git-rebase.sh in C. This is the
first step in the conversion of init_basic_state(), hence the mode in
rebase--helper.c is called INIT_BASIC_STATE. init_basic_state() will be
converted in the next commit.
The part of read_strategy_opts() that parses the
This rewrites init_basic_state() from shell to C. The call to
write_basic_state() in cmd_rebase__helper() is replaced by a call to the
new function.
The shell version is then stripped from git-rebase--interactive.sh.
Signed-off-by: Alban Gruin
---
builtin/rebase--helper.c | 23
This refactors append_todo_help() to write its message to a buffer
instead of the todo-list. This is needed for the rewrite of
complete_action(), which will come after the next commit.
As rebase--helper still needs the file manipulation part of
append_todo_help(), it is extracted to a temporary
If the todo list generated by `--make-script` is empty,
complete_action() writes a noop, but if it has only commented-out
commands, it will abort with the message "Nothing to do", and does not
launch the editor. This adds a new test to ensure that
complete_action() behaves this way.
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list
Instead of skip_unnecessary_picks() printing its result to stdout, it
returns it into a struct object_id, as the rewrite of complete_action()
(to come in the next commit) will need it.
rebase--helper then is modified to fit this change.
Signed-off-by: Alban Gruin
---
builtin/rebase--helper.c |
This rewrites the edit-todo functionality from shell to C.
To achieve that, a new command mode, `edit-todo`, is added, and the
`write-edit-todo` flag is removed, as the shell script does not need to
write the edit todo help message to the todo list anymore.
The shell version is then stripped in
This makes rebase_path_todo(), get_missing_commit_check_level() and the
enum check_level accessible outside sequencer.c, renames check_level to
missing_commit_check_level, and prefixes its value names by
MISSING_COMMIT_ to avoid namespace pollution.
This function and this enum will eventually be
This rewrites append_todo_help() from shell to C. It also incorporates
some parts of initiate_action() and complete_action() that also write
help texts to the todo file.
This also introduces the source file rebase-interactive.c. This file
will contain functions necessary for interactive rebase
This patch series rewrite the interactive rebase from shell to C.
It is based on master (as of 2018-07-24).
Changes since v3:
- The `--verbose` option is stored directly into opts.verbose
- Drop includes in rebase-interactive.h
- skip_unnecessary_picks() now returns an object_id instead of
Christian Couder writes:
> From: Jeff King
>
> As get_delta_base() will be used outside 'packfile.c' in
> a following commit, let's make it non static and let's
> declare it in 'packfile.h'.
As a public function in *.h, don't we want a bit of comment there to
help those who want to use it from
On Tue, Jul 24, 2018 at 6:20 AM Jeff King wrote:
> At least that's my view of it. unpack_trees() has always been a
> terrifying beast that I've avoided looking too closely at.
/me nods on the terrifying part.
> > After a quick look at the code, the only place I can find that tries to use
> >
Phillip Wood writes:
> From: Phillip Wood
>
> Single quotes should be escaped as \' not \\'. Note that this only
> affects authors that contain a single quote and then only external
> scripts that read the author script and users whose git is upgraded from
> the shell version of rebase -i while
From: Jeff Hostetler
In commit fb0dc3bac135e9f6243bd6d293e8c9293c73b9cd code was added
to builtin/config.c to define a new function and a forward declaration
for an array of unknown size. This causes a compile error under MSVC.
Reorder the code to forward declare the function instead of the
On Mon, Jul 23, 2018 at 04:51:38PM -0400, Ben Peart wrote:
> >>> What's the current state of the index before this checkout?
> >>
> >> This was after running "git checkout" multiple times so there was really
> >> nothing for git to do.
> >
> > Hmm.. this means cache-tree is fully valid, unless
I would like to speak with the person that managing photos for your
company?
We provide image editing like – photos cutting out and retouching.
Enhancing your images is just a part of what we can do for your business.
Whether you’re an ecommerce
store or portrait photographer, real estate
I would like to speak with the person that managing photos for your
company?
We provide image editing like – photos cutting out and retouching.
Enhancing your images is just a part of what we can do for your business.
Whether you’re an ecommerce
store or portrait photographer, real estate
From: Jeff Hostetler
Replace non-standard "\e" escape sequence with "\x1B".
In commit 7a17918c34f4e83982456ffe22d880c3cda5384f a trace message with
several "\e" escape sequences was added. This causes a compiler warning
under MSVC.
According to [1], the "\e" sequence is an extension supported
Beat Bolli writes:
> On 23.07.18 20:53, Junio C Hamano wrote:
>>
>>> This is the convenience knob for all developers that led to the series
>>> bb/pedantic[1]. It does not depend on this series, though.
>>
>> Yup, but "make DEVELOPER=Yes" build won't pass unless this patch is
>> queued after
All of the numeric formatting done by this function uses
"%u", but we pass in a signed "int". The actual range
doesn't matter here, since the conditional makes sure we're
always showing reasonably small numbers. And even gcc's
format-checker does not seem to mind. But it's potentially
confusing to
When we initially added the strbuf_readlink() function in
b11b7e13f4 (Add generic 'strbuf_readlink()' helper function,
2008-12-17), the point was that we generally have a _guess_
as to the correct size based on the stat information, but we
can't necessarily trust it.
Over the years, a few callers
The return type of readlink() is ssize_t, not int. This
probably doesn't matter in practice, as it would require a
2GB symlink destination, but it doesn't hurt to be careful.
Signed-off-by: Jeff King
---
strbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/strbuf.c
A few strbuf functions store the length of a strbuf in a
temporary variable. We should always use size_t for this, as
it's possible for a strbuf to exceed an "int" (e.g., a 2GB
string on a 64-bit system). This is unlikely in practice,
but we should try to behave sensibly on silly or malicious
The iconv interface takes a size_t, which is the appropriate
type for an in-memory buffer. But our reencode_string_*
functions use integers, meaning we may get confusing results
when the sizes exceed INT_MAX. Let's use size_t
consistently.
Signed-off-by: Jeff King
---
convert.c | 6 +++---
When converting a string with iconv, if the output buffer
isn't big enough, we grow it. But our growth is done without
any concern for integer overflow. So when we add:
outalloc = sofar + insz * 2 + 32;
we may end up wrapping outalloc (which is a size_t), and
allocating a too-small buffer. We
This series is primarily about the first two patches to convert our
iconv helpers to use size_t consistently. I posted them to the
git-security list a while back, wondering if there was something sneaky
you could do here. But after some discussion, the consensus was no, you
can't.
The other four
On Sun, Jul 22, 2018 at 07:48:36AM +0200, Christian Couder wrote:
> From: Jeff King
>
> Signed-off-by: Jeff King
> Signed-off-by: Christian Couder
> ---
> t/t9930-delta-islands.sh | 143 +++
For topics that I'm not immediately sending upstream, I usually
On Sun, Jul 22, 2018 at 07:48:31AM +0200, Christian Couder wrote:
> I kept Peff as the author and took the liberty to add his
> Signed-off-by to all the patches.
Yes, that's fine. This is a topic I've been meaning to upstream for a
long time, so I'm happy to see it progressing in that direction.
On Mon, Jul 23, 2018 at 11:52:49AM -0700, Stefan Beller wrote:
> > +DELTA ISLANDS
> > +-
> [...]
>
> I had to read all of this [background information] to understand the
> concept and I think it is misnamed, as my gut instinct first told me
> to have deltas only "within an island and
On Mon, Jul 23, 2018 at 06:50:46PM -0700, Junio C Hamano wrote:
> Side Note: there are a few workflow elements I do want to
> keep using but they currently *lose* the mapping info. An
> obvious one is
>
> $ git checkout -b to/pic master &&
> ... review in MUA
1 - 100 of 108 matches
Mail list logo
