On Tue, Oct 15, 2019 at 6:25 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> >> * en/merge-recursive-directory-rename-fixes (2019-10-12) 2 commits
> >> (merged to 'next' on 2019-10-15 at ebfdc3ff7b)
> >> + merge-recursive: fix merging a subdirectory into the root directory
> >> + merge
I am Nancy l from Incredible USA Although I am a Business Development Manager
by job, I am looking forward to learning from all of you guys!
-
EDataMine is one of the leading Offshore Data Entry Company from India. We
provide Outsourcing Data Entry Services and Solutions as per client need
>From commit bbb1b8a35a, ("notes: check number of parameters to "git
notes copy"", 2010-06-28), we have a test for too many or too few
of parameters provided to `git notes copy'.
However, the test is only ensure the command will fail but it doesn't
really check if it fails because of number of par
The builtin/notes.c::copy() function is prepared to handle either
one or two arguments given from the command line;
in case of one argument is given, to-obj defaults to HEAD.
When bbb1b8a3 ("notes: check number of parameters to "git notes copy"",
2010-06-28) tried to make sure "git notes copy" (wi
On 2019-10-16 11:01:34 +0900, Junio C Hamano wrote:
> Doan Tran Cong Danh writes:
>
> > The target objects for copying notes was defaulted to HEAD from very
> > early stage of git-notes.
> >
> > However, that default was limited by commit bbb1b8a35a, ("notes: check
> > number of parameters to "gi
Junio C Hamano writes:
>> int graph_next_line(struct git_graph *graph, struct strbuf *sb)
>
> I just noticed it but does this have to be extern? Nobody outside
> graph.[ch] seems to have any reference to it.
I was stupid; strike this part out.
Thanks.
On Tue, Oct 15, 2019 at 2:13 PM Wink Saville wrote:
>>
>> Something like this makes sense and I've thought about the problem for
>> a long time. Unfortunately it's quite a bit trickier to do this.
>>
>> It would solve the problem more generally though, and definitely seems
>> like the right approa
"James Coglan via GitGitGadget" writes:
> This effect is applied to both "normal" two-parent merges, and to
> octopus merges. It also reduces the vertical space needed for pre-commit
> lines, as the merge occupies one less column than usual.
>
> Before: After:
>
> | *
"James Coglan via GitGitGadget" writes:
> From: James Coglan
>
> Now that the display width of graph lines is implicitly tracked via the
> `graph_line` interface, the calls to `graph_pad_horizontally()` no
> longer need to be located inside the individual output functions, where
> the character
"James Coglan via GitGitGadget" writes:
> +struct graph_line {
> + struct strbuf *buf;
> + size_t width;
> +};
> +
> +static inline void graph_line_addch(struct graph_line *line, int c)
> +{
> + strbuf_addch(line->buf, c);
> + line->width++;
> +}
> +
> +static inline void graph_li
James Coglan writes:
>> Is there a reason why you need a pointer to a strbuf that is
>> allocated separately? E.g. would it make it harder to manage
>> if the above were
>>
>> struct graphbuf {
>> struct strbuf buf;
>> int width; /* display width in columns */
>>
William Baker writes:
> At this time there are no other MIDX_* flags and so there's always the option
> to revisit the best way to handle multiple MIDX_* flags if/when additional
> flags are added.
I do not care too deeply either way, but if you wrote it in one way,
how about completing the seri
"Maxim Belsky via GitGitGadget" writes:
> From: Maxim Belsky
> Subject: Re: [PATCH v3 1/1] doc: Change zsh git completion file name
Lack of attention to the detail. This is not about changing the
filename anymore.
Subject: [PATCH v3] completion: clarify installation instruction for zsh
p
Doan Tran Cong Danh writes:
> The target objects for copying notes was defaulted to HEAD from very
> early stage of git-notes.
>
> However, that default was limited by commit bbb1b8a35a, ("notes: check
> number of parameters to "git notes copy"", 2010-06-28).
Sorry, I don't quite get the above.
Johannes Schindelin writes:
> Hi Phillip,
>
> On Tue, 15 Oct 2019, Phillip Wood via GitGitGadget wrote:
>
>> When I converted the sequencer to avoid forking git commit i forgot about
>> the post-commit hook. These patches are based on
>> pw/rebase-i-show-HEAD-to-reword, otherwise the new test fai
Thanks. I think we are ready for 'next'.
Elijah Newren writes:
>> * en/merge-recursive-directory-rename-fixes (2019-10-12) 2 commits
>> (merged to 'next' on 2019-10-15 at ebfdc3ff7b)
>> + merge-recursive: fix merging a subdirectory into the root directory
>> + merge-recursive: clean up get_renamed_dir_portion()
>>
>> A few glitches
Derrick Stolee writes:
> On 10/15/2019 3:11 AM, Eric Wong wrote:
>> Junio C Hamano wrote:
>>> Eric Wong writes:
>>>
I just took a brief look, but that appears to leak memory.
"hashmap_free(var, 1)" should be replaced with
"hashmap_free_entries(var, struct foo, member)"
From: James Coglan
The change I'm about to make requires being able to inspect the mapping
array that was used to render the last GRAPH_COLLAPSING line while
rendering a GRAPH_COMMIT line. The `new_mapping` array currently exists
as a pre-allocated space for computing the next `mapping` array dur
From: James Coglan
In 04005834ed ("log: fix coloring of certain octopus merge shapes",
2018-09-01) there is a fix for the coloring of dashes following an
octopus merge. It makes a distinction between the case where all parents
introduce a new column, versus the case where the first parent collaps
From: James Coglan
When a merge commit is printed and its final parent is the same commit
that occupies the column to the right of the merge, this results in a
kink in the displayed edges:
* |
|\ \
| |/
| *
Graphs containing these shapes can be hard to read, as t
From: James Coglan
Currently, when we display a merge whose first parent is already present
in a column to the left of the merge commit, we display the first parent
as a vertical pipe `|` in the GRAPH_POST_MERGE line and then immediately
enter the GRAPH_COLLAPSING state. The first-parent line tra
From: James Coglan
I will shortly be making some changes to
`graph_insert_into_new_columns()` and so am trying to simplify it. One
possible simplification is that we can extract the loop for finding the
element in `new_columns` containing the given commit.
`find_new_column_by_commit()` contains
From: James Coglan
Following the introduction of "left-skewed" merges, which are merges
whose first parent fuses with another edge to its left, we have some
more edge cases to deal with in the display of commit and post-merge
lines.
The current graph code handles the following cases for edges ap
From: James Coglan
I will shortly be making some changes to this function and so am trying
to simplify it. It currently contains some duplicated logic; both
branches the function can take assign the commit's column index into
the `mapping` array and increment `mapping_index`.
Here I change the f
From: James Coglan
Now that the display width of graph lines is implicitly tracked via the
`graph_line` interface, the calls to `graph_pad_horizontally()` no
longer need to be located inside the individual output functions, where
the character counting was previously being done.
All the function
From: James Coglan
When a graph contains edges that are in the process of collapsing to the
left, but those edges cross a commit line, the effect is that the edges
have a jagged appearance:
*
|\
| *
| \
*-. \
|\ \ \
| | * |
| * | |
From: James Coglan
There's a duplication of logic between `graph_insert_into_new_columns()`
and `graph_update_width()`. `graph_insert_into_new_columns()` is called
repeatedly by `graph_update_columns()` with an `int *` that tracks the
offset into the `mapping` array where we should write the next
From: James Coglan
The commits following this one introduce a series of improvements to the
layout of graphs, tidying up a few edge cases, namely:
- merge whose first parent fuses with an existing column to the left
- merge whose last parent fuses with its immediate neighbor on the right
- edges
From: James Coglan
All the output functions called by `graph_next_line()` currently keep
track of how many printable chars they've written to the buffer, before
calling `graph_pad_horizontally()` to pad the line with spaces. Some
functions do this by incrementing a counter whenever they write to
From: James Coglan
This computation is repeated in a couple of places and I need to add
another condition to it to implement a further improvement to the graph
rendering, so I'm extracting this into a function.
Signed-off-by: James Coglan
---
graph.c | 12
1 file changed, 8 insert
This series of patches are designed to improve the output of the log --graph
command; their effect can be summed up in the following diagram:
BeforeAfter
---
*
|\
| * *
| |\ |\
|
From: James Coglan
In 04005834ed ("log: fix coloring of certain octopus merge shapes",
2018-09-01) there is a fix for the coloring of dashes following an
octopus merge. It makes a distinction between the case where all parents
introduce a new column, versus the case where the first parent collaps
From: James Coglan
The change I'm about to make requires being able to inspect the mapping
array that was used to render the last GRAPH_COLLAPSING line while
rendering a GRAPH_COMMIT line. The `new_mapping` array currently exists
as a pre-allocated space for computing the next `mapping` array dur
From: James Coglan
The commits following this one introduce a series of improvements to the
layout of graphs, tidying up a few edge cases, namely:
- merge whose first parent fuses with an existing column to the left
- merge whose last parent fuses with its immediate neighbor on the right
- edges
From: James Coglan
Currently, when we display a merge whose first parent is already present
in a column to the left of the merge commit, we display the first parent
as a vertical pipe `|` in the GRAPH_POST_MERGE line and then immediately
enter the GRAPH_COLLAPSING state. The first-parent line tra
From: James Coglan
When a merge commit is printed and its final parent is the same commit
that occupies the column to the right of the merge, this results in a
kink in the displayed edges:
* |
|\ \
| |/
| *
Graphs containing these shapes can be hard to read, as t
From: James Coglan
Following the introduction of "left-skewed" merges, which are merges
whose first parent fuses with another edge to its left, we have some
more edge cases to deal with in the display of commit and post-merge
lines.
The current graph code handles the following cases for edges ap
This series of patches are designed to improve the output of the log --graph
command; their effect can be summed up in the following diagram:
BeforeAfter
---
*
|\
| * *
| |\ |\
|
From: James Coglan
When a graph contains edges that are in the process of collapsing to the
left, but those edges cross a commit line, the effect is that the edges
have a jagged appearance:
*
|\
| *
| \
*-. \
|\ \ \
| | * |
| * | |
From: James Coglan
All the output functions called by `graph_next_line()` currently keep
track of how many printable chars they've written to the buffer, before
calling `graph_pad_horizontally()` to pad the line with spaces. Some
functions do this by incrementing a counter whenever they write to
From: James Coglan
I will shortly be making some changes to this function and so am trying
to simplify it. It currently contains some duplicated logic; both
branches the function can take assign the commit's column index into
the `mapping` array and increment `mapping_index`.
Here I change the f
From: James Coglan
There's a duplication of logic between `graph_insert_into_new_columns()`
and `graph_update_width()`. `graph_insert_into_new_columns()` is called
repeatedly by `graph_update_columns()` with an `int *` that tracks the
offset into the `mapping` array where we should write the next
From: James Coglan
This computation is repeated in a couple of places and I need to add
another condition to it to implement a further improvement to the graph
rendering, so I'm extracting this into a function.
Signed-off-by: James Coglan
---
graph.c | 12
1 file changed, 8 insert
From: James Coglan
Now that the display width of graph lines is implicitly tracked via the
`graph_line` interface, the calls to `graph_pad_horizontally()` no
longer need to be located inside the individual output functions, where
the character counting was previously being done.
All the function
From: James Coglan
I will shortly be making some changes to
`graph_insert_into_new_columns()` and so am trying to simplify it. One
possible simplification is that we can extract the loop for finding the
element in `new_columns` containing the given commit.
`find_new_column_by_commit()` contains
On 11.10.19 16:43, Daniel Lezcano wrote:
>
> Hi all,
>
> Is there a way to specify a line to be added in the change-log after the
> SOB with git-am ?
>
> I would like to do something:
>
> git am -s -l "Link: https://lore.kernel.org/r/"
>
> Which will give:
>
> blabla
>
> Signed-off-by: aut..
On 10/8/19 6:32 PM, SZEDER Gábor wrote:
>>> No, they tend to show (PROGRESS | REGRESS), at least both gdb and lldb
>>> do.
>
> I was wrong here, gdb does this, but lldb, unfortunately, doesn't; see
> my other reply in this thread.
>
>> What I was worried about is that the constants that are used t
On 2019.10.14 17:12, Jonathan Tan wrote:
> The specification of promisor packfiles (in partial-clone.txt) states
> that the .promisor files that accompany packfiles do not matter (just
> like .keep files), so whenever a packfile is fetched from the promisor
> remote, Git has been writing empty .pro
On 10/11/19 6:26 PM, Junio C Hamano wrote:
> "William Baker via GitGitGadget" writes:
>
>> +# Test staging/unstaging files that appear at the end of the index. Test
>> +# file names begin with 'z' so that they are sorted to the end of the
>> index.
>
> Well, the test is now done in a freshly
Hey,
Today I've spent a few hours to understand why git-completion doesn't work
in my zsh shell. It was because I thought ~/.zsh/_git should be a dictionary
with git-completion.zsh file.
I think this change may save some hours for someone else.
Maxim Belsky (1):
doc: Change zsh git completion
From: Maxim Belsky
The original comment does not describe type of ~/.zsh/_git explicitly
and zsh does not warn or fail if a user create it as a dictionary.
So unexperienced users could be misled by the original comment.
There is a small update to clarify it.
Helped-by: Johannes Schindelin
Help
On Mon, Oct 14, 2019 at 8:07 PM Junio C Hamano wrote:
>
> Wink Saville writes:
>
> > When --prefix-tags is passed to `git remote add` the tagopt is set to
> > --prefix-tags and a second fetch line is added so tags are placed in
> > a separate hierarchy per remote.
>
>
> In the olden days, there w
On Tue, Oct 15, 2019 at 10:39 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Tue, 15 Oct 2019, Elijah Newren wrote:
>
> > On Tue, Oct 15, 2019 at 2:04 AM Junio C Hamano wrote:
> > > * en/fast-imexport-nested-tags (2019-10-04) 8 commits
> > > (merged to 'next' on 2019-10-07 at 3e75779e10)
>
> In short, if you truly want to see "separate hierarchy per remote",
> you should consider how you can reliably implement an equivalent of
> "git branch --list --remote"; a design that does not allow it is a
> failure.
>
> A better solution with longer lifetime would probably be to use
>
>
Hi Elijah,
On Tue, 15 Oct 2019, Elijah Newren wrote:
> On Tue, Oct 15, 2019 at 2:04 AM Junio C Hamano wrote:
> > * en/fast-imexport-nested-tags (2019-10-04) 8 commits
> > (merged to 'next' on 2019-10-07 at 3e75779e10)
> > + fast-export: handle nested tags
> > + t9350: add tests for tags of t
From: Johannes Schindelin
The CI builds are failing for Mac OS X due to a change in the
location of the perforce cask. The command outputs the following
error:
+ brew install caskroom/cask/perforce
Error: caskroom/cask was moved. Tap homebrew/cask-cask instead.
Preface the "brew install
Running CI on Mac OS X in Azure Pipelines is currently broken due to a moved
homebrew package.
Thanks, -Stolee
Johannes Schindelin (1):
ci(osx): use new location of the `perforce` cask
ci/install-dependencies.sh | 1 +
1 file changed, 1 insertion(+)
base-commit: 108b97dc372828f0e72e56bbb40c
As an alternate for the incoming patch,
this snippet could be used to eliminate some dead code in builtin/notes.c
Since `argc' will always be 2 in the removed condition.
Also:
Signed-off-by: Doan Tran Cong Danh
---
builtin/notes.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
On Tue, Oct 15, 2019 at 01:07:59AM +, brian m. carlson wrote:
> Fix this by passing the option from the transport code through to remote
> helpers, and from the HTTP remote helper down to send-pack. With this
> change, we can detect if the server side rejects the push and report
> back approp
The target objects for copying notes was defaulted to HEAD from very
early stage of git-notes.
However, that default was limited by commit bbb1b8a35a, ("notes: check
number of parameters to "git notes copy"", 2010-06-28).
Lift that limitation by adjust the check for numbers of arguments.
Signed-
Hi Everyone, hoping you might have a solution for
this problem:
CONTEXT
* I'm serving git repos using "smart https" via
apache and basic authentication; everything works
fine.
* We're moving to SSO via Azure AD and apache
mod_auth_openidc; this works fine for gitweb (on
the same server a
On Tue, Oct 15, 2019 at 2:04 AM Junio C Hamano wrote:
> * en/fast-imexport-nested-tags (2019-10-04) 8 commits
> (merged to 'next' on 2019-10-07 at 3e75779e10)
> + fast-export: handle nested tags
> + t9350: add tests for tags of things other than a commit
> + fast-export: allow user to request
Hi Phillip,
On Tue, 15 Oct 2019, Phillip Wood via GitGitGadget wrote:
> When I converted the sequencer to avoid forking git commit i forgot about
> the post-commit hook. These patches are based on
> pw/rebase-i-show-HEAD-to-reword, otherwise the new test fails as that branch
> changes the number
From: Derrick Stolee
Getting started with a sparse-checkout file can be daunting. Help
users start their sparse enlistment using 'git sparse-checkout init'.
This will set 'core.sparseCheckout=true' in their config, write
an initial set of patterns to the sparse-checkout file, and update
their wor
From: Derrick Stolee
The 'git sparse-checkout set' subcommand takes a list of patterns
and places them in the sparse-checkout file. Then, it updates the
working directory to match those patterns. For a large list of
patterns, the command-line call can get very cumbersome.
Add a '--stdin' option
From: Derrick Stolee
The sparse-checkout feature can have quadratic performance as
the number of patterns and number of entries in the index grow.
If there are 1,000 patterns and 1,000,000 entries, this time can
be very significant.
Create a new Boolean config option, core.sparseCheckoutCone, to
From: Derrick Stolee
The sparse-checkout feature is mostly hidden to users, as its
only documentation is supplementary information in the docs for
'git read-tree'. In addition, users need to know how to edit the
.git/info/sparse-checkout file with the right patterns, then run
the appropriate 'git
From: Derrick Stolee
The sparse-checkout builtin used 'git read-tree -mu HEAD' to update the
skip-worktree bits in the index and to update the working directory.
This extra process is overly complex, and prone to failure. It also
requires that we write our changes to the sparse-checkout file befo
From: Derrick Stolee
If two 'git sparse-checkout set' subcommands are launched at the
same time, the behavior can be unexpected as they compete to write
the sparse-checkout file and update the working directory.
Take a lockfile around the writes to the sparse-checkout file. In
addition, acquire
From: Derrick Stolee
The parent and recursive patterns allowed by the "cone mode"
option in sparse-checkout are restrictive enough that we
can avoid using the regex parsing. Everything is based on
prefix matches, so we can use hashsets to store the prefixes
from the sparse-checkout file. When che
From: Derrick Stolee
The sparse-checkout feature in "cone mode" can use the fact that
the recursive patterns are "connected" to the root via parent
patterns to decide if a directory is entirely contained in the
sparse-checkout or entirely removed.
In these cases, we can skip hashing the paths wi
From: Derrick Stolee
The read-tree builtin has a --verbose option that signals to show
progress and other data while updating the index. Update this to
be on by default when stderr is a terminal window.
This will help tools like 'git sparse-checkout' to automatically
benefit from progress indica
From: Derrick Stolee
During the development of the sparse-checkout "cone mode" feature,
an incorrect placement of the initializer for "use_cone_patterns = 1"
caused warnings to show up when a .gitignore file was present with
non-cone-mode patterns. This was fixed in the original commit
introducin
From: Derrick Stolee
To make the cone pattern set easy to use, update the behavior of
'git sparse-checkout [init|set]'.
Add '--cone' flag to 'git sparse-checkout init' to set the config
option 'core.sparseCheckoutCone=true'.
When running 'git sparse-checkout set' in cone mode, a user only
needs
From: Jeff Hostetler
When Git updates the working directory with the sparse-checkout
feature enabled, the unpack_trees() method calls clear_ce_flags()
to update the skip-wortree bits on the cache entries. This
check can be expensive, depending on the patterns used.
Add trace2 regions around the
From: Derrick Stolee
When a large repository has many sparse-checkout patterns, the
process for updating the skip-worktree bits can take long enough
that a user gets confused why nothing is happening. Update the
clear_ce_flags() method to write progress.
Signed-off-by: Derrick Stolee
---
cache
From: Derrick Stolee
If a user provides folders A/ and A/B/ for inclusion in a cone-mode
sparse-checkout file, the parsing logic will notice that A/ appears
both as a "parent" type pattern and as a "recursive" type pattern.
This is unexpected and hence will complain via a warning and revert
to th
From: Derrick Stolee
The instructions for disabling a sparse-checkout to a full
working directory are complicated and non-intuitive. Add a
subcommand, 'git sparse-checkout disable', to perform those
steps for the user.
Signed-off-by: Derrick Stolee
---
Documentation/git-sparse-checkout.txt | 2
V4 UPDATE: Rebased on latest master to include ew/hashmap and
ds/include-exclude in the base.
This series makes the sparse-checkout feature more user-friendly. While
there, I also present a way to use a limited set of patterns to gain a
significant performance boost in very large repositories.
Sp
From: Derrick Stolee
The 'git sparse-checkout set' subcommand takes a list of patterns
as arguments and writes them to the sparse-checkout file. Then, it
updates the working directory using 'git read-tree -mu HEAD'.
The 'set' subcommand will replace the entire contents of the
sparse-checkout fil
From: Derrick Stolee
When someone wants to clone a large repository, but plans to work
using a sparse-checkout file, they either need to do a full
checkout first and then reduce the patterns they included, or
clone with --no-checkout, set up their patterns, and then run
a checkout manually. This
On 10/15/2019 3:11 AM, Eric Wong wrote:
> Junio C Hamano wrote:
>> Eric Wong writes:
>>
>>> I just took a brief look, but that appears to leak memory.
>>>
>>> "hashmap_free(var, 1)" should be replaced with
>>> "hashmap_free_entries(var, struct foo, member)"
>>>
>>> Only "hashmap_free(var, 0)" can
On Mon, Oct 14, 2019 at 02:46:29PM -0700, Jonathan Tan wrote:
> > > 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
> > > enu
Hi Pratyush,
Thanks for reviewing. How does this work, do I send a re-roll of the patch(es)?
Birger
From: Phillip Wood
This function was declared in commit.h but was implemented in
builtin/commit.c so was not part of libgit. Move it to libgit so we can
use it in the sequencer. This simplifies the implementation of
run_prepare_commit_msg_hook() and will be used in the next commit.
Signed-off-by
From: Phillip Wood
Commit 65850686cf ("rebase -i: rewrite write_basic_state() in C",
2018-08-28) accidentially added new function declarations after
the #endif at the end of the include guard.
Signed-off-by: Phillip Wood
---
sequencer.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
From: Phillip Wood
As $EDITOR is exported setting it in one test affects all subsequent
tests. Avoid this by always setting it in a subshell. This commit leaves
20 calls to set_fake_editor that are not in subshells as they can
safely be removed in the next commit once all the other editor setting
When I converted the sequencer to avoid forking git commit i forgot about
the post-commit hook. These patches are based on
pw/rebase-i-show-HEAD-to-reword, otherwise the new test fails as that branch
changes the number of commits we make.
Thanks to Dscho & Junio for their comments on V1. I've made
From: Phillip Wood
Neither of the commands executed in the subshell change any shell
variables or the current directory so there is no need for them to be
executed in a subshell.
Signed-off-by: Phillip Wood
---
t/t3404-rebase-interactive.sh | 6 ++
1 file changed, 2 insertions(+), 4 deleti
From: Phillip Wood
Prior to commit 356ee4659b ("sequencer: try to commit without forking
'git commit'", 2017-11-24) the sequencer would always run the
post-commit hook after each pick or revert as it forked `git commit` to
create the commit. The conversion to committing without forking `git
commi
From: Phillip Wood
Some tests were calling set_fake_editor to ensure they had a sane no-op
editor set. Now that all the editor setting is done in subshells these
tests can rely on EDITOR=: and so do not need to call set_fake_editor.
Also add a test at the end to detect any future additions messi
Before, when format-patch generated a cover letter, only the body would
be populated with a branch's description while the subject would be
populated with placeholder text. However, users may want to have the
subject of their cover letter automatically populated in the same way.
Teach format-patch
Currently, format-patch only puts "*** SUBJECT HERE ***" when a cover
letter is generated. However, it is already smart enough to be able to
populate the cover letter with the branch description so there's no
reason why it cannot populate the subject as well.
Teach format-patch the `--infer-cover-
Before, `thread` and `config_cover_letter` were defined as ints even
though they behaved as enums. Define actual enums and change these
variables to use these new definitions.
Signed-off-by: Denton Liu
Signed-off-by: Junio C Hamano
---
builtin/log.c | 30 +-
1 file c
Commit 30984ed2e9 (format-patch: support deep threading, 2009-02-19),
introduced the following lines:
#define THREAD_SHALLOW 1
[...]
thread = git_config_bool(var, value) && THREAD_SHALLOW;
Since git_config_bool() returns a bool, the trailing `&& THREAD_SHALLOW`
is a no-o
On Mon, Oct 14, 2019 at 11:27:54AM -0700, Jonathan Tan wrote:
> > 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
> > >
Junio C Hamano wrote:
> Eric Wong writes:
>
> > I just took a brief look, but that appears to leak memory.
> >
> > "hashmap_free(var, 1)" should be replaced with
> > "hashmap_free_entries(var, struct foo, member)"
> >
> > Only "hashmap_free(var, 0)" can become "hashmap_free(var)"
>
> I delibera
98 matches
Mail list logo
