Internally, we represent `git config`'s type specifiers as a bitset
using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique
allows for the representation of multiple type specifiers in the `int
types` field, but this multi-representation is left unused.
In fact, `git config` will n
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values are satisfiable under that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to add extend this fun
Hi,
Here is a v3 of a series to (1) treat type specifiers in `git config` as
singulars rather than a collection of bits, and (2) to prefer --type= over
--.
I have made the following changes since v2:
- Fix some misspellings in Documentation/git-config.txt (cc: René).
- Handle --no-type corre
On April 2, 2018 3:34 PM, Junio C Hamano wrote:
> Subject: [ANNOUNCE] Git v2.17.0
>
> The latest feature release Git v2.17.0 is now available at the usual places.
> It is
> comprised of 516 non-merge commits since v2.16.0, contributed by 71
> people, 20 of which are new faces.
The NonStop platf
On Wed, Apr 04, 2018 at 12:17:06AM +0100, Ramsay Jones wrote:
> >> Is there any reason to believe this would be too small of a value in the
> >> future? Or is a 32 bit unsigned good enough?
> >
> > The linux kernel took ~10 years to produce 500k commits. Even assuming
> > those were all linear (
On 03/04/18 19:28, Jeff King wrote:
> On Tue, Apr 03, 2018 at 11:05:36AM -0700, Brandon Williams wrote:
>
>> On 04/03, Derrick Stolee wrote:
>>> The generation number of a commit is defined recursively as follows:
>>>
>>> * If a commit A has no parents, then the generation number of A is one.
>>
Notes:
I am aware this test is not probably the best one and maybe I
should have first one test that does a one level non-default, before
trying a test with 2 levels of submodules, but I wanted to express the
goal of the patch.
Currently the test fails, so I am obviously missing something.
Since the --log-destination option was added in 0c591cacb ("daemon: add
--log-destination=(stderr|syslog|none)", 2018-02-04) with the explicit
goal of allowing logging to stderr when running in inetd mode, we should
not always redirect stderr to /dev/null in inetd mode, but rather only
when stderr
From: Eddy Petrișor
There are projects such as llvm/clang which use several repositories, and they
might be forked for providing support for various features such as adding Redox
awareness to the toolchain. This typically means the superproject will use
another branch than master, occasionally ev
From: Eddy Petrișor
If a submodule uses a non-default branch and the branch info is versioned, on
submodule update --recursive --init the correct branch should be checked out.
Signed-off-by: Eddy Petrișor
---
t/t7406-submodule-update.sh | 54 +
1 fil
On 25.03.2018 10:08, Eric Sunshine wrote:
On Sat, Mar 24, 2018 at 2:23 PM, Paul-Sebastian Ungureanu
wrote:
Currently, because git stash is not fully converted to C, I
introduced a new helper that will hold the converted commands.
---
diff --git a/builtin/stash--helper.c b/builtin/stash--helpe
On Tue, Apr 3, 2018 at 5:49 AM, Johannes Schindelin
wrote:
> My main evidence that shell scripts on macOS are slower than on Linux was
> the difference of the improvement incurred by moving more things from
> git-rebase--interactive.sh into sequencer.c: Linux saw an improvement only
> of about 3x,
> Currently we have plain, zebra & dimmed_zebra, and zebra is the
> default.
>
> I got an internal report from someone who had, because zebra looked
> crappy in his terminal, moved to "plain", and was reporting getting
> worse moved diffs as a result.
>
> I found that there's essentially a missing
On Tue, Apr 03 2018, Stefan Beller wrote:
> On Tue, Apr 3, 2018 at 12:39 PM, Ævar Arnfjörð Bjarmason
> wrote:
>>
>> On Mon, Apr 02 2018, Stefan Beller wrote:
>>
>>> At the time the move coloring was implemented we thought an enum of modes
>>> is the best to configure this feature. However as we
On Tue, 3 Apr 2018 12:22:32 -0700
Stefan Beller wrote:
> On Mon, Apr 2, 2018 at 5:41 PM, Jonathan Tan wrote:
> > On Mon, 2 Apr 2018 15:48:54 -0700
> > Stefan Beller wrote:
> >
> >> +struct ws_delta {
> >> + int deltachars;
> >> + char firstchar;
> >> +};
> >
> > I'll just make some ove
On Tue, Apr 03, 2018 at 09:33:10PM +0200, Jan Palus wrote:
> My understanding of test "daemon log records all attributes" is that daemon
> process is started in background, some git command is executed and daemon's
> output (saved to daemon.log) is compared against expected value. However
> daemon
On Tue, Apr 03, 2018 at 09:14:50AM -0400, Derrick Stolee wrote:
> > I'm not sure what the exact solution would be, but I imagine something
> > like variable-sized "struct commit"s with the parent pointers embedded,
> > with some kind of flag to indicate the number of parents (and probably
> > some
On Tue, Apr 3, 2018 at 11:53 AM, Alex Ivanov wrote:
> Hi.
> I want to use systemd as fastcgi spawner for gitweb + nginx.
> The traffic is low and number of users is limited + traversal bots. For that
> reason I've decided to use following mimimal services
>
> gitweb.socket
> [Unit]
> Description=
On Tue, Apr 3, 2018 at 12:00 PM, Stefan Beller wrote:
The fun is in the last patch, which allows white space sensitive
languages to trust the move detection, too. Each block that is marked as
moved will have the same delta in {in-, de-}dentation.
I would think this mode might b
On Tue, Apr 3, 2018 at 12:39 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Mon, Apr 02 2018, Stefan Beller wrote:
>
>> At the time the move coloring was implemented we thought an enum of modes
>> is the best to configure this feature. However as we want to tack on new
>> features, the enum would grow
On Mon, Apr 02 2018, Stefan Beller wrote:
> At the time the move coloring was implemented we thought an enum of modes
> is the best to configure this feature. However as we want to tack on new
> features, the enum would grow exponentially.
>
> Refactor the code such that features are enabled via
My understanding of test "daemon log records all attributes" is that daemon
process is started in background, some git command is executed and daemon's
output (saved to daemon.log) is compared against expected value. However
daemon.log is not a straight redirect to file -- it is being piped through
On Mon, Apr 2, 2018 at 5:41 PM, Jonathan Tan wrote:
> On Mon, 2 Apr 2018 15:48:54 -0700
> Stefan Beller wrote:
>
>> +struct ws_delta {
>> + int deltachars;
>> + char firstchar;
>> +};
>
> I'll just make some overall design comments.
>
> Shouldn't this be a string of characters (or a char
On Tue, 3 Apr 2018 12:51:43 -0400
Derrick Stolee wrote:
> We now calculate generation numbers in the commit-graph file and use
> them in paint_down_to_common().
For completeness, I'll mention that I don't see any issues with this
patch, of course.
Thanks for this series.
On Tue, Apr 03, 2018 at 02:47:27PM -0400, Jeff King wrote:
> On Tue, Apr 03, 2018 at 02:29:01PM -0400, Derrick Stolee wrote:
>
> > If we have generic "can X reach Y?" queries, then we can also use generation
> > numbers there to great effect (by not walking commits Z with gen(Z) <=
> > gen(Y)). P
On Tue, 3 Apr 2018 12:51:42 -0400
Derrick Stolee wrote:
> -static int queue_has_nonstale(struct prio_queue *queue)
> +static int queue_has_nonstale(struct prio_queue *queue, uint32_t min_gen)
> {
> - int i;
> - for (i = 0; i < queue->nr; i++) {
> - struct commit *commit = qu
>>> The fun is in the last patch, which allows white space sensitive
>>> languages to trust the move detection, too. Each block that is marked as
>>> moved will have the same delta in {in-, de-}dentation.
>>> I would think this mode might be a reasonable default eventually.
>>
>> This sounds like a
Hi.
I want to use systemd as fastcgi spawner for gitweb + nginx.
The traffic is low and number of users is limited + traversal bots. For that
reason I've decided to use following mimimal services
gitweb.socket
[Unit]
Description=GitWeb Socket
[Socket]
ListenStream=/run/gitweb.sock
Accept=false
On Mon, Apr 2, 2018 at 4:51 PM, Jonathan Tan wrote:
> On Mon, 2 Apr 2018 15:48:52 -0700
> Stefan Beller wrote:
>
>> At the time the move coloring was implemented we thought an enum of modes
>> is the best to configure this feature. However as we want to tack on new
>> features, the enum would g
On Tue, Apr 3, 2018 at 11:30 AM, Jonathan Tan wrote:
> On Tue, 3 Apr 2018 12:51:40 -0400
> Derrick Stolee wrote:
>
>> + if ((*list)->generation != GENERATION_NUMBER_UNDEF) {
>> + if ((*list)->generation > GENERATION_NUMBER_MAX)
>> + die
On Tue, Apr 03, 2018 at 02:29:01PM -0400, Derrick Stolee wrote:
> If we have generic "can X reach Y?" queries, then we can also use generation
> numbers there to great effect (by not walking commits Z with gen(Z) <=
> gen(Y)). Perhaps I should look at that "git branch --contains" thread for
> idea
On Tue, Apr 3, 2018 at 11:28 AM, Jeff King wrote:
> On Tue, Apr 03, 2018 at 11:05:36AM -0700, Brandon Williams wrote:
>
>> On 04/03, Derrick Stolee wrote:
>> > The generation number of a commit is defined recursively as follows:
>> >
>> > * If a commit A has no parents, then the generation number
>>> +/*
>>> + * For performance reasons, a commit loaded from the graph does not
>>> + * have a tree loaded until trying to consume it for the first time.
>>
>> That is the theme of this series/patch, but do we need to write it down
>> into the codebase? I'd be inclined to omit this part and only g
On 4/3/2018 2:28 PM, Jeff King wrote:
On Tue, Apr 03, 2018 at 11:21:36AM -0700, Jonathan Tan wrote:
On Tue, 3 Apr 2018 12:51:38 -0400
Derrick Stolee wrote:
Most code paths load commits using lookup_commit() and then
parse_commit(). In some cases, including some branch lookups, the commit
On Tue, 3 Apr 2018 12:51:41 -0400
Derrick Stolee wrote:
> +int compare_commits_by_gen_then_commit_date(const void *a_, const void *b_,
> void *unused)
> +{
> + const struct commit *a = a_, *b = b_;
> +
> + if (a->generation < b->generation)
> + return 1;
> + else if (a->
On 04/03, Jeff King wrote:
> On Tue, Apr 03, 2018 at 11:05:36AM -0700, Brandon Williams wrote:
>
> > On 04/03, Derrick Stolee wrote:
> > > The generation number of a commit is defined recursively as follows:
> > >
> > > * If a commit A has no parents, then the generation number of A is one.
> > >
On Tue, Apr 3, 2018 at 9:51 AM, Derrick Stolee wrote:
> Define compare_commits_by_gen_then_commit_date(), which uses generation
> numbers as a primary comparison and commit date to break ties (or as a
> comparison when both commits do not have computed generation numbers).
>
> Since the commit-gra
On 4/3/2018 2:28 PM, Jeff King wrote:
On Tue, Apr 03, 2018 at 11:05:36AM -0700, Brandon Williams wrote:
On 04/03, Derrick Stolee wrote:
The generation number of a commit is defined recursively as follows:
* If a commit A has no parents, then the generation number of A is one.
* If a commit A
On Tue, 3 Apr 2018 12:51:40 -0400
Derrick Stolee wrote:
> + if ((*list)->generation != GENERATION_NUMBER_UNDEF) {
> + if ((*list)->generation > GENERATION_NUMBER_MAX)
> + die("generation number %u is too large to store
> in commit-grap
On 4/3/2018 2:03 PM, Brandon Williams wrote:
On 04/03, Derrick Stolee wrote:
This is the first of several "small" patches that follow the serialized
Git commit graph patch (ds/commit-graph).
As described in Documentation/technical/commit-graph.txt, the generation
number of a commit is one more
On Tue, Apr 03, 2018 at 11:21:36AM -0700, Jonathan Tan wrote:
> On Tue, 3 Apr 2018 12:51:38 -0400
> Derrick Stolee wrote:
>
> > Most code paths load commits using lookup_commit() and then
> > parse_commit(). In some cases, including some branch lookups, the commit
> > is parsed using parse_obje
On Tue, Apr 03, 2018 at 11:05:36AM -0700, Brandon Williams wrote:
> On 04/03, Derrick Stolee wrote:
> > The generation number of a commit is defined recursively as follows:
> >
> > * If a commit A has no parents, then the generation number of A is one.
> > * If a commit A has parents, then the ge
On Tue, 3 Apr 2018 12:51:39 -0400
Derrick Stolee wrote:
> The generation number of a commit is defined recursively as follows:
>
> * If a commit A has no parents, then the generation number of A is one.
> * If a commit A has parents, then the generation number of A is one
> more than the maxi
On 4/3/2018 2:00 PM, Stefan Beller wrote:
On Tue, Apr 3, 2018 at 5:00 AM, Derrick Stolee wrote:
The commit-graph file provides quick access to commit data, including
the OID of the root tree for each commit in the graph. When performing
a deep commit-graph walk, we may not need to load most of
On Tue, 3 Apr 2018 12:51:38 -0400
Derrick Stolee wrote:
> Most code paths load commits using lookup_commit() and then
> parse_commit(). In some cases, including some branch lookups, the commit
> is parsed using parse_object_buffer() which side-steps parse_commit() in
> favor of parse_commit_buff
On 04/03, Derrick Stolee wrote:
> The generation number of a commit is defined recursively as follows:
>
> * If a commit A has no parents, then the generation number of A is one.
> * If a commit A has parents, then the generation number of A is one
> more than the maximum generation number among
On 04/03, Derrick Stolee wrote:
> This is the first of several "small" patches that follow the serialized
> Git commit graph patch (ds/commit-graph).
>
> As described in Documentation/technical/commit-graph.txt, the generation
> number of a commit is one more than the maximum generation number amo
On Tue, Apr 3, 2018 at 5:00 AM, Derrick Stolee wrote:
> The commit-graph file provides quick access to commit data, including
> the OID of the root tree for each commit in the graph. When performing
> a deep commit-graph walk, we may not need to load most of the trees
> for these commits.
>
> Dela
Commit 8894d53580 (commit: allow partial commits with relative paths,
2011-07-30) ensured that partial commits were allowed when a user
supplies a relative pathspec but then this was regressed in 5879f5684c
(remove prefix argument from pathspec_prefix, 2011-09-04) when the
prefix argument to 'paths
Noticed-by: Matthias Rüster
Signed-off-by: Ralf Thielow
---
po/de.po | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po/de.po b/po/de.po
index 793bd2a80..257f527d6 100644
--- a/po/de.po
+++ b/po/de.po
@@ -16991,7 +16991,7 @@ msgstr "Löschung im Arbeitsverzeichnis verwerfen
[
2018-04-02 20:09 GMT+02:00 Matthias Rüster :
> Hi Ralf,
>
> thanks a lot for your translations!
>
> I've only found a small issue:
>
>> #: git-add--interactive.perl:1405
>> -#, fuzzy, perl-format
>> +#, perl-format
>> msgid "Discard this hunk from worktree [y,n,q,a,d%s,?]? "
>> -msgstr "diesen
Thanks for your contributions!
Signed-off-by: Ralf Thielow
---
po/TEAMS | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/po/TEAMS b/po/TEAMS
index 065771cfe..762879550 100644
--- a/po/TEAMS
+++ b/po/TEAMS
@@ -13,12 +13,8 @@ Members: Alex Henrie
Language: de (Ge
On 4/3/2018 12:51 PM, Derrick Stolee wrote:
This is the first of several "small" patches that follow the serialized
Git commit graph patch (ds/commit-graph).
As described in Documentation/technical/commit-graph.txt, the generation
number of a commit is one more than the maximum generation number
The generation number of a commit is defined recursively as follows:
* If a commit A has no parents, then the generation number of A is one.
* If a commit A has parents, then the generation number of A is one
more than the maximum generation number among the parents of A.
Add a uint32_t generat
While preparing commits to be written into a commit-graph file, compute
the generation numbers using a depth-first strategy.
The only commits that are walked in this depth-first search are those
without a precomputed generation number. Thus, computation time will be
relative to the number of new c
Most code paths load commits using lookup_commit() and then
parse_commit(). In some cases, including some branch lookups, the commit
is parsed using parse_object_buffer() which side-steps parse_commit() in
favor of parse_commit_buffer().
Before adding generation numbers to the commit-graph, we nee
Define compare_commits_by_gen_then_commit_date(), which uses generation
numbers as a primary comparison and commit date to break ties (or as a
comparison when both commits do not have computed generation numbers).
Since the commit-graph file is closed under reachability, we know that
all commits i
In paint_down_to_common(), the walk is halted when the queue contains
only stale commits. The queue_has_nonstale() method iterates over the
entire queue looking for a nonstale commit. In a wide commit graph where
the two sides share many commits in common, but have deep sets of
different commits, t
We now calculate generation numbers in the commit-graph file and use
them in paint_down_to_common().
Signed-off-by: Derrick Stolee
---
Documentation/technical/commit-graph.txt | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/Documentation/technical/commit-graph.txt
b/Do
This is the first of several "small" patches that follow the serialized
Git commit graph patch (ds/commit-graph).
As described in Documentation/technical/commit-graph.txt, the generation
number of a commit is one more than the maximum generation number among
its parents (trivially, a commit with n
Hi team,
On Tue, 3 Apr 2018, Johannes Schindelin wrote:
> Johannes Schindelin (15):
> git_config_set: fix off-by-two
> t1300: rename it to reflect that `repo-config` was deprecated
> t1300: demonstrate that --replace-all can "invent" newlines
> config --replace-all: avoid extra line break
It can happen quite easily that the last setting in a config section is
removed, and to avoid confusion when there are comments in the config
about that section, we keep a lone section header, i.e. an empty
section.
Now that we use the `event_fn` callback, it is easy to add support for
re-using em
In the recent commit with the title "config: introduce an optional event
stream while parsing", we introduced an optional callback to keep track
of the config parser's events "comment", "white-space", "section header"
and "entry".
One motivation for this feature was to make use of it in the code t
The `seen` field is the actual length of the `offset` array, and the
`offset_alloc` field records what was allocated (to avoid resizing
wherever `seen` has to be incremented).
Elsewhere, we use the convention `name` for the array, where `name` is
descriptive enough to guess its purpose, `name_nr`
The original reasoning for not removing section headers upon removal of
the last entry went like this: the user could have added comments about
the section, or about the entries therein, and if there were other
comments there, we would not know whether we should remove them.
In particular, a conco
This extends our config parser so that it can optionally produce an event
stream via callback function, where it reports e.g. when a comment was
parsed, or a section header, etc.
This parser will be used subsequently to handle the scenarios better where
removing config entries would make sections
We already have a test demonstrating that removing the last entry from a
config section fails to remove the section header of the now-empty
section.
The same can happen, of course, if we remove the last entries in one fell
swoop. This is *also* a bug, and should be fixed at the same time.
Signed-
It is much easier to reason about, when the config code to set/unset
variables or to remove/rename sections does not rely on a global (or
file-local) variable.
Signed-off-by: Johannes Schindelin
---
config.c | 119 +++
1 file changed, 6
While a neat theoretical construct, state machines are hard to read. In
this instance, it does not even make a whole lot of sense because we are
more interested in flags, anyway: has the section been seen? Has the key
been seen? Does the current section match the key we are looking for?
Besides, t
The test case 'unset with cont. lines' relied on a bug that is about to
be fixed: it tests *explicitly* that removing the last entry from a
config section leaves an *empty* section behind.
Let's fix this test case not to rely on that behavior, simply by
preventing the section from becoming empty.
When replacing multiple config entries at once, we did not re-set the
flag that indicates whether we need to insert a new-line before the new
entry. As a consequence, an extra new-line was inserted under certain
circumstances.
Signed-off-by: Johannes Schindelin
---
config.c | 1 +
t/t13
Signed-off-by: Johannes Schindelin
---
t/t1300-config.sh | 21 +
1 file changed, 21 insertions(+)
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 4f8e6f5fde3..cc417687e8d 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1611,4 +1611,25 @@ test_expect_succes
Signed-off-by: Johannes Schindelin
---
t/{t1300-repo-config.sh => t1300-config.sh} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename t/{t1300-repo-config.sh => t1300-config.sh} (100%)
diff --git a/t/t1300-repo-config.sh b/t/t1300-config.sh
similarity index 100%
rename from t/t1300-rep
In https://public-inbox.org/git/7vvc8alzat@alter.siamese.dyndns.org/
a reasonable patch was made quite a bit less so by changing a test case
demonstrating a bug to a test case that demonstrates that we ask for too
much: the test case 'unsetting the last key in a section removes header'
now expe
This patch series originally only tried to help fixing that annoying bug that
has been reported several times over the years, where `git config --unset`
would leave empty sections behind, and `git config --add` would not reuse them.
The first patch is somewhat of a "while at it" bug fix that I fir
Currently, we are slightly overzealous When removing an entry from a
config file of this form:
[abc]a
[xyz]
key = value
When calling `git config --unset abc.a` on this file, it leaves this
(invalid) config behind:
[
[xyz]
key = valu
Hi Peff,
On Tue, 3 Apr 2018, Jeff King wrote:
> On Tue, Apr 03, 2018 at 01:43:10PM +0200, Johannes Schindelin wrote:
>
> > > I don't have time or interest to work on this now, but thought it was
> > > interesting to share. This assumes that something in shellscript like:
> > >
> > > while e
Hi Ævar,
On Tue, 3 Apr 2018, Ævar Arnfjörð Bjarmason wrote:
> [...] I think it would be really interesting to see the third
> approach I suggested, i.e. hack the shell to make the test_cmp a builtin
> and test that. Then you won't fork, but will get the advantage of your
> fast C codepath.
That
Hi Duy,
On Tue, 3 Apr 2018, Duy Nguyen wrote:
> On Tue, Apr 3, 2018 at 11:31 AM, Johannes Schindelin
> wrote:
> > It is very frustrating to spend that much time with only little gains
> > here and there (and BusyBox-w32 is simply not robust enough yet, apart
> > from also not showing a significa
On Tue, Apr 3, 2018 at 11:31 AM, Johannes Schindelin
wrote:
> It is very frustrating to spend that much time with only little gains here
> and there (and BusyBox-w32 is simply not robust enough yet, apart from
> also not showing a significant improvement in performance).
You still use busybox-w32
On Tue, Apr 3, 2018 at 11:25 AM, Eric Sunshine wrote:
> Following a rename of worktree "source" to "destination", the "move
> worktree" test uses grep to verify that the output of "git worktree list
> --porcelain" does not contain "source" (and does contain "destination").
> Unfortunately, the gre
On Tue, Apr 03, 2018 at 11:19:46AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Mar 31 2018, Duy Nguyen wrote:
>
> > On Sat, Mar 31, 2018 at 6:40 PM, Ævar Arnfjörð Bjarmason
> > wrote:
> >> Change the DEVELOPER flag, and the newly added EAGER_DEVELOPER flag
> >> which (approximately) enable
From: Eric Sunshine
"git branch --list" shows an in-progress rebase as:
* (no branch, rebasing )
master
...
However, if the rebase is started from a detached HEAD, then there is no
, and it would attempt to print a NULL pointer. The previous
commit fixed this problem, so add a test to
Hi Luciano,
On Sat, 31 Mar 2018, Luciano Joublanc wrote:
> I've cloned the `maint` branch, built the project, and added the test
> as you suggested - it's failing as expected.
Excellent.
> On 30 March 2018 at 11:20, Johannes Schindelin
> wrote:
> >
> > However, this would be incorrect, as th
It's possible to have libcurl installed but not the curl
command-line utility. The latter is not generally needed for
Git's http support, but we use it in t5561 for basic tests
of http-backend's functionality. Let's detect when it's
missing and skip this test.
Note that we can't mark the individua
For a normal test run, stderr is already redirected to
/dev/null by the test suite. When used with "-v",
suppressing stderr is actively harmful, as it may hide the
reason for curl failing.
Reported-by: Jens Krüger
Signed-off-by: Jeff King
---
t/t5561-http-backend.sh | 4 ++--
1 file changed, 2
On Tue, Apr 03, 2018 at 09:14:47AM -0400, Jeff King wrote:
> As far as code changes in Git, perhaps (assuming my guess is right):
>
> - drop the redirect of stderr here; the test suite already handles
> hiding stderr from the user (without "-v"), and in "-v" mode you
> probably would ha
On 4/3/2018 7:39 AM, Derrick Stolee wrote:
On 4/3/2018 6:18 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Apr 03 2018, Lars Schneider wrote:
What is the state of this series? I can't find it in git/git nor in
git-for-windows/git. I think Stolee mentioned the config in
his Git Merge talk [1] and
Am 03.04.2018 um 15:14 schrieb Jeff King:
On Tue, Apr 03, 2018 at 01:43:37PM +0200, Jens Krüger wrote:
expecting success: GET refs/heads/master "404 Not Found" not ok 2 -
direct refs/heads/master not found
That GET function is:
GET() {
curl --include "$HTTPD_URL/$SMART/repo.gi
On Tue, Apr 03, 2018 at 01:43:10PM +0200, Johannes Schindelin wrote:
> > I don't have time or interest to work on this now, but thought it was
> > interesting to share. This assumes that something in shellscript like:
> >
> > while echo foo; do echo bar; done
> >
> > Is no slower on Windows
On Tue, Apr 03, 2018 at 01:43:37PM +0200, Jens Krüger wrote:
> expecting success:
> GET refs/heads/master "404 Not Found"
>
> not ok 2 - direct refs/heads/master not found
That GET function is:
GET() {
curl --include "$HTTPD_URL/$SMART/repo.git/$1" >out 2>/dev/null &&
t
On 4/3/2018 9:06 AM, Jeff King wrote:
On Tue, Apr 03, 2018 at 08:00:54AM -0400, Derrick Stolee wrote:
There are several commit-graph walks that require loading many commits
but never walk the trees reachable from those commits. However, the
current logic in parse_commit() requires the root tree
Hi Junio,
On Fri, 30 Mar 2018, Junio C Hamano wrote:
> * js/runtime-prefix-windows (2018-03-27) 2 commits
> - mingw/msvc: use the new-style RUNTIME_PREFIX helper
> - exec_cmd: provide a new-style RUNTIME_PREFIX helper for Windows
> (this branch uses dj/runtime-prefix.)
>
> The Windows port w
On Tue, Apr 03, 2018 at 08:00:54AM -0400, Derrick Stolee wrote:
> There are several commit-graph walks that require loading many commits
> but never walk the trees reachable from those commits. However, the
> current logic in parse_commit() requires the root tree to be loaded.
> This only uses loo
On Tuesday 03 April 2018 01:30 PM, Eric Sunshine wrote:
>> Note that the "detached HEAD" test case might actually fail in some cases
>> as the actual output of "git branch --list" might contain remote branch
>> names which is not considered by the test case as it is rare to happen
>> in the test en
Dear Git users,
It is my pleasure to announce that Git for Windows 2.17.0 is available from:
https://gitforwindows.org/
Changes since Git for Windows v2.16.3 (March 23rd 2018)
New Features
* Comes with Git v2.17.0.
* Comes with OpenSSL v1.0.2o.
* Comes with Git Credential Manager
On 4/3/2018 8:00 AM, Derrick Stolee wrote:
There are several commit-graph walks that require loading many commits
but never walk the trees reachable from those commits. However, the
current logic in parse_commit() requires the root tree to be loaded.
This only uses lookup_tree(), but when reading
The commit-graph file provides quick access to commit data, including
the OID of the root tree for each commit in the graph. When performing
a deep commit-graph walk, we may not need to load most of the trees
for these commits.
Delay loading the tree object for a commit loaded from the graph
until
While walking the commit graph, we load struct commit objects into
the object cache. During this process, we also load struct tree
objects for the root tree of each of these commits. We load these
objects even if we are only computing commit reachability information,
such as a merge base or ahead/b
Replace all direct accesses of the 'tree' member in 'struct commit'
with calls to get_commit_tree() or get_commit_tree_oid().
This patch was constructed starting with the following Coccinelle
script, then removing false-positives:
@@
expression c;
@@
- &c->tree->object.oid
+ get_commit_tree_oid(c
1 - 100 of 123 matches
Mail list logo