"Carlo Marcelo Arenas Belón via GitGitGadget"
writes:
> builtin/grep.c | 1 +
> grep.c | 34 +-
> grep.h | 1 +
> 3 files changed, 35 insertions(+), 1 deletion(-)
>
> +#if defined(USE_LIBPCRE2)
> + if (!pcre2_global_context)
> +
Philip Oakley writes:
> branch..merge::
> Defines, together with branch..remote, the upstream branch
> - for the given branch. It tells 'git fetch'/'git pull'/'git rebase' which
> + for the given branch. It defines the branch name _on the remote_,
> + which may be different fro
On Thu, Oct 17, 2019 at 04:45:32PM -0400, Konstantin Ryabitsev wrote:
> On Thu, Oct 17, 2019 at 01:43:43PM -0700, Greg KH wrote:
> > > I wonder if it'd be also possible to then embed gpg signatures over
> > > send-mail payloads so as they can be transparently transferred to the
> > > commit.
> >
>
"Johannes Schindelin via GitGitGadget"
writes:
> 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). However, the wrong path is returned for
> `
Understood (and agree).
We do use git for source code (where we use SSH
and key authentication for CI/CD), but also for
configuration control of other files like
financial reports, engineering drawings, etc.
where access is via HTTPS. In that 2nd group the
challenge is to make it as "not cod
Derrick Stolee writes:
> I hit this very situation recently when I was experimenting with
> 'git fast-import' and accidentally created many parallel, independent
> histories. Running "git log --graph --all --simplify-by-decoration"
> made it look like all the refs were in a line, but they were no
Doan Tran Cong Danh writes:
> Documentation/git-notes.txt | 6 +++---
> builtin/notes.c | 2 +-
> t/t3301-notes.sh| 40 +++--
> 3 files changed, 42 insertions(+), 6 deletions(-)
Thanks, makes sense.
Doan Tran Cong Danh writes:
> If we accidentally lifted the check inside our code base, the test may
> still failed because the provided parameter is not a valid ref.
Makes sense. Another option would be to use a valid ref to make
sure there are no other possible reason for the command to fail,
On 2019-10-17 at 08:56:34, Manoj Sterex wrote:
> Hi all,
>
> Currently, AFAIK, there is no way to know if a commit was done with or
> without using the '--no-verify' option. That is, git does not track if
> hooks were skipped when the commit happened.
>
> Is there some way to track this in the lo
On Thu, Oct 17, 2019 at 7:35 PM Denton Liu wrote:
> Although `test -f` has the same functionality as test_path_is_file(), in
> the case where test_path_is_file() fails, we get much better debugging
> information.
>
> Replace `test -f` with test_path_is_file() so that future developers
> will have
On 10/15/19 6:55 AM, Derrick Stolee via GitGitGadget wrote:
V4 UPDATE: Rebased on latest master to include ew/hashmap and
ds/include-exclude in the base.
I did a partial review of the v4 patches out of curiosity and I notice
in sparse-checkout.c there are a couple of unchecked `fopen` call site
-files)" = staged-file &&
> - test "$(git show :staged-file)" = staged-file &&
> + echo staged-file >expect &&
> + git ls-files >actual &&
> + test_cmp expect actual &&
> +
On Thu, Oct 17, 2019 at 7:17 PM Denton Liu wrote:
> In case an invocation of `git rev-list` fails within the subshell, the
> failure will be masked. Remove the subshell and use test_cmp_rev() so
> that failures can be discovered.
>
> Signed-off-by: Denton Liu
> ---
> diff --git a/t/t5520-pull.sh
On Thu, Oct 17, 2019 at 7:17 PM Denton Liu wrote:
> Instead of using `test -n` or `test -z`, replace them respectively with
> invocations of test_file_not_empty() and test_must_be_empty().
>
> Signed-off-by: Denton Liu
> ---
> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
> @@ -206,15 +206,18 @@
On Thu, Oct 17, 2019 at 7:17 PM Denton Liu wrote:
> Although `test -f` has the same functionality as test_path_is_file(), in
> the case where test_path_is_file() fails, we get much better debugging
> information. Replace `test -f` with test_path_is_file so that future
> developers will have a bett
On 2019-10-17 at 14:33:38, Ralph Ewig wrote:
> Quick follow up question: can the git client pass
> a token read from a cookie with a request? That
> would enable users to sign-in via a browser, store
> the cookie, and then use that as the access token
> to authenticate a git request.
Git has an op
On 2019-10-17 at 05:40:52, Jeff King wrote:
> 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
Hi Gábor,
On Wed, 16 Oct 2019, SZEDER Gábor wrote:
> 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
On Thu, Oct 17, 2019 at 01:43:43PM -0700, Greg KH wrote:
I wonder if it'd be also possible to then embed gpg signatures over
send-mail payloads so as they can be transparently transferred to the
commit.
That's a crazy idea. It would be nice if we could do that, I like it
:)
It could only po
On Wed, Oct 16, 2019 at 10:45:19AM -0400, Santiago Torres Arias wrote:
> 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 work
global ui_index ui_workdir ui_comm
> > > > > global rescan_active file_states
> > > > > - global repo_config
> > > > > + global repo_config _gitdir_cache
> > > > >
> > > > > if {$rescan_active > 0
On 17/10/19 07:08AM, Birger Skogeng Pedersen wrote:
> 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 en
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' subcommands.
> [...]
> Arguably 'git worktree unlock ' should only complete locked
> working trees, but 'git worktree list --porcelain' do
Denton Liu writes:
> 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.
> ...
Hmm. I like the general thrust, but ...
> LIB_OBJS += combine-diff.o
> -LIB_OBJS += comm
On Thu, Oct 17, 2019 at 1:35 PM SZEDER Gábor wrote:
> When using the __git_find_on_cmdline() helper function so far we've
> only been interested in which one of a set of words appear on the
> command line. To complete options for some of 'git worktree's
> subcommands in the following patches we'l
On Thu, Oct 17, 2019 at 12:28 PM Peter Jones wrote:
> Currently, if you do:
>
> $ git branch zonk origin/master
> $ git worktree add zonk zonk
> $ rm -rf zonk
> $ git branch -d zonk
>
> You get the following error:
>
> $ git branch -d zonk
> error: Cannot delete branch 'zonk' checked out at
> '/h
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 Thu, 17 Oct 2019 16:01:33 +0200
Vegard Nossum wrote:
> In your example, couldn't Darrick simply base his xfs work on the latest
> xfs branch that was pulled by Linus? That should be up to date with all
> things xfs without having any of the things that made Linus's tree not
> work for him.
Su
On Thu, Oct 17, 2019 at 04:01:33PM +0200, Vegard Nossum wrote:
>
> In your example, couldn't Darrick simply base his xfs work on the latest
> xfs branch that was pulled by Linus? That should be up to date with all
> things xfs without having any of the things that made Linus's tree not
> work for
Quick follow up question: can the git client pass
a token read from a cookie with a request? That
would enable users to sign-in via a browser, store
the cookie, and then use that as the access token
to authenticate a git request.
On 10/16/2019 11:03 PM, Jeff King wrote:
> On Thu, Oct 17, 2019
Interesting ... I have not looked at access tokens
before, but did find some documentation online
that describes how Azure AD Jason Web Tokens can
be used to authenticate a headless API
(https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens),
This seems to be a fit in thi
On 10/17/19 3:11 PM, Theodore Y. Ts'o wrote:
On Thu, Oct 17, 2019 at 02:23:58PM +0200, Vegard Nossum wrote:
Of course, this relies strongly on actually having (correct) sha1
references to previous versions inside the changelog. In my original
idea, this reference would only appear inside the m
Hi all,
On 11/10/2019 06:58, Jeff King wrote:
I snipped your concerns with some of the language. I do agree with you
that a lot of is open to interpretation. But I also think it's
impossible to get it 100% airtight. My feeling was that it was a good
idea to go with some existing, well-establishe
On 10/17/19 5:17 AM, Junio C Hamano wrote:
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) need
On Thu, Oct 17, 2019 at 02:23:58PM +0200, Vegard Nossum wrote:
> Of course, this relies strongly on actually having (correct) sha1
> references to previous versions inside the changelog. In my original
> idea, this reference would only appear inside the merge commit that
> binds the patchset togeth
On 10/16/19 10:57 PM, Jonathan Nieder wrote:
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
On 10/16/2019 12:00 AM, Junio C Hamano wrote:
> "James Coglan via GitGitGadget" writes:
>
>> This effect is applied to both "normal" two-parent merges, and to
>> octopus merges. It also reduces the vertical space needed for pre-commit
>> lines, as the merge occupies one less column than usual.
>>
On 10/15/2019 7:47 PM, 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
> +
> +test_description='
ut.
I do that every now and then for git-gui, and Junio does that sometimes
for Git. I don't know if the folks over at Linux do something like this,
but using '--exact' would mean that contributors would have to send a
re-roll for even minor changes. Its mostly an inconvenience inst
Hi Stolee,
On Tue, 15 Oct 2019, Derrick Stolee via GitGitGadget wrote:
> Running CI on Mac OS X in Azure Pipelines is currently broken due to a moved
> homebrew package.
It seems that the exact problem we tried to avoid by staying on caskroom
rears its ugly head: all of the macOS jobs are failin
Jeff King writes:
> I think this is a good distinction to draw, but...
>
>> Documentation/git-commit-tree.txt | 6 ++
>> 1 file changed, 6 insertions(+)
>
> ...I was surprised to see it here, where I think most users wouldn't
> find it. Would it make sense in git-commit(1), or in the descrip
"Hariom Verma via GitGitGadget" writes:
> -#define OUTPUT_SHOW_AGE_WITH_COLOR 04000
> +#define OUTPUT_ANNOTATE_COMPAT (1<<0)
> +#define OUTPUT_LONG_OBJECT_NAME (1<<1)
> +#define OUTPUT_RAW_TIMESTAMP(1<<2)
> +#define OUTPUT_PORCELAIN(1<<3)
> +#define OUTPUT_SHOW_NAME
"Hariom Verma via GitGitGadget" writes:
> 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 s
On Thu, Oct 17, 2019 at 04:03:00PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> >> Hmm, I am kind of surprised that the decoding side allowed such a
> >> padding.
> >
> > IIRC, the "padding" is just a sequence of 0-length-plus-continuation-bit
> > varint bytes. And for some reason it wor
SZEDER Gábor writes:
> However, I'm not sure what the right path should be in the first
> place, given that each working tree has its own 'logs' directory, but
> only for HEAD's reflog, while everything else goes to the main working
> tree's 'logs' directory.
As all worktrees should share the sa
"brian m. carlson" writes:
> Yeah, my default editor configuration for AsciiDoc is two spaces. I
> noticed that Junio's already picked it up for next, but I'll send a v2
> with this fixed in case he wants to merge the fixed version to master
> instead.
>
> If it's more convenient, I can send a f
Jeff King writes:
>> Hmm, I am kind of surprised that the decoding side allowed such a
>> padding.
>
> IIRC, the "padding" is just a sequence of 0-length-plus-continuation-bit
> varint bytes. And for some reason it worked for the size but not for the
> delta offset value.
I think the reason is b
testing it.
(As I mentioned earlier) I'm all for it when it comes to using a
config setting, rather than having this as default behaviour. I
propose "gui.autoFocusStaged" as a variable name for the setting.
I'll be doing a re-roll once I get some more spare time.
Birger
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
Definition and implementation of this
> flag.
Right, I think going in this direction is pretty simple. Having been
marked with QUICK, they hit both of my points from above. And if we want
to avoid re-scanning the pack directory because of cost, we _definitely_
want to avoid making an expensive
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.
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
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
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 b
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
an upstream issue. I guess we can just report it and wait
> > for them to fix it.
> I'd missed the final 'Segmentation fault' on the last line in the bash
> output that wasn't there for the captured file.
>
> That was repeatable in re-testing.
> But failed if
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
> > @@
- requires a bot to continuously create branches for patchsets sent to
> mailing lists
>
> - increased storage/bandwidth for git.kernel.org (?)
>
> - may need a couple of new wrapper scripts to automate patchset
> construction/versioning
Just to play the devil's advocate,
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`.
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
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
On Tue, Oct 15, 2019 at 6:25 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> >> * en/merge-recursive-directory-rename-fixes (2019-10-12) 2 commits
> >> (merged to 'next' on 2019-10-15 at ebfdc3ff7b)
> >> + merge-recursive: fix merging a subdirectory into the root directory
> >> + merge
On 2019-10-16 11:01:34 +0900, Junio C Hamano wrote:
> Doan Tran Cong Danh writes:
>
> > The target objects for copying notes was defaulted to HEAD from very
> > early stage of git-notes.
> >
> > However, that default was limited by commit bbb1b8a35a, ("notes: check
> > number of parameters to "gi
Junio C Hamano writes:
>> int graph_next_line(struct git_graph *graph, struct strbuf *sb)
>
> I just noticed it but does this have to be extern? Nobody outside
> graph.[ch] seems to have any reference to it.
I was stupid; strike this part out.
Thanks.
On Tue, Oct 15, 2019 at 2:13 PM Wink Saville wrote:
>>
>> Something like this makes sense and I've thought about the problem for
>> a long time. Unfortunately it's quite a bit trickier to do this.
>>
>> It would solve the problem more generally though, and definitely seems
>> like the right approa
"James Coglan via GitGitGadget" writes:
> This effect is applied to both "normal" two-parent merges, and to
> octopus merges. It also reduces the vertical space needed for pre-commit
> lines, as the merge occupies one less column than usual.
>
> Before: After:
>
> | *
"James Coglan via GitGitGadget" writes:
> From: James Coglan
>
> Now that the display width of graph lines is implicitly tracked via the
> `graph_line` interface, the calls to `graph_pad_horizontally()` no
> longer need to be located inside the individual output functions, where
> the character
"James Coglan via GitGitGadget" writes:
> +struct graph_line {
> + struct strbuf *buf;
> + size_t width;
> +};
> +
> +static inline void graph_line_addch(struct graph_line *line, int c)
> +{
> + strbuf_addch(line->buf, c);
> + line->width++;
> +}
> +
> +static inline void graph_li
James Coglan writes:
>> Is there a reason why you need a pointer to a strbuf that is
>> allocated separately? E.g. would it make it harder to manage
>> if the above were
>>
>> struct graphbuf {
>> struct strbuf buf;
>> int width; /* display width in columns */
>>
William Baker writes:
> At this time there are no other MIDX_* flags and so there's always the option
> to revisit the best way to handle multiple MIDX_* flags if/when additional
> flags are added.
I do not care too deeply either way, but if you wrote it in one way,
how about completing the seri
"Maxim Belsky via GitGitGadget" writes:
> From: Maxim Belsky
> Subject: Re: [PATCH v3 1/1] doc: Change zsh git completion file name
Lack of attention to the detail. This is not about changing the
filename anymore.
Subject: [PATCH v3] completion: clarify installation ins
201 - 300 of 116325 matches
Mail list logo
