he 'osx-gcc' job fails when it tries
to link gcc@8:
+ brew link gcc@8
Error: No such keg: /usr/local/Cellar/gcc@8
Apparently 'brew link gcc' works, so let's do that then, and fall back
to linking gcc@8 if it doesn't.
Signed-off-by: SZEDER Gábor
---
ci/install-
On Wed, Oct 23, 2019 at 01:01:00PM +0900, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> >> - b9317d55a3 added two new keys to the trie: 'logs/refs/rewritten'
> >> and 'logs/refs/worktree', next to the already existing
> >> '
git reflog expire --expire-unreachable=now --all
# Now write a commit-graph from that pack file
$ git commit-graph write
Computing commit graph generation numbers: 100% (2/2), done.
It added two commits to the commit-graph, although one of them is
clearly not reachable anymore, so markin
r of a git command. (I used the word "desired" here, because
you just used the word "expect" above in the sense that "I expect it
to fail, because I know it's buggy, and I want to demonstrate that
bug")
> Helped-by: Jeff King
> Helped-by: Johannes Schindelin
On Wed, Oct 23, 2019 at 07:22:12AM +, Aleksey Mikhaylov wrote:
> "Could not access submodule" error when pulling recursively with Git 2.22.0.
> This issue causes if there is submodule in submodule.
> Please use my simple test repository to reproduce the problem:
> https://github.com/agmikhailo
On Wed, Oct 23, 2019 at 01:23:25AM +0200, Johannes Schindelin wrote:
> On Fri, 18 Oct 2019, SZEDER Gábor wrote:
>
> > On Thu, Oct 17, 2019 at 12:47:33PM +, Johannes Schindelin via
> > GitGitGadget wrote:
> > > From: Johannes Schindelin
> > >
> > &g
modules?
$ cd ~/src/git/
$ git quotelog 86cfd61e6b
86cfd61e6b (sha1dc: optionally use sha1collisiondetection as a submodule,
2017-07-01)
$ git init --bare good.git
Initialized empty Git repository in /home/szeder/src/git/good.git/
$ git push -q good.git 86cfd61e6b^:refs/heads/master
$ gi
On Mon, Oct 21, 2019 at 09:54:42PM +, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> Ever since worktrees were introduced, the `git_path()` function _really_
> needed to be called e.g. to get at the path to `logs/HEAD` (`HEAD` is
> specific to the worktree, and t
On Mon, Oct 21, 2019 at 06:00:43PM +0200, SZEDER Gábor wrote:
> 'logs/refs' is not a working tree-specific path, but since commit
> b9317d55a3 (Make sure refs/rewritten/ is per-worktree, 2019-03-07)
> 'git rev-parse --git-path' has been returning a bogus path i
#x27;s value in all entries as
well.
The diff is best viewed with '--color-words'.
Signed-off-by: SZEDER Gábor
---
path.c | 66 +-
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/path.c b/path.c
index 3fac5f5
--git-path logs/refs/
/home/szeder/src/git/.git/logs/refs
/home/szeder/src/git/.git/worktrees/WT/logs/refs/
We use a trie data structure to efficiently decide whether a path
belongs to the common dir or is working tree-specific. As it happens
b9317d55a3 triggered a bug that is as old as
only
function that looks at the 'is_dir' bit, and that function either
returns 0, or '!exclude', which for 'logs/HEAD' results in 0 as well.
Signed-off-by: SZEDER Gábor
---
path.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/path.c b/path.
On Fri, Oct 18, 2019 at 01:35:57PM +0200, SZEDER Gábor wrote:
> > unfortunately, see two more bugs,
And there are documentation bugs as well, both user-visible (i.e. in
a man page) and in in-code comment.
> > and one of them is a "proper" bug leading to bogus
> > o
es correspond 100% to the current implementation, because the
implementation is a bit buggy, but the comment describes the desired
behavior. The bug will be fixed in the last patch of this series.
Signed-off-by: SZEDER Gábor
---
path.c | 45 -
y-layout'. Document them as well.
Signed-off-by: SZEDER Gábor
---
Documentation/gitrepository-layout.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitrepository-layout.txt
b/Documentation/gitrepository-layout.txt
index d6388f10bb..1a2ef4c
an int anyway.
[1] start_progress() expects the total number as an uint64_t, that's
why I chose the same type when declaring the variable holding the
value given on the command line.
Signed-off-by: SZEDER Gábor
---
t/helper/test-progress.c | 2 +-
1 file changed, 1 insertion(+),
On Fri, Oct 18, 2019 at 03:10:21PM -0700, Denton Liu wrote:
> Currently, in the case where we are using test_cmp_rev() to report
> not-equals, we write `! test_cmp_rev`. However, since test_cmp_rev()
> contains
>
> r1=$(git rev-parse --verify "$1") &&
> r2=$(git rev-parse --verify "$2"
On Fri, Oct 18, 2019 at 10:24:21PM +0200, SZEDER Gábor wrote:
> On Tue, Oct 15, 2019 at 01:56:02PM +, Derrick Stolee via GitGitGadget
> wrote:
> > From: Derrick Stolee
> >
> > The sparse-checkout builtin used 'git read-tree -mu HEAD' to update the
> >
does. In
> addition, provide an in-memory list of patterns so we can avoid
> reading from the sparse-checkout file. This allows us to test a
> proposed change to the file before writing to it.
Starting with this patch there is an issue with locking the index:
$ git init
Initializ
On Fri, May 17, 2019 at 12:07:02PM -0700, Emily Shaffer wrote:
> +=== Adding a New Command
> +
> +Lots of the subcommands are written as builtins, which means they are
> +implemented in C and compiled into the main `git` executable. Implementing
> the
> +very simple `psuh` command as a built-in wi
On Tue, Oct 15, 2019 at 01:55:53PM +, Derrick Stolee via GitGitGadget wrote:
> diff --git a/builtin/sparse-checkout.c b/builtin/sparse-checkout.c
> index b747b78d34..78a80ce119 100644
> --- a/builtin/sparse-checkout.c
> +++ b/builtin/sparse-checkout.c
> @@ -8,7 +8,7 @@
> #include "strbuf.h"
>
On Tue, Oct 15, 2019 at 01:55:48PM +, Derrick Stolee via GitGitGadget wrote:
> 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 edi
On Tue, Oct 15, 2019 at 01:55:56PM +, Derrick Stolee via GitGitGadget wrote:
> Running 'git read-tree -mu HEAD' on this file had the following
> performance:
>
> core.sparseCheckout=false: 0.21 s (0.00 s)
>core.sparseCheckout=true: 3.75 s (3.50 s)
>core.sparseCheckout=con
On Tue, Oct 15, 2019 at 11:47:53PM +, James Coglan via GitGitGadget wrote:
> diff --git a/t/t4215-log-skewed-merges.sh b/t/t4215-log-skewed-merges.sh
> new file mode 100755
> index 00..4582ba066a
> --- /dev/null
> +++ b/t/t4215-log-skewed-merges.sh
> @@ -0,0 +1,43 @@
> +#!/bin/sh
> +
>
On Thu, Oct 17, 2019 at 02:08:12PM -0400, Eric Sunshine wrote:
> On Thu, Oct 17, 2019 at 1:35 PM SZEDER Gábor wrote:
> > Complete the paths of existing working trees for 'git worktree's
> > 'move', 'remove', 'lock', and 'unlock'
On Thu, Oct 17, 2019 at 01:52:27PM -0400, Eric Sunshine wrote:
> > __git_find_on_cmdline ()
> > {
> > - local word c=1
> > + local word c=1 show_idx
> > +
> > + while test $# -gt 1; do
> > + case "$1" in
> > + --show-idx) show_idx=y ;;
> > +
On Fri, Oct 18, 2019 at 10:23:00AM +0900, Junio C Hamano wrote:
> > diff --git a/path.c b/path.c
> > index e3da1f3c4e..ff85692b45 100644
> > --- a/path.c
> > +++ b/path.c
> > @@ -268,7 +268,7 @@ static int trie_find(struct trie *root, const char
> > *key, match_fn fn,
> > int result;
> > s
On Fri, Oct 18, 2019 at 01:06:18PM +0200, SZEDER Gábor wrote:
> I didn't look yesterday at all, but now I did, and, unfortunately, see
> two more bugs
The second patch is kind of a bugfix, though luckily the bug doesn't
actually manifest in undesired behavior.
The first is a m
only
function that looks at the 'is_dir' bit, and that function either
returns 0, or '!exclude', which for 'logs/HEAD' results in 0 as well.
Signed-off-by: SZEDER Gábor
---
path.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/path.c b/path.
r file, e.g.
'gc.pid'.
Rename this 'dirname' field to 'path' to avoid future confusion.
Signed-off-by: SZEDER Gábor
---
path.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/path.c b/path.c
index e3da1f3c4e..eeb43e1d25 10064
On Fri, Oct 18, 2019 at 01:06:18PM +0200, SZEDER Gábor wrote:
> > > On a related note, I'm not sure whether the path of the reflogs
> > > directory is right while in a different working tree... Both with and
> > > without this patch I get a path p
is right while in a different working tree... Both with and
> > without this patch I get a path pointing to the main working tree:
> >
> > $ ./git -C WT/ rev-parse --git-path logs
> > /home/szeder/src/git/.git/logs
> >
> > However, I'm not sure what the
On Thu, Oct 17, 2019 at 12:47:33PM +, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> The CI builds are failing for Mac OS X due to a change in the
s/CI/Azure Pipelines/
Our Travis CI builds are fine.
> location of the perforce cask. The command outputs the fol
h: refactor searching for subcommands on the
command line, 2008-03-10),
[2] 918c03c2a7 (bash: rename __git_find_subcommand() to
__git_find_on_cmdline(), 2009-09-15)
Signed-off-by: SZEDER Gábor
---
contrib/completion/git-completion.bash | 13 -
1 file changed, 8 insertions(+), 5 d
The following two patches will refactor and extend the
__git_find_on_cmdline() helper function, so let's add a few tests
first to make sure that its basic behavior doesn't change.
Signed-off-by: SZEDER Gábor
---
t/t9902-completion.sh | 28
1 file c
completing --options
via parse-options, and after the preparatory steps in this series).
[1]
https://public-inbox.org/git/1440190256-21794-1-git-send-email-sze...@ira.uka.de/
SZEDER Gábor (6):
t9902-completion: add tests for the __git_find_on_cmdline() helper
completion: clean up the __git_fin
x27; option, but that is consistent with our general stance on
not offering '--force', as it should be used with care.
Signed-off-by: SZEDER Gábor
---
contrib/completion/git-completion.bash | 30 +++---
1 file changed, 8 insertions(+), 22 deletions(-)
diff --gi
of that word on the command line as well.
Extend __git_find_on_cmdline() to optionally show the index of the
found word on the command line (IOW in the $words array) when the
'--show-idx' option is given.
Signed-off-by: SZEDER Gábor
---
contrib/completion/git-completion.bash |
e path of the main working tree, as it cannot be moved,
removed, locked, or unlocked.
Arguably 'git worktree unlock ' should only complete locked
working trees, but 'git worktree list --porcelain' doesn't indicate
which working trees are locked. So for now it will complet
ill make it not too hard to
digest.
Signed-off-by: SZEDER Gábor
---
contrib/completion/git-completion.bash | 36 ++
1 file changed, 36 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 4eb13b06d6..4e5cad4966 1
On Thu, Oct 17, 2019 at 12:28:25PM -0400, Peter Jones wrote:
> Currently if you do, for example:
>
> $ git worktree add path foo
>
> And "foo" has already been checked out at some other path, but the user
> has removed it without pruning, you'll get an error that the branch is
> already checked o
On Wed, Oct 16, 2019 at 01:45:15PM +0100, Philip Oakley wrote:
> Signed-off-by: Philip Oakley
> ---
>
> While tring to get to grips with some Git-for-Windows config settings
> for testing >4GiB files, I couldn't find any note in the readme about
> the test system config file sources.
The path o
;$(pwd)/.git/worktrees/wt/logs/HEAD.lock" \
> + "$(pwd)/.git/worktrees/wt/index" \
> + "$(pwd)/.git/worktrees/wt/index.lock" &&
> + git -C wt rev-parse >actual \
> + --git-path logs/HEAD --git-path logs/HEAD.lock \
&
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
> > >
+# ~/.zsh/ directory as ~/.zsh/git-completion.zsh and then add the following
These updated instructions don't work for me, following them gives me
zsh's git completion instead of ours:
$ ls -l /etc/bash_completion.d/git
-rwxr-xr-x 1 root root 72165 Oct 15 01:27 /etc/bash_comp
On Thu, Oct 10, 2019 at 08:19:32AM -0700, Emily Shaffer wrote:
> diff --git a/Documentation/MyFirstObjectWalk.txt
> b/Documentation/MyFirstObjectWalk.txt
> new file mode 100644
> index 00..7085f17072
> --- /dev/null
> +++ b/Documentation/MyFirstObjectWalk.txt
> @@ -0,0 +1,905 @@
> +My Firs
On Fri, Oct 11, 2019 at 05:47:44PM +0200, Bert Wesarg wrote:
> > > > +test_expect_success 'format-patch -o with no leading directories' '
> > > > + rm -fr patches &&
> > > > + git format-patch -o patches master..side &&
> > > > + count=$(git rev-list --count master..side) &&
> > > > +
On Fri, Oct 11, 2019 at 10:36:41AM +0200, Bert Wesarg wrote:
> Changes in v4:
> * based on dl/format-patch-doc-test-cleanup and adopt it
Thanks... but here I am nitpicking again, sorry :)
> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
> index 72b09896cf..9facc3a79e 100755
> --
On Thu, Oct 10, 2019 at 01:07:32PM +0200, SZEDER Gábor wrote:
> On Wed, Oct 09, 2019 at 02:00:12PM -0700, William Baker via GitGitGadget
> wrote:
> > diff --git a/t/t7519-status-fsmonitor.sh b/t/t7519-status-fsmonitor.sh
> > index 81a375fa0f..87042470ab 100755
> &
On Wed, Oct 09, 2019 at 02:00:12PM -0700, William Baker via GitGitGadget wrote:
> diff --git a/t/t7519-status-fsmonitor.sh b/t/t7519-status-fsmonitor.sh
> index 81a375fa0f..87042470ab 100755
> --- a/t/t7519-status-fsmonitor.sh
> +++ b/t/t7519-status-fsmonitor.sh
> @@ -354,4 +354,17 @@ test_expect_s
On Fri, Sep 27, 2019 at 06:18:58PM -0400, Jeff King wrote:
> On Thu, Sep 26, 2019 at 11:44:48PM +0200, SZEDER Gábor wrote:
>
> > All that was over a year and a half ago, and these limitations weren't
> > a maintenance burden at all so far, and nobody needed that escape
>
On Wed, Oct 09, 2019 at 09:13:56AM +0300, Uwe Brauer wrote:
> Could you please try out
> git clone https://git.code.sf.net/p/matlab-emacs/src matlab-emacs-hg
This repository contains two branches: 'master' and 'strings'. From
these two 'master' is the default branch, so that is that 'git clone'
On Tue, Oct 08, 2019 at 09:49:35AM +0200, Toon Claes wrote:
> Add support to provide the Co-author when committing. For each
> co-author provided with --coauthor=, a line is added at the
> bottom of the commit message, like this:
>
> Co-authored-by:
>
> It's a common practice use when pairin
On Tue, Oct 08, 2019 at 09:36:26PM +0200, Johannes Schindelin wrote:
> I missed a well-ACKed contribution in here: the code of conduct Peff
> kindly submitted, with the add-on that clarifies who is in that group of
> potential mediators. See
>
> https://public-inbox.org/git/20190924064454.ga30...@
On Tue, Oct 08, 2019 at 01:30:34PM +0900, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> >>func(PROGRESS | REGRESS);
> >>func(PROGRESS + REGRESS);
> >>func(PROGRESS * 3);
> >>}
> >>
> >> ho
On Tue, Oct 08, 2019 at 09:24:56AM -0700, William Baker wrote:
> On 10/7/19 9:30 PM, Junio C Hamano wrote:
> > SZEDER Gábor writes:
> >
> >>> func(PROGRESS | REGRESS);
> >>> func(PROGRESS + REGRESS);
> >>> func(P
On Tue, Sep 24, 2019 at 12:22:27PM +0200, Uwe Brauer wrote:
> I am confused, I just pulled
> but git log --graph --decorate
> did not show all commits,
>
> Only
>
> git log --graph --decorate --all
>
> and from the emails I received the commits shown by --all
>
> Should be on a new branch.
On Fri, Sep 27, 2019 at 02:02:01PM +0200, SZEDER Gábor wrote:
> On Fri, Sep 27, 2019 at 11:51:07AM +0200, Anders Janmyr wrote:
> > I'm not sure if this is a bug or not but `git describe` gives
> > different results when the repo has been cloned with `--depth` or not.
> >
On Sat, Oct 05, 2019 at 10:43:51AM +0200, Bert Wesarg wrote:
> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
> index 83f52614d3..2f2cd6fea6 100755
> --- a/t/t4014-format-patch.sh
> +++ b/t/t4014-format-patch.sh
> @@ -1606,6 +1606,26 @@ test_expect_success 'From line has expected fo
On Tue, Oct 01, 2019 at 04:16:26AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
Good idea, now that 'make hdr-check' runs clean this will help to keep
it that way.
I think adding it to the static analysis job makes sense, as opposed
to the additional VM startup
t want empty pathspecs to remove
> untracked directories by default).
>
> Denton found and analyzed one issue and provided the patch for the
> match_pathspec() call, SZEDER figured out why the issue only reproduced
> for some folks and not others and provided the testcase, and I looke
On Sat, Sep 28, 2019 at 12:40:52PM +0900, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > On Fri, Sep 20, 2019 at 09:53:48AM -0700, William Baker via GitGitGadget
> > wrote:
> >> diff --git a/midx.h b/midx.h
> >> index f0ae656b5d..e6fa356b5c 100644
On Wed, Oct 02, 2019 at 02:43:48PM +0900, Junio C Hamano wrote:
> William Baker writes:
>
> > Although my debugger might not be the smartest, I haven't noticed any
> > downsides to switching this to an enum.
>
> Well, if you write
>
> enum { BIT_0 = 1, BIT_1 = 2, BIT_3 = 4 } var;
>
> it'
On Mon, Oct 07, 2019 at 07:14:25PM +0400, Semyon Kirnosenko wrote:
> I have a question about log command.
> Probably I'm just missing something but anyway.
> I can illustrate the question on the repository of Git.
> Let's look at revision 1ed91937
> It is a merge based on pair of revisions a9572072
On Fri, Sep 27, 2019 at 11:51:07AM +0200, Anders Janmyr wrote:
> Hi,
>
> I'm not sure if this is a bug or not but `git describe` gives
> different results when the repo has been cloned with `--depth` or not.
>
> In the example below from the git repository the number of additional
> commits since
On Fri, Sep 27, 2019 at 03:09:30AM +0200, SZEDER Gábor wrote:
> On Wed, Sep 25, 2019 at 01:39:19PM -0700, Denton Liu wrote:
> > Hi Elijah,
> >
> > I ran into a segfault on MacOS. I managed to bisect it down to
> > 404ebceda0 (dir: also check directories for matchin
On Wed, Sep 25, 2019 at 01:39:19PM -0700, Denton Liu wrote:
> Hi Elijah,
>
> I ran into a segfault on MacOS. I managed to bisect it down to
> 404ebceda0 (dir: also check directories for matching pathspecs,
> 2019-09-17), which should be the patch in the parent thread. The test
> case below works f
On Thu, Sep 26, 2019 at 09:32:35PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 26 Sep 2019, SZEDER Gábor wrote:
>
> > On Mon, Sep 23, 2019 at 08:07:09PM +0200, SZEDER Gábor wrote:
> > > Here is one more idea for microprojects:
> > >
> > > F
On Thu, Sep 26, 2019 at 09:39:58PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 26 Sep 2019, SZEDER Gábor wrote:
>
> > On Thu, Sep 26, 2019 at 01:04:48PM +0200, Johannes Schindelin wrote:
> > > > > > > Also, things like the code
On Tue, Sep 24, 2019 at 07:03:50PM +0200, René Scharfe wrote:
> Am 23.09.19 um 22:47 schrieb SZEDER Gábor:
> > On Mon, Sep 23, 2019 at 09:55:11PM +0200, René Scharfe wrote:
> >> -- >8 --
> >> Subject: [PATCH] name-rev: use FLEX_ARRAY for tip_name in struct rev_name
&g
On Thu, Sep 26, 2019 at 09:36:44AM -0400, Derrick Stolee wrote:
> On 9/26/2019 9:22 AM, Johannes Schindelin wrote:
> > Hi Peff,
> >
> > On Mon, 23 Sep 2019, Jeff King wrote:
> >
> >> On Thu, Sep 19, 2019 at 10:48:30PM +0200, René Scharfe wrote:
> >>
> >>> Use the macro COPY_ARRAY to copy array el
On Thu, Sep 26, 2019 at 01:04:48PM +0200, Johannes Schindelin wrote:
> > > > > Also, things like the code tracing via `-x` (which relies on Bash
> > > > > functionality in order to work properly,
> > > >
> > > > Not really.
> > >
> > > To work properly. What I meant was the trick we need to play wi
On Mon, Sep 23, 2019 at 08:07:09PM +0200, SZEDER Gábor wrote:
> Here is one more idea for microprojects:
>
> Find a group of related preprocessor constants and turn them into an
> enum. Also find where those constants are stored in variables and
> in structs and passed aro
On Tue, Sep 24, 2019 at 02:44:54AM -0400, Jeff King wrote:
> We've never had a formally written Code of Conduct document. Though it
> has been discussed off and on over the years, for the most part the
> behavior on the mailing list has been good enough that nobody felt the
> need to push one forwa
stamp with
unsigned committer dates in name_rev(). IOW, this underflow bug is as
old as 'git name-rev' itself.
Helped-by: Johannes Sixt
Signed-off-by: SZEDER Gábor
---
Range-diff:
1: 3bef6bdf7b ! 1: b053181af9 name-rev: avoid cutoff timestamp underflow
@@ Commit message
fa
On Mon, Sep 23, 2019 at 09:16:26PM +0200, Johannes Sixt wrote:
> Am 23.09.19 um 10:37 schrieb SZEDER Gábor:
> > On Sun, Sep 22, 2019 at 11:01:26PM +0200, Johannes Sixt wrote:
> >> Huh? For signed cutoff and positive CUTOFF_DATE_SLOP,
> >> cutoff - CUTOFF_DATE_SLOP <
On Mon, Sep 23, 2019 at 09:55:11PM +0200, René Scharfe wrote:
> -- >8 --
> Subject: [PATCH] name-rev: use FLEX_ARRAY for tip_name in struct rev_name
>
> Give each rev_name its very own tip_name string. This simplifies memory
> ownership, as callers of name_rev() only have to make sure the tip_nam
On Mon, Sep 23, 2019 at 08:43:11PM +0200, René Scharfe wrote:
> > It's overall memory usage, the avarage of five runs of:
> >
> > /usr/bin/time --format='%M' ~/src/git/git name-rev --all
> >
> >> And how much is that in absolute terms?
> >
> > git: 29801 -> 28514
> > linux: 317018 -> 332218
On Mon, Sep 23, 2019 at 01:18:39PM -0400, Jeffrey Walton wrote:
> (A) core.sshCommand:
>
> sshcommand = "C:\\Users\\Jeffrey Walton\\Desktop\\test_tunnel.exe"
>
> Result:
>
> $ GIT_TRACE=1 git clone ssh://jeffrey.wal...@example.com:22480/main
> ...
> Cloning into 'main'...
> 11:44:32.192382 r
On Wed, Sep 04, 2019 at 03:41:15PM -0400, Jeff King wrote:
> The project page has a section to point people in the right direction
> for first-time contributions. I've left it blank for now, but I think it
> makes sense to point one (or both) of:
>
> - https://git-scm.com/docs/MyFirstContributio
On Mon, Sep 23, 2019 at 02:47:23PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 17 Sep 2019, SZEDER Gábor wrote:
>
> > On Tue, Sep 17, 2019 at 01:23:18PM +0200, Johannes Schindelin wrote:
> > > Also, things like the code tracing via `-x` (which relies on Bash
&
On Sat, Sep 21, 2019 at 11:11:28PM -0400, Taylor Blau wrote:
> Hi ZJ,
>
> On Tue, Sep 17, 2019 at 03:31:34PM +0200, Zeger-Jan van de Weg wrote:
> > When adding or updating configuration values using git-config, the
> > values could all be observed by different processes as these are passed
> > as
line arguments passed to the program in core.sshcommand?
Try
GIT_TRACE=1 git
and, among other things, you'll see something like
11:20:12.013785 run-command.c:663 trace: run_command: unset GIT_PREFIX;
ssh g...@github.com 'git-receive-pack '\''/szeder/git
On Mon, Sep 23, 2019 at 01:42:30AM +, brian m. carlson wrote:
> On 2019-09-22 at 18:01:43, SZEDER Gábor wrote:
> > diff --git a/builtin/name-rev.c b/builtin/name-rev.c
> > index c785fe16ba..a4d8d312ab 100644
> > --- a/builtin/name-rev.c
> > +++ b/builtin/n
On Sun, Sep 22, 2019 at 11:01:26PM +0200, Johannes Sixt wrote:
> Am 22.09.19 um 21:53 schrieb SZEDER Gábor:
> > On Sun, Sep 22, 2019 at 07:57:36PM +0100, Phillip Wood wrote:
> >> On 22/09/2019 19:01, SZEDER Gábor wrote:
> >>> +/*
> >>> + * One day. S
On Sun, Sep 22, 2019 at 07:57:36PM +0100, Phillip Wood wrote:
> On 22/09/2019 19:01, SZEDER Gábor wrote:
> >When 'git name-rev' is invoked with commit-ish parameters, it tries to
> >save some work, and doesn't visit commits older than the committer
> >date of
On Sat, Sep 21, 2019 at 02:37:18PM +0200, René Scharfe wrote:
> Am 21.09.19 um 11:57 schrieb SZEDER Gábor:
> > On Fri, Sep 20, 2019 at 08:14:07PM +0200, SZEDER Gábor wrote:
> >> On Fri, Sep 20, 2019 at 08:13:02PM +0200, SZEDER Gábor wrote:
> >>>> If the (
est
committer date, but when comparing the signed cutoff timestamp with
unsigned committer dates in name_rev(). IOW, this underflow bug is as
old as 'git name-rev' itself.
Signed-off-by: SZEDER Gábor
---
This patch adds a test at the end of 't6120-describe.sh', so it will
con
On Sat, Sep 21, 2019 at 02:37:05PM +0200, René Scharfe wrote:
> Am 20.09.19 um 20:13 schrieb SZEDER Gábor:
> >>> @@ -280,12 +269,16 @@ static int name_ref(const char *path, const struct
> >>> object_id *oid, int flags, vo
> >>> if (o && o->t
On Fri, Sep 20, 2019 at 09:53:48AM -0700, William Baker via GitGitGadget wrote:
> diff --git a/midx.h b/midx.h
> index f0ae656b5d..e6fa356b5c 100644
> --- a/midx.h
> +++ b/midx.h
> @@ -37,6 +37,8 @@ struct multi_pack_index {
> char object_dir[FLEX_ARRAY];
> };
>
> +#define MIDX_PROGRESS
On Fri, Sep 20, 2019 at 08:14:07PM +0200, SZEDER Gábor wrote:
> On Fri, Sep 20, 2019 at 08:13:02PM +0200, SZEDER Gábor wrote:
> > > If the (re)introduced leak doesn't impact performance and memory
> > > usage too much then duplicating tip_name again in name_rev(
ser/running-build-in-debug-mode/
[2] 9cc2c76f5e (travis-ci: record and skip successfully built trees,
2017-12-31)
Signed-off-by: SZEDER Gábor
---
Range-diff:
1: e9badc7483 ! 1: a1959d3e16 travis-ci: ignore already tested trees in debug
mode
@@ Metadata
Author: SZEDER Gábor
On Fri, Sep 20, 2019 at 02:47:38PM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > At the top of 't6120-describe.sh' an ASCII graph illustrates the
> > repository's history used in this test script. This graph is a bit
> > misleading, because it
On Fri, Sep 20, 2019 at 11:28:11AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> >> But in the larger picture, I would expect that readers would more
> >> immediately grasp what it is about if it were titled "do not skip
> >> versions that
On Fri, Sep 20, 2019 at 11:03:48AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > skip_good_tree () {
> > + if test "$TRAVIS_DEBUG_MODE" = true
> > + then
> > + return
> > + fi
>
> I think you convinced readers
> > @@ -280,12 +269,16 @@ static int name_ref(const char *path, const struct
> > object_id *oid, int flags, vo
> > if (o && o->type == OBJ_COMMIT) {
> > struct commit *commit = (struct commit *)o;
> > int from_tag = starts_with(path, "refs/tags/");
> > + const
On Fri, Sep 20, 2019 at 08:13:02PM +0200, SZEDER Gábor wrote:
> > If the (re)introduced leak doesn't impact performance and memory
> > usage too much then duplicating tip_name again in name_rev() or
> > rather your new create_or_update_name() would likely make the
> &
On Fri, Sep 20, 2019 at 11:21:53AM -0400, Derrick Stolee wrote:
> On 9/19/2019 5:47 PM, SZEDER Gábor wrote:
> > The 'if (deref) { ... }' condition near the beginning of the recursive
> > name_rev() function can only ever be true in the first invocation,
> > because
On Fri, Sep 20, 2019 at 11:37:12AM -0400, Derrick Stolee wrote:
> On 9/19/2019 5:46 PM, SZEDER Gábor wrote:
> > 'git name-rev' is implemented using a recursive algorithm, and,
> > consequently, it can segfault in deep histories (e.g. WebKit), and
> > thanks to
On Fri, Sep 20, 2019 at 11:27:49AM -0400, Derrick Stolee wrote:
> On 9/19/2019 5:47 PM, SZEDER Gábor wrote:
> > At the beginning of the recursive name_rev() function it creates a new
> > 'struct rev_name' instance for each previously unvisited commit or, if
> > th
1 - 100 of 1904 matches
Mail list logo
