Hi Johannes,
On Thu, Oct 17, 2019 at 7:33 AM Johannes Sixt wrote:
> FWIW, I would prefer to experiment with the feature for a few weeks
> before it (or a configuration that enables it by default) is baked in.
Yes please do. Obviously I'm glad someone other than me will be
actually testing it.
(A
On Fri, Oct 11, 2019 at 09:33:11AM -0400, Derrick Stolee wrote:
> Here is today's test coverage report. The usual report format is
> available online [1], [2]. The report listed below is a new format
> that groups lines by the commit that introduced them [3]. Thanks
> Peff for the feedback on that
On Wed, Oct 09, 2019 at 04:44:22PM -0700, Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan
> ---
> builtin/index-pack.c | 267 ---
> 1 file changed, 127 insertions(+), 140 deletions(-)
I think this is a good direction to go in. I confess I didn't careful
On Wed, Oct 09, 2019 at 04:44:21PM -0700, Jonathan Tan wrote:
> A subsequent commit will make the quantum of work smaller, necessitating
> more locking. This commit allows resolve_delta() to be called outside
> the lock.
OK, that makes sense, I think.
-Peff
On Wed, Oct 09, 2019 at 04:44:20PM -0700, Jonathan Tan wrote:
> Whenever we make a struct base_data, immediately calculate its delta
> children. This eliminates confusion as to when the
> {ref,ofs}_{first,last} fields are initialized.
That _seems_ like a good idea, but I'm a little worried just b
On Wed, Oct 09, 2019 at 04:44:19PM -0700, Jonathan Tan wrote:
> -static void prune_base_data(struct base_data *retain)
> +static void prune_base_data(struct base_data *youngest_child)
> {
> struct base_data *b;
> struct thread_local *data = get_thread_data();
> - for (b = data->ba
On Thu, Oct 10, 2019 at 12:02:29PM -0700, Jonathan Tan wrote:
> > On 10/9/2019 7:44 PM, Jonathan Tan wrote:
> > > Instead, recompute ancestry if we ever need to reclaim memory.
> >
> > I find this message lacking in important details:
> >
> > 1. Where do we recompute ancestry?
> > 2. What are th
On Wed, Oct 09, 2019 at 04:44:18PM -0700, Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan
> ---
> builtin/index-pack.c | 26 --
> 1 file changed, 12 insertions(+), 14 deletions(-)
Yeah, this seems like a good cleanup. Probably worth explaining in the
commit message tha
On Wed, Oct 09, 2019 at 04:44:17PM -0700, Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan
> ---
> builtin/index-pack.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/builtin/index-pack.c b/builtin/index-pack.c
> index a23454da6e..1a2600d4b3 100644
> --- a/b
On Fri, Oct 11, 2019 at 03:08:22PM -0700, Jonathan Tan wrote:
> > As a general rule (and why I'm raising this issue in reply to Jonathan's
> > patch), I think most or all sites that want OBJECT_INFO_QUICK will want
> > SKIP_FETCH_OBJECT as well, and vice versa. The reasoning is generally
> > the s
On Thu, Oct 17, 2019 at 03:00:58AM +, Ralph Ewig wrote:
> Thanks for the reply. I was hoping the Git GUI
> might be able to handle the OpenID authentication
> flow, but it makes sense that it would be
> inconsistent with other git clients.
I don't think we'd ever do the full flow, but it m
On Thu, Oct 17, 2019 at 12:53:30AM +, brian m. carlson wrote:
> Users in a wide variety of situations find themselves with HTTP push
> problems. Oftentimes these issues are due to antivirus software,
> filtering proxies, or other man-in-the-middle situations; other times,
> they are due to si
On Thu, Oct 17, 2019 at 12:53:29AM +, brian m. carlson wrote:
> There is no sensible behavior in this case, because sometimes the data
> is precious, such as certain configuration files, and sometimes it is
> irrelevant data that the user would be happy to discard.
>
> Since this is not a sup
On Thu, Oct 17, 2019 at 12:53:28AM +, brian m. carlson wrote:
> It's a frequent misconception that the user.name variable controls
> authentication in some way, and as a result, beginning users frequently
> attempt to change it when they're having authentication troubles.
> Document that the c
Am 17.10.19 um 07:08 schrieb Birger Skogeng Pedersen:
> Hi Pratyush,
>
> On Wed, Oct 16, 2019 at 9:28 PM Pratyush Yadav wrote:
>> I mentioned this earlier, and I'll mention this again: I'm not sure
>> whether this feature would be a good thing for the larger population. So
>> this _might_ not end
Hi Pratyush,
On Wed, Oct 16, 2019 at 9:28 PM Pratyush Yadav wrote:
> I mentioned this earlier, and I'll mention this again: I'm not sure
> whether this feature would be a good thing for the larger population. So
> this _might_ not end up being accepted depending on how people react to
> the propo
Vegard Nossum writes:
> Step 1:
>
> * git send-email needs to include parent SHA1s and generally all the
> information needed to perfectly recreate the commit when applied so
> that all the SHA1s remain the same
>
> * git am (or an alternative command) needs to recreate the commit
> perfect
Thanks for the reply. I was hoping the Git GUI
might be able to handle the OpenID authentication
flow, but it makes sense that it would be
inconsistent with other git clients.
Azure AD does support both LDAP and Kerberos, but
unfortunately only as an extra cost add-on called
"Domain Services"
Jeff King writes:
> Maybe:
>
> 'git fetch', 'git pull', and 'git clone'
>
> ? Given the repetition below, though:
... including this one, I think you covered everything I wanted to
say on the patch already. Thanks.
It's a frequent misconception that the user.name variable controls
authentication in some way, and as a result, beginning users frequently
attempt to change it when they're having authentication troubles.
Document that the convention is that this variable represents some form
of a human's personal
It is quite common for users to want to ignore the changes to a file
that Git tracks. Common scenarios for this case are IDE settings and
configuration files, which should generally not be tracked and possibly
generated from tracked files using a templating mechanism.
However, users learn about t
Users in a wide variety of situations find themselves with HTTP push
problems. Oftentimes these issues are due to antivirus software,
filtering proxies, or other man-in-the-middle situations; other times,
they are due to simple unreliability of the network.
However, a common solution to HTTP push
This series includes three patches that update the documentation to
address common user misconceptions.
The first patch has seen the list before, which is why this is now v2.
It addresses the attempt to use "user.name" as a username for
$GIT_HOSTING_SERVICE instead of a person's personal name.
Th
When pushing more than one reference with the --atomic option, the
server is supposed to perform a single atomic transaction to update the
references, leaving them either all to succeed or all to fail. This
works fine when pushing locally or over SSH, but when pushing over HTTP,
we fail to pass th
On 2019-10-15 at 16:40:29, Jeff King wrote:
> On Tue, Oct 15, 2019 at 01:07:59AM +, brian m. carlson wrote:
> > diff --git a/Documentation/gitremote-helpers.txt
> > b/Documentation/gitremote-helpers.txt
> > index a5c3c04371..670d72c174 100644
> > --- a/Documentation/gitremote-helpers.txt
> > +
On 2019-10-15 at 15:59:03, Ralph Ewig wrote:
> 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
> mo
[Removed bouncing addresses of Matthieu Moy and William Duclot from Cc]
Am 16.10.19 um 22:32 schrieb Stephen Boyd:
> diff --git a/t/t4018/dts-nodes-multiline-prop
> b/t/t4018/dts-nodes-multiline-prop
> new file mode 100644
> index ..db4b4bdda686
> --- /dev/null
> +++ b/t/t4018/dts-nod
On Wed, Oct 16, 2019 at 10:57:37AM +0100, Philip Oakley wrote:
> From: Philip Oakley
>
> Git URLs can accept bundle files for fetch, pull and clone, include
> in that section. Include git clone in the bundle usage description.
> Correct the quoting of .
> Detail the options for cloning a comple
Hi,
A few small points.
Vegard Nossum wrote:
> * git am (or an alternative command) needs to recreate the commit
> perfectly when applied, including applying it to the correct parent
Interesting. "git format-patch" has a --base option to do some of
what you're looking for, for the sake of sn
While reviewing some dts diffs recently I noticed that the hunk header
logic was failing to find the containing node. This is because the regex
doesn't consider properties that may span multiple lines, i.e.
property = ,
;
and it got hung up on comments inside nodes that
Quoting Johannes Sixt (2019-10-12 05:54:00)
> Am 08.10.19 um 16:43 schrieb Stephen Boyd:
> > Quoting Johannes Sixt (2019-10-05 07:09:11)
> >> Am 04.10.19 um 23:30 schrieb Stephen Boyd:
> >>> --- /dev/null
> >>> +++ b/t/t4018/dts-nodes-multiline-prop
> >>> @@ -0,0 +1,12 @@
> >>> +/ {
> >>> + lab
On Tue, Oct 15, 2019 at 6:56 AM Derrick Stolee via GitGitGadget
wrote:
> Updates in V4:
>
> * Updated hashmap API usage to respond to ew/hashmap
>
>
> * Responded to detailed review by Elijah. Thanks!
>
>
> * Marked the feature as experimental in git-sparse-checkout.txt the same
>way that g
On 10/15/19 7:09 PM, Junio C Hamano wrote:
>> 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,
> h
On 16/10/19 12:37PM, Jonathan Tan wrote:
> > There was some discussion recently about converting these related
> > #defines to enums [0]. We might consider doing that here.
> >
> > If you read through that entire thread, you'd see that there were some
> > disagreements about whether using enums
> There was some discussion recently about converting these related
> #defines to enums [0]. We might consider doing that here.
>
> If you read through that entire thread, you'd see that there were some
> disagreements about whether using enums for sets of bits is a good idea
> ([1] and [2]), b
From: William Baker
The comments for the staging/unstaging test did not accurately
describe the scenario being tested. It is not essential that
the test files being staged/unstaged appear at the end of the
index. All that is required is that the test files are not
flagged with CE_FSMONITOR_VALI
This patch series is based on the 'wb/fsmonitor-bitmap-fix' branch and
addresses feedback on the new test that was added there.
I've updated the comments for the new test to more accurately describe the
scenario being tested.
Thanks,
William
William Baker (1):
t7519-status-fsmonitor: improve
On 15/10/19 12:51PM, Birger Skogeng Pedersen wrote:
> Hi Pratyush,
>
> Thanks for reviewing. How does this work, do I send a re-roll of the
> patch(es)?
Yes, please do.
I mentioned this earlier, and I'll mention this again: I'm not sure
whether this feature would be a good thing for the larger
On 07/10/19 07:11PM, Birger Skogeng Pedersen wrote:
> When the user focuses the Commit Message widget (to write a message), the
> diff view may be blank.
>
> With this patch a staged file is automatically selected when the Commit
> Message widget is focused, if no other file is selected (i.e. diff
On 16/10/19 06:30PM, Hariom Verma via GitGitGadget wrote:
> From: Hariom Verma
>
> We are looking at bitfield constants, and elsewhere in the Git source
> code, such cases are handled via bit shift operators rather than octal
> numbers, which also makes it easier to spot holes in the range
> (if,
On 16/10/2019 17:47, SZEDER Gábor wrote:
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 c
On Tue, Oct 15, 2019 at 6:56 AM Derrick Stolee via GitGitGadget
wrote:
> +DESCRIPTION
> +---
> +
> +Initialize and modify the sparse-checkout configuration, which reduces
> +the checkout to a set of directories given by a list of prefixes.
> +
> +THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR
On 14/10/19 11:11PM, Philip Oakley wrote:
> On 14/10/2019 18:57, Pratyush Yadav wrote:
> > > list "refs/heads/MSVC-README" [list "commit"
> > > "056fb95c8e983ec07e9f5f8baa0b119bf3d13fed" [concat "" "Philip Oakley"]
> > > [reformat_date [concat "" "Sun May 19 22:33:37 2019 +0100"]]
> > > "compat/vcS
we are looking at bitfield constants, and elsewhere in the Git source code,
such cases are handled via bit shift operators rather than octal numbers,
which also makes it easier to spot holes in the range (if, say, 1<<5 was
missing, it is easier to spot it between 1<<4 and 1<<6 than it is to spot a
From: Hariom Verma
We are looking at bitfield constants, and elsewhere in the Git source
code, such cases are handled via bit shift operators rather than octal
numbers, which also makes it easier to spot holes in the range
(if, say, 1<<5 was missing, it is easier to spot it between 1<<4
and 1<<6
Hi, thought I'd send this to git@ as a public FYI. Some of you were
concerned about my inactivity recently, rest assured I'm fine, just been
busy with other things.
Hoping to get back into it sooner than later, sorry about not replying
to things I've been CC'd on.
Since autostash.c was recently introduced, we should avoid
USE_THE_INDEX_COMPATIBILITY_MACROS since we are trying to move away from
this in the rest of the codebase. Rewrite the autostash code to not need
it and remove its definition.
Signed-off-by: Denton Liu
---
autostash.c | 8 +++-
1 fil
There are many += lists in the Makefile and, over time, they have gotten
slightly out of order, alphabetically. Alphabetically sort all += lists
to bring them back in order.
Signed-off-by: Denton Liu
---
Makefile | 75
1 file changed, 38 i
Continue the process of lib-ifying the autostash code. In a future
commit, this will be used to implement `--autostash` in other builtins.
This patch is best viewed with `--color-moved` and
`--color-moved-ws=allow-indentation-change`.
Signed-off-by: Denton Liu
---
autostash.c | 46
Alban reported[1] that he expected merge to have an --autostash option,
just like rebase. Since there's not really any reason why merge can't
have it, let's implement it in this patchset.
The actual logic isn't too bad. That change can be found in the last
patch. The remainder is refactoring so th
Continue the process of lib-ifying the autostash code. In a future
commit, this will be used to implement `--autostash` in other builtins.
This patch is best viewed with `--color-moved` and
`--color-moved-ws=allow-indentation-change`.
Signed-off-by: Denton Liu
---
autostash.c | 46
In rebase, one can pass the `--autostash` option to cause the worktree
to be automatically stashed before continuing with the rebase. This
option is missing in merge, however.
Implement the `--autostash` option and corresponding `merge.autoStash`
option in merge which stashes before merging and th
Begin the process of lib-ifying the autostash code. In a future commit,
This patch is best viewed with `--color-moved` and
`--color-moved-ws=allow-indentation-change`.
this will be used to implement `--autostash` in other builtins.
Signed-off-by: Denton Liu
---
autostash.c | 137 ++
Begin the process of lib-ifying the autostash code. In a future commit,
this will be used to implement `--autostash` in other builtins.
This patch is best viewed with `--color-moved` and
`--color-moved-ws=allow-indentation-change`.
Signed-off-by: Denton Liu
---
autostash.c | 12 +++
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
Hi Willy, Vegard.
On Wed, Oct 16, 2019 at 01:10:09PM +0200, Willy Tarreau wrote:
> Hi Vegard,
>
> On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote:
> > (cross-posted to git, LKML, and the kernel workflows mailing lists.)
> >
> > Hi all,
> >
> > I've been following Konstantin Ryabit
On 15/10/19 10:59AM, Junio C Hamano wrote:
> "kdnakt via GitGitGadget" writes:
>
> > @@ -661,7 +662,7 @@ msgstr ""
> > #: lib/merge.tcl:108
> > #, tcl-format
> > msgid "%s of %s"
> > -msgstr "%s の %s ブランチ"
> > +msgstr "%2$s の %1$s ブランチ"
> >
> > #: lib/merge.tcl:122
> > #, tcl-format
> > @@
Hi Vegard,
On 16/10/19 12:22PM, Vegard Nossum wrote:
> (cross-posted to git, LKML, and the kernel workflows mailing lists.)
>
> Hi all,
>
> I've been following Konstantin Ryabitsev's quest for better development
> and communication tools for the kernel [1][2][3], and I would like to
> propose a
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.
Is this the right place for the information, is it complete enough,
and is the defaul
From: =?UTF-8?q?Carlo=20Marcelo=20Arenas=20Bel=C3=B3n?=
94da9193a6 ("grep: add support for PCRE v2", 2017-06-01) introduced
a small memory leak visible with valgrind in t7813.
Complete the creation of a PCRE2 specific variable that was missing from
the original change and free the generated tabl
As I had stated several times, I was really unhappy how the original fix
harped on nedmalloc and totally ignored runtime-configured custom
allocators.
So this is, at long last, my attempt to give this a new life. It is based
off of maint and needs trivial merge conflict resolutions relative to mas
From: =?UTF-8?q?Carlo=20Marcelo=20Arenas=20Bel=C3=B3n?=
94da9193a6 (grep: add support for PCRE v2, 2017-06-01) didn't include
a way to override the system allocator, and so it is incompatible with
custom allocators (e.g. nedmalloc). This problem became obvious when we
tried to plug a memory leak
From: =?UTF-8?q?Carlo=20Marcelo=20Arenas=20Bel=C3=B3n?=
63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09) didn't include a way
to override the system alocator, and so it is incompatible with
USE_NED_ALLOCATOR as reported by Dscho[1] (in similar code from PCRE2)
Note that nedmalloc, as well as othe
From: Johannes Schindelin
94da9193a6 ("grep: add support for PCRE v2", 2017-06-01) introduced
a small memory leak visible with valgrind in t7813.
Complete the creation of a PCRE2 specific variable that was missing from
the original change and free the generated table just like it is done
for PCR
As I had stated several times, I was really unhappy how the original fix
harped on nedmalloc and totally ignored runtime-configured custom
allocators.
So this is, at long last, my attempt to give this a new life. It is based
off of maint and needs trivial merge conflict resolutions relative to mas
From: =?UTF-8?q?Carlo=20Marcelo=20Arenas=20Bel=C3=B3n?=
63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09) didn't include a way
to override the system alocator, and so it is incompatible with
USE_NED_ALLOCATOR as reported by Dscho[1] (in similar code from PCRE2)
Note that nedmalloc, as well as othe
From: =?UTF-8?q?Carlo=20Marcelo=20Arenas=20Bel=C3=B3n?=
94da9193a6 (grep: add support for PCRE v2, 2017-06-01) didn't include
a way to override the system allocator, and so it is incompatible with
custom allocators (e.g. nedmalloc). This problem became obvious when we
tried to plug a memory leak
The branch..merge value typically looks just like a
local ref. Tell the reader it is the ref name at the remote,
which may be different.
Signed-off-by: Philip Oakley
---
This confusion had me scratching my head for many minutes recently.
A simple clarification would avoid such mental model error
Hi Vegard,
On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote:
> (cross-posted to git, LKML, and the kernel workflows mailing lists.)
>
> Hi all,
>
> I've been following Konstantin Ryabitsev's quest for better development
> and communication tools for the kernel [1][2][3], and I would
On Wed, Oct 16, 2019 at 07:07:17AM +, 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 `index`. However, the wrong path
> is returned for `index.lock`.
(cross-posted to git, LKML, and the kernel workflows mailing lists.)
Hi all,
I've been following Konstantin Ryabitsev's quest for better development
and communication tools for the kernel [1][2][3], and I would like to
propose a relatively straightforward idea which I think could bring a
lot to
On 16/10/2019 10:57, Philip Oakley wrote:
From: Philip Oakley
Oops - the From: line still has my old email address. Is a resend
preferred, or can it be fixed locally?
P.
Git URLs can accept bundle files for fetch, pull and clone, include
in that section. Include git clone in the bundle usage
From: Philip Oakley
Git URLs can accept bundle files for fetch, pull and clone, include
in that section. Include git clone in the bundle usage description.
Correct the quoting of .
Detail the options for cloning a complete repo.
Signed-off-by: Philip Oakley
---
This takes up the advice from p
On 16/10/2019 00:52, Beat Bolli wrote:
> 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 w
I stumbled over this during my recent work in Git GUI
[https://github.com/gitgitgadget/git/pull/361] that was originally really
only intended to use the correct hooks directory.
Technically, the first patch is not needed (because I decided against adding
a test to t1400 in the end, in favor of t15
From: Johannes Schindelin
Without this, you cannot use `--run=<...>` to skip that part, and a run
with `--run=0` (which is a common way to determine the test case number
corresponding to a given test case title).
Signed-off-by: Johannes Schindelin
---
t/t1400-update-ref.sh | 18 ++-
From: Johannes Schindelin
Ever since worktrees were introduced, the `git_path()` function _really_
needed to be called e.g. to get at the `index`. However, the wrong path
is returned for `index.lock`.
This does not matter as long as the Git executable is doing the asking,
as the path for that `i
78 matches
Mail list logo
