On Tue, Apr 3, 2018 at 12:31 AM, Kaartic Sivaraam
wrote:
> 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 pri
The actual2 file does not exists, if I call the ./t2028-worktree-move.sh
with the '-v -i' options, only without any option or with '-v' option.
Am 03.04.2018 um 08:58 schrieb Eric Sunshine:
On Tue, Apr 3, 2018 at 2:33 AM, Jens Krüger wrote:
*** t2028-worktree-move.sh ***
not ok 12 - move workt
On Tue, Apr 3, 2018 at 4:01 AM, Jens Krüger wrote:
> The actual2 file does not exists, if I call the ./t2028-worktree-move.sh
> with the '-v -i' options, only without any option or with '-v' option.
The content of the various files looks correct, and absence of
"actual2" implies that one of the g
> On 02 Apr 2018, at 20:31, Lars Schneider wrote:
>
>
>> On 29 Mar 2018, at 20:37, Junio C Hamano wrote:
>>
>> lars.schnei...@autodesk.com writes:
>>
>>> From: Lars Schneider
>>>
>>> Patches 1-6,9 are preparation and helper functions. Patch 4 is new.
>>> Patch 7,8,10 are the actual change.
Am 03.04.2018 um 10:16 schrieb Eric Sunshine:
On Tue, Apr 3, 2018 at 4:01 AM, Jens Krüger wrote:
The actual2 file does not exists, if I call the ./t2028-worktree-move.sh
with the '-v -i' options, only without any option or with '-v' option.
The content of the various files looks correct, and
Am 03.04.2018 um 10:16 schrieb Eric Sunshine:
On Tue, Apr 3, 2018 at 4:01 AM, Jens Krüger wrote:
The actual2 file does not exists, if I call the ./t2028-worktree-move.sh
with the '-v -i' options, only without any option or with '-v' option.
The content of the various files looks correct, and
On Tue, Apr 3, 2018 at 4:38 AM, Jens Krüger wrote:
> Am 03.04.2018 um 10:16 schrieb Eric Sunshine:
>> Using the "out" file you attached, can you show the output of these
>> commands?
>> grep "^worktree.*/destination" out
>> echo $?
>> grep "^worktree.*/source" out
>> echo $?
>>
On Tue, Apr 3, 2018 at 4:42 AM, Jens Krüger wrote:
> Maybe, the attached patch may help. On my machine(s) it helped.
> git worktree list --porcelain >out &&
> grep "^worktree.*/destination" out &&
> - ! grep "^worktree.*/source" out &&
> + ! grep "^worktree.*/source$" out &&
Our emails crosse
Am 03.04.2018 um 10:47 schrieb Eric Sunshine:
On Tue, Apr 3, 2018 at 4:42 AM, Jens Krüger wrote:
Maybe, the attached patch may help. On my machine(s) it helped.
git worktree list --porcelain >out &&
grep "^worktree.*/destination" out &&
- ! grep "^worktree.*/source" out &&
+ ! grep "^work
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) enables -Wextra so that any combination of them
>> and -Werror can be set.
>>
>> I've long wa
Commit 20d2a30f (Makefile: replace perl/Makefile.PL with simple make rules)
removed a target that allowed Makefiles from contrib/ to get the correct
install path. This introduces a new target for main Makefile and fixes
installation for Mediawiki module.
Signed-off-by: Christian Hesse
---
Makefi
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 grep expression is too loose and can match
unexpectedly. For examp
Hi Junio,
On Fri, 30 Mar 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > What would be a *really* good strategy is: "Oh, there is a problem! Let's
> > acknowledge it and try to come up with a solution rather than a
> > work-around".
> >
> > EXPENSIVE_ON_WINDOWS is a symptom. Not
Hi Peff,
On Fri, 30 Mar 2018, Jeff King wrote:
> On Fri, Mar 30, 2018 at 08:45:45PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > I've wondered for a while whether it wouldn't be a viable approach to
> > make something like an interpreter for our test suite to get around
> > this problem, i.e. muc
> On 04 Jan 2018, at 20:26, Jeff King wrote:
>
> On Wed, Dec 27, 2017 at 09:41:30AM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>>> I, too, had a funny feeling about calling this "core". But I didn't have
>>> a better name, as I'm not sure what other place we have for config
>>> op
On Tue, Apr 03 2018, Lars Schneider wrote:
>> On 04 Jan 2018, at 20:26, Jeff King wrote:
>>
>> On Wed, Dec 27, 2017 at 09:41:30AM -0800, Junio C Hamano wrote:
>>
>>> Jeff King writes:
>>>
I, too, had a funny feeling about calling this "core". But I didn't have
a better name, as I'm no
On Tue, Apr 03 2018, Christian Hesse wrote:
> Commit 20d2a30f (Makefile: replace perl/Makefile.PL with simple make rules)
> removed a target that allowed Makefiles from contrib/ to get the correct
> install path. This introduces a new target for main Makefile and fixes
> installation for Mediawik
On Tue, Apr 03 2018, Johannes Schindelin wrote:
> Hi Peff,
>
> On Fri, 30 Mar 2018, Jeff King wrote:
>
>> On Fri, Mar 30, 2018 at 08:45:45PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> > I've wondered for a while whether it wouldn't be a viable approach to
>> > make something like an interpreter
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 I was about to test it/roll it out :-)
It's i
Hi Ævar,
On Fri, 30 Mar 2018, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Mar 30 2018, Johannes Schindelin wrote [expressing frustrations
> about Windows test suite slowness]:
To be precise (and I think it is important to be precise here): it is not
the Windows test suite about which I talked, it i
Git version 2.17.0
OS: Debian 9 (9.4)
gcc: gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
build from github clone:
autoreconf
./configure
make
make test
*** t5561-http-backend.sh ***
ok 1 - setup repository
not ok 2 - direct refs/heads/master not found
#
# GET refs/heads/master "40
On 4/2/2018 5:33 PM, Junio C Hamano wrote:
Derrick Stolee writes:
From: Derrick Stolee
...
+static int graph_read(int argc, const char **argv)
+{
+ struct commit_graph *graph = 0;
The previous round said NULL above, not 0, and NULL is the better
way to spell it, I would think.
Sorry
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 commits from the commit-
graph file, the has
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
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
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
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
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 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
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
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 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
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 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
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 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
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
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
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
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
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
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
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 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
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
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 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
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
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
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
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.
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
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
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
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 `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`
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
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
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
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
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
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
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
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
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
[
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
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
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 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 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 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: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 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, 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 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, 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: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, 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 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 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
>>> +/*
>>> + * 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 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
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: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 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
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
>>> 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
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
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: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.
1 - 100 of 123 matches
Mail list logo