Adjusting the build process to rely more on curl-config to populate
linker flags instead of manually populating flags based off detected
features.
Originally, a configure-invoked build would check for SSL-support in the
target curl library. If enabled, NEEDS_SSL_WITH_CURL would be set and
used in
Noticed-by: SZEDER Gábor
Signed-off-by: Nguyễn Thái Ngọc Duy
---
On top of nd/per-worktree-ref-iteration
Documentation/git-worktree.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index
On Sat, Nov 3, 2018 at 1:38 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > On Fri, Nov 2, 2018 at 2:32 PM Ben Peart wrote:
> >>
> >> From: Ben Peart
> >>
> >> During an "add", a call is made to run_diff_files() which calls
> >> check_remove() for each index-entry. The preload_index()
Derrick Stolee writes:
> Uncovered code in 'next' not in 'master'
>
>
> pretty.c
> 4de9394dcb 1264) if (c->signature_check.primary_key_fingerprint)
> 4de9394dcb 1265) strbuf_addstr(sb,
> c->signature_check.primary_key_fingerprint);
> 4de9394dcb 1266)
Here is the coverage report for today. Some builds were timing out, so I
removed the tests with number 9000 or more from the build [1]. Hopefully
this is a temporary measure.
Thanks,
-Stolee
[1]
https://dev.azure.com/git/git/_build/results?buildId=250&_a=summary=logs
---
pu:
Stefan Beller writes:
>
> -static int parse_color_moved_ws(const char *arg)
> +static unsigned parse_color_moved_ws(const char *arg)
> {
> int ret = 0;
> struct string_list l = STRING_LIST_INIT_DUP;
> @@ -312,15 +312,19 @@ static int parse_color_moved_ws(const char *arg)
>
Ævar Arnfjörð Bjarmason writes:
> Although I'm on the fence with the approach in 1/5. Should this be a
> giant getopt switch statement like that in a helper script?
>
> An alternative would be to write out a shell file similar to
> GIT-BUILD-OPTIONS and source that from this thing. I don't
Junio C Hamano writes:
> Johannes Sixt writes:
>
>>> Yep, correct on all counts. I'm in favor of changing the commit message to
>>> only say that this patch removes Warning C28159.
>>
>> How about this fixup instead?
>
> Isn't that already in 'next'? I didn't check, though.
Well, it turnsout
Johannes Sixt writes:
>> Yep, correct on all counts. I'm in favor of changing the commit message to
>> only say that this patch removes Warning C28159.
>
> How about this fixup instead?
Isn't that already in 'next'? I didn't check, though.
Duy Nguyen writes:
> On Fri, Nov 2, 2018 at 2:32 PM Ben Peart wrote:
>>
>> From: Ben Peart
>>
>> During an "add", a call is made to run_diff_files() which calls
>> check_remove() for each index-entry. The preload_index() code distributes
>> some of the costs across multiple threads.
>
>
Jeff King writes:
>> to have *some* names there, for the sake of a
>> simply described coding style without many exceptions
>> (especially those exceptions that rely on judgement).
>
> Fair enough.
For the record, there aren't "many" exceptions to the rule that was
suggested earlier: if you
I think up to patch 4 here should be near a state that's ready for
inclusion.
Although I'm on the fence with the approach in 1/5. Should this be a
giant getopt switch statement like that in a helper script? An
alternative would be to write out a shell file similar to
GIT-BUILD-OPTIONS and source
This code is still very much unlike our usual style since it was
lifted from the Makefile, but we can at least make some of it use the
usual style and line spacing.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
install_programs | 28 +---
1 file changed, 17 insertions(+),
Back when git was initially written the likes of "git-add", "git-init"
etc. were installed in the user's $PATH. A few years later everything,
with a few exceptions like git-upload-pack and git-receive-pack, was
expected to be invoked as "git $cmd".
Now something like a decade later we're still
Change the fallback mechanism where we try to create hardlinks and
ultimately fall back on a plain copy to emit the errors it encounters
instead of hiding them away and silently falling back to copying.
Hiding these errors dates back to 3e073dc561 ("Makefile: always
provide a fallback when
Add a switch for use in conjunction with the INSTALL_SYMLINKS flag
added in ad874608d8 ("Makefile: optionally symlink libexec/git-core
binaries to bin/git", 2018-03-13).
Now it's possible to install git with:
INSTALL_SYMLINKS=YesPlease NO_INSTALL_SYMLINKS_FALLBACK=YesPlease
And know for
Move a 37 line for-loop mess out of "install" and into a helper
script. This started out fairly innocent but over the years has grown
into a hard-to-maintain monster, and my recent ad874608d8 ("Makefile:
optionally symlink libexec/git-core binaries to bin/git", 2018-03-13)
certainly didn't help.
As we check command line options more strictly and allow configuration
variables to be parsed more leniently, we need take different actions
based on whether an unknown value is given on the command line or in the
config.
Move the die() call out of parse_color_moved_ws into the parsing
of command
On Thu, Nov 1, 2018 at 6:19 PM james harvey wrote:
> > This sounds like you are asking for two things:
> > (1) make color-moved work with words (somehow)
> > (2) allow the user to fine tune the heuristics for a block,
> > such that default=zebra would still work.
>
> I was asking for #1.
I
On Fri, Nov 02, 2018 at 12:50:05PM -0700, Stefan Beller wrote:
> > +/*
> > + * Can be used as a no-op hunk_fn for xdi_diff_outf(), since a NULL
> > + * one just sends the hunk line to the line_fn callback).
> > + */
> > +void discard_hunk_line(void *, long, long, long, long, const char *, long);
On Fri, Nov 2, 2018 at 12:09 PM Derrick Stolee wrote:
>
> On 11/2/2018 2:53 PM, Elijah Newren wrote:
> > Major question:
> >* You'll note that I edited the last two patches to mark them as RFC.
> > To be honest, I'm not sure what to do with these. They improve code
> > coverage of
In handle_rename_rename_1to2(), we have duplicated error handling
around colliding paths. Specifically, when we want to write out
the file and there is a directory or untracked file in the way,
we need to create a temporary file to hold the contents. This has
some special output to alert the user,
> +/*
> + * Can be used as a no-op hunk_fn for xdi_diff_outf(), since a NULL
> + * one just sends the hunk line to the line_fn callback).
> + */
> +void discard_hunk_line(void *, long, long, long, long, const char *, long);
Recently we had the discussion on style and naming things.
On the one
On 11/2/2018 2:53 PM, Elijah Newren wrote:
Major question:
* You'll note that I edited the last two patches to mark them as RFC.
To be honest, I'm not sure what to do with these. They improve code
coverage of new code, but the same gaps existed in the old code;
they only show
NOTE: This test added solely to improve code coverage of new code added in
this series.
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 37 +
1 file changed, 37 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
> > This offloading-to-CDN (or "mostly resumable clone" in the
> > sense that the communication with the server is minimal, and
> > you get most of your data via resumable http range-requests)
> > sounds like complete offtopic, but is one of the requirements
> > for the repo to submodule
This results in no-net change of behavior, it simply ensures that all
file-collision conflict handling types are being handled the same by
calling the same function.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 29 +
1 file changed, 21 insertions(+), 8
There are three conflict types that represent two (possibly entirely
unrelated) files colliding at the same location:
* add/add
* rename/add
* rename/rename(2to1)
These three conflict types already share more similarity than might be
immediately apparent from their description: (1) the
Later patches in this series will modify file collision conflict
handling (e.g. from rename/add and rename/rename(2to1) conflicts) so
that multiply nested conflict markers can arise even before considering
conflicts in the virtual merge base. Including the virtual merge base
will provide a way to
Add testcases dealing with file collisions for the following types of
conflicts:
* add/add
* rename/add
* rename/rename(2to1)
All these conflict types simplify down to two files "colliding"
and should thus be handled similarly. This means that rename/add and
rename/rename(2to1) conflicts
This makes the rename/rename(2to1) conflicts use the new
handle_file_collision() function. Since that function was based
originally on the rename/rename(2to1) handling code, the main
differences here are in what was added. In particular:
* Instead of storing files at collide_path~HEAD and
NOTE: This test added solely to improve code coverage of new code added in
this series.
Signed-off-by: Elijah Newren
---
t/t6036-recursive-corner-cases.sh | 51 +++
1 file changed, 51 insertions(+)
diff --git a/t/t6036-recursive-corner-cases.sh
When we have a rename/rename(1to2) conflict, each of the renames can
collide with a file addition. Each of these rename/add conflicts suffered
from the same kinds of problems that normal rename/add suffered from.
Make the code use handle_file_conflicts() as well so that we get all the
same fixes
When a single file is renamed, it can also be modified, yielding the
possibility of that renamed file having content conflicts. If two
different such files are renamed into the same location, then two-way
merging those files may result in nested conflicts. Add a testcase that
makes sure we get
This series depends on en/merge-cleanup-more and is built on that
series. (It merges cleanly to master, next, and pu -- well, as long
as v3 of this series is excluded from pu, that is).
This series makes all the "file collision" conflict types be handled
consistently; making them all behave like
This makes the rename/add conflict handling make use of the new
handle_file_collision() function, which fixes several bugs and improves
things for the rename/add case significantly. Previously, rename/add
would:
* Not leave any higher order stage entries in the index, making it
appear as
On Fri, Nov 2, 2018 at 6:09 PM Stefan Beller wrote:
>
> On Fri, Nov 2, 2018 at 9:10 AM Duy Nguyen wrote:
> >
> > I use git-bundle today and it occurs to me that if I want to use it to
> > transfer part of a history that involves submodule changes, things
> > aren't pretty. Has anybody given
On Fri, Nov 02, 2018 at 06:32:36PM +0100, Nicolas Mailhot wrote:
> > I did create the way git credential matches repo urls. And I do not
> > think your proposal is a good idea. The credential system is about
> > interacting with a remote URL, and creating a commit object is a local
> > operation.
Derrick Stolee writes:
> On 10/31/2018 8:54 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Tue, Oct 30 2018, Junio C Hamano wrote:
>>> Derrick Stolee writes:
In contrast, maximum generation numbers and corrected commit
dates both performed quite well. They are frequently the top
Le vendredi 02 novembre 2018 à 12:51 -0400, Jeff King a écrit :
Hi,
Thank you for reading the RFE.
> I did create the way git credential matches repo urls. And I do not
> think your proposal is a good idea. The credential system is about
> interacting with a remote URL, and creating a commit
On 11/2/2018 1:27 PM, Elijah Newren wrote:
On Thu, Nov 1, 2018 at 12:01 AM Elijah Newren wrote:
On Wed, Oct 31, 2018 at 8:08 AM Derrick Stolee wrote:
On 10/19/2018 3:31 PM, Elijah Newren wrote:
[snip]
+ char *new_path = NULL;
+ if
On Thu, Nov 1, 2018 at 12:01 AM Elijah Newren wrote:
>
> On Wed, Oct 31, 2018 at 8:08 AM Derrick Stolee wrote:
> >
> > On 10/19/2018 3:31 PM, Elijah Newren wrote:
> > > [snip]
> > >
> > > + char *new_path = NULL;
> > > + if (dir_in_way(b->path,
On 11/2/2018 1:23 PM, Stefan Beller wrote:
On Fri, Nov 2, 2018 at 6:03 AM Derrick Stolee wrote:
On 10/30/2018 6:08 PM, Stefan Beller wrote:
This converts the 'show_submodule_header' function to use
the repository API properly, such that the submodule objects
are not added to the main object
On Fri, Nov 2, 2018 at 6:03 AM Derrick Stolee wrote:
>
> On 10/30/2018 6:08 PM, Stefan Beller wrote:
> > This converts the 'show_submodule_header' function to use
> > the repository API properly, such that the submodule objects
> > are not added to the main object store.
> >
> > Signed-off-by:
On Fri, Nov 2, 2018 at 11:43 AM Johannes Sixt wrote:
>
> Am 02.11.18 um 15:47 schrieb Steve Hoelzer:
> > On Thu, Nov 1, 2018 at 5:22 AM Johannes Sixt wrote:
> >>
> >> Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget:
> >>> @@ -614,7 +618,7 @@ restart:
> >>>
> >>> if (!rc &&
Hi Alban
On 02/11/2018 16:26, Alban Gruin wrote:
Hi Phillip,
Le 02/11/2018 à 11:09, Phillip Wood a écrit :
+ struct todo_item *items = NULL,
+ base_item = {TODO_EXEC, NULL, 0, 0, commands_len, 0};
+
+ strbuf_addstr(buf, commands);
+ base_item.offset_in_buf = buf->len -
On Fri, Nov 2, 2018 at 9:10 AM Duy Nguyen wrote:
>
> I use git-bundle today and it occurs to me that if I want to use it to
> transfer part of a history that involves submodule changes, things
> aren't pretty. Has anybody given thought on how to do binary history
> transfer that contains changes
On Fri, Nov 02, 2018 at 09:57:30AM +0100, Nicolas Mailhot wrote:
> Or are you arguing that having two separate mecanisms in git, to match
> config directives to repo urls, is some kind of improvement?
There are already are multiple mechanisms (e.g., http.* config). So that
ship has sailed. ;)
>
Am 02.11.18 um 15:47 schrieb Steve Hoelzer:
> On Thu, Nov 1, 2018 at 5:22 AM Johannes Sixt wrote:
>>
>> Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget:
>>> @@ -614,7 +618,7 @@ restart:
>>>
>>> if (!rc && orig_timeout && timeout != INFTIM)
>>>{
>>> - elapsed =
On Thu, Nov 01, 2018 at 07:31:15PM +, Ævar Arnfjörð Bjarmason wrote:
> Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON
> test parameter to only be a GIT_TEST_GETTEXT_POISON=
> runtime parameter, to be consistent with other parameters documented
> in "Running tests with
Hi Phillip,
Le 02/11/2018 à 11:09, Phillip Wood a écrit :
+ struct todo_item *items = NULL,
+ base_item = {TODO_EXEC, NULL, 0, 0, commands_len, 0};
+
+ strbuf_addstr(buf, commands);
+ base_item.offset_in_buf = buf->len - commands_len - 1;
+
Hello,
Wanted to bring to your attention an issue that we discovered on our
Windows Jenkins nodes with git scm installed (git.exe). Our Jenkins
servers don't have Internet access. It appears that git.exe is trying
to connect to various Cloudflare and Akamai CDN instances over the
Internet when it
On 11/2/2018 11:23 AM, Junio C Hamano wrote:
Ben Peart writes:
From: Ben Peart
During an "add", a call is made to run_diff_files() which calls
check_remove() for each index-entry. The preload_index() code
distributes some of the costs across multiple threads.
Nice. I peeked around
I use git-bundle today and it occurs to me that if I want to use it to
transfer part of a history that involves submodule changes, things
aren't pretty. Has anybody given thought on how to do binary history
transfer that contains changes from submodules?
Since .bundle files are basically .pack
On Fri, Nov 2, 2018 at 7:19 AM Junio C Hamano wrote:
>
> Farhan Khan writes:
>
> > ...Where is this in the git code? That might
> > serve as a good guide.
>
> There are two major codepaths. One is used at runtime, giving us
> random access into the packfile with the help with .idx file. The
>
On Fri, Nov 2, 2018 at 6:26 AM Farhan Khan wrote:
>
> Hi all,
>
> I am trying to understand the pack file format and have been reading
> the documentation, specifically https://git-scm.com/docs/pack-format
> (which is in git's own git repository as
> "Documentation/technical/pack-format.txt"). I
On Fri, Nov 2, 2018 at 2:32 PM Ben Peart wrote:
>
> From: Ben Peart
>
> During an "add", a call is made to run_diff_files() which calls
> check_remove() for each index-entry. The preload_index() code distributes
> some of the costs across multiple threads.
Instead of doing this site by site.
On 11/2/2018 10:58 AM, Elijah Newren wrote:
On Thu, Nov 1, 2018 at 12:02 PM Derrick Stolee wrote:
On 11/1/2018 2:57 PM, Elijah Newren wrote:
On Thu, Nov 1, 2018 at 5:32 AM Derrick Stolee wrote:
No rush. I'd just like to understand how removing the commit-graph file
can make the new
Ben Peart writes:
> From: Ben Peart
>
> During an "add", a call is made to run_diff_files() which calls
> check_remove() for each index-entry. The preload_index() code
> distributes some of the costs across multiple threads.
Nice. I peeked around and noticed that we already do this in
James Knight writes:
> Makefile | 21 +++--
> config.mak.uname | 5 ++---
> configure.ac | 17 +++--
> 3 files changed, 16 insertions(+), 27 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index b08d5ea25..c3be87b0e 100644
> --- a/Makefile
> +++
On Thu, Nov 1, 2018 at 12:02 PM Derrick Stolee wrote:
>
> On 11/1/2018 2:57 PM, Elijah Newren wrote:
> > On Thu, Nov 1, 2018 at 5:32 AM Derrick Stolee wrote:
> >> No rush. I'd just like to understand how removing the commit-graph file
> >> can make the new algorithm faster. Putting a similar
On Thu, Nov 1, 2018 at 5:22 AM Johannes Sixt wrote:
>
> Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget:
> > From: Steve Hoelzer
> >
> > From Visual Studio 2015 Code Analysis: Warning C28159 Consider using
> > 'GetTickCount64' instead of 'GetTickCount'.
> >
> > Reason:
Good day I am Dr. Joshua Mene a banker here in Cotonu Benin Republic, I have a
lucrative business transaction for you and it is profitable and risk free.
kindly reach me via my private email: me...@rediffmail.com for more details.
Thanks
Dr. Joshua Mene
Derrick Stolee writes:
> On 10/29/2018 11:59 PM, Junio C Hamano wrote:
>> Derrick Stolee writes:
[...]
>>> * **Compatible?** In our test implementation, we use a previously unused
>>>byte of data in the commit-graph format to indicate which reachability
>>>index version we are using.
From: Ben Peart
During an "add", a call is made to run_diff_files() which calls
check_remove() for each index-entry. The preload_index() code distributes
some of the costs across multiple threads.
Because the files checked are restricted to pathspec, adding individual
files makes no measurable
As reported earlier [1], the add_missing_tags() method in remote.c has
quadratic performance. Some of that performance is curbed due to the
generation-number cutoff in in_merge_bases_many(). However, that fix doesn't
help users without a commit-graph, and it can still be painful if that
cutoff is
From: Derrick Stolee
The existing reachability algorithms in commit-reach.c focus on
finding merge-bases or determining if all commits in a set X can
reach at least one commit in a set Y. However, for two commits sets
X and Y, we may also care about which commits in Y are reachable
from at least
From: Derrick Stolee
The add_missing_tags() method currently has quadratic behavior.
This is due to a linear number (based on number of tags T) of
calls to in_merge_bases_many, which has linear performance (based
on number of commits C in the repository).
Replace this O(T * C) algorithm with an
From: Derrick Stolee
The get_reachable_subset() method returns the list of commits in
the 'to' array that are reachable from at least one commit in the
'from' array. Add tests that check this method works in a few
cases:
1. All commits in the 'to' list are reachable. This exercises the
On 10/30/2018 6:08 PM, Stefan Beller wrote:
This converts the 'show_submodule_header' function to use
the repository API properly, such that the submodule objects
are not added to the main object store.
Signed-off-by: Stefan Beller
A couple tests are broken in 'pu' when run with
Good day I am Dr. Joshua Mene a banker here in Cotonu Benin Republic, I have a
lucrative business transaction for you and it is profitable and risk free.
kindly reach me via my private email: me...@rediffmail.com for more details.
Thanks
Dr. Joshua Mene
Jeff King writes:
> There's another mention in Documentation/technical/api-object-access.txt.
Yes, and we are on the same page on that one.
>
> But since the entire API is undocumented, I'm not sure it matters much.
> That file has been a placeholder since 2007. Maybe we should just delete
>
Jeff King writes:
> ... it seems rather silly that we have xdiff generate a string
> just so that we can parse it from within the same process. So instead I
> improved the xdiff interface to pass the actual integers out, made use
> of it as appropriate, and then in the final patch we can just
--
Greetings,
I wish to seek your assistance for the transfer of US$35M depository
made by a politician for an investment program that has
remained dormant for years now.I shall provide you with more details
and relevant documents that will help you understand the transaction.
Mr. Hama
Hi Alban
On 01/11/2018 23:31, Alban Gruin wrote:
> Le 30/10/2018 à 17:47, Phillip Wood a écrit :
>> On 27/10/2018 22:29, Alban Gruin wrote:
>>> This refactors sequencer_add_exec_commands() to work on a todo_list to
>>> avoid redundant reads and writes to the disk.
>>>
>>> An obvious way to do
Fix a small bug introduced by "7a36987ff (send-email: add an auto option
for transfer encoding, 2018-07-14)"
I saw the following message when setting --transfer-encoding for a file
with the same encoding:
$ git send-email --transfer-encoding=8bit example.patch
Use of uninitialized value
Jakub Narebski writes:
> Stefan Beller writes:
[...]
>> How would this impact creation of a commit?
>>
>> The current generation numbers can be lazily updated or not
>> updated at all. In my understanding of the maximum generation
>> numbers, a new commit would make these maximum generation
>>
Le vendredi 02 novembre 2018 à 09:27 +0100, Christian Couder a écrit :
> On Thu, Nov 1, 2018 at 3:42 PM Nicolas Mailhot
> wrote:
> > Le jeudi 01 novembre 2018 à 15:13 +0100, Christian Couder a écrit :
> > > How can Git know when you commit where you will want to push the
> > > commit afterwards?
On Thu, Nov 1, 2018 at 3:42 PM Nicolas Mailhot
wrote:
>
> Le jeudi 01 novembre 2018 à 15:13 +0100, Christian Couder a écrit :
> >
> > How can Git know when you commit where you will want to push the
> > commit afterwards?
>
> You have an url in the repo config. of course you can change it between
Adjust the autotools configuration to populate libcurl-related linker
flags from curl-config instead of manually populating flags based off
detected features.
Originally, the configuration would check for SSL-support in the target
curl library. If enabled, NEEDS_SSL_WITH_CURL would be set and
On Fri, Oct 26, 2018 at 11:07:33PM +, Ævar Arnfjörð Bjarmason wrote:
> After sending out v2 I noticed I didn't update the examples in a
> couple of the commit messages, and figured I'd finish this up by
> adding a patch to document how this works in the "git-push"
> manpage. This behavior has
On Mon, Oct 29, 2018 at 02:14:02PM +0900, Junio C Hamano wrote:
> Any failure in the &&-chain (or the last grep) would not terminate
> the for loop, so for the purpose of determining the success of this
> test_expect_success, the last "blob" iteration is the only thing
> that matters.
>
> Which
This function was used only for parsing the hunk headers generated by
xdiff. Now that we can use hunk callbacks to get that information
directly, it has outlived its usefulness.
Note to anyone who wants to resurrect it: the "len" parameter was
totally unused, meaning that the function could read
When we count the lines in a diff, we don't actually care about the
contents of each line. By using a hunk callback, we tell xdiff that it
does not need to even bother generating a hunk header line, saving a
small amount of work.
Arguably we could even ignore the hunk headers completely, since
The "diff --check" code needs to know the line number on which each hunk
starts in order to generate its output. We get that now by parsing the
hunk header line generated by xdiff, but it's much simpler to just pass
it directly using a hunk callback.
Signed-off-by: Jeff King
---
diff.c | 20
A combined diff has to line up the hunks for all of the individual
pairwise diffs, and thus needs to know their line numbers and sizes. We
get that now by parsing the hunk header line that xdiff generates.
However, now that xdiff supports a hunk callback, we can just use the
values directly.
Our word-diff does not look at the -/+ lines generated by xdiff at all
(because they are not real lines to show the user, but just the
tokenized words split into lines). Instead we use the line numbers from
the hunk headers to index our own data structure.
As a result, our xdi_diff_outf()
We do not include hunk header lines when computing patch-ids, since
the line numbers would create false negatives. Rather than detect and
skip them in our line callback, we can simply tell xdiff to avoid
generating them.
This is similar to the previous commit, but split out because it
actually
Some callers of xdi_diff_outf() do not look at the generated hunk header
lines at all. By plugging in a no-op hunk callback, this tells xdiff not
to even bother formatting them.
This patch introduces a stock no-op callback and uses it with a few
callers whose line callbacks explicitly ignore hunk
The previous commit taught xdiff to optionally provide the hunk header
data to a specialized callback. But most users of xdiff actually use our
more convenient xdi_diff_outf() helper, which ensures that our callbacks
are always fed whole lines.
Let's plumb the special hunk-callback through this
The xdiff library always emits hunk header lines to our callbacks as
formatted strings like "@@ -a,b +c,d @@\n". This is convenient if we're
going to output a diff, but less so if we actually need to compute using
those numbers, which requires re-parsing the line.
In preparation for moving away
As part of my -Wunused-parameter hunt, I noticed that parse_hunk_header()
can read out-of-bounds in the array it is given. But it turns out not to
be a big problem because we only ever use it to parse lines that xdiff
has just generated.
This is fixable, and I'll show my patch to do so at the end
On Fri, Nov 02, 2018 at 03:05:03PM +0900, Junio C Hamano wrote:
> Remnant of the old name of the function still remains in comments.
> Update them all.
Yay. What's here looks obviously correct.
> Signed-off-by: Junio C Hamano
> ---
> apply.c | 2 +-
> builtin/gc.c | 2 +-
>
Farhan Khan writes:
> ...Where is this in the git code? That might
> serve as a good guide.
There are two major codepaths. One is used at runtime, giving us
random access into the packfile with the help with .idx file. The
other is used when receiving a new packstream to create an .idx
file.
Remnant of the old name of the function still remains in comments.
Update them all.
Signed-off-by: Junio C Hamano
---
apply.c | 2 +-
builtin/gc.c | 2 +-
fast-import.c | 4 ++--
notes.c | 2 +-
object.h | 2 +-
sha1-file.c | 2 +-
6 files changed, 7 insertions(+), 7
95 matches
Mail list logo
