On Mon, Aug 12, 2019 at 09:49:20AM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > On 2019-08-12 at 00:32:26, Junio C Hamano wrote:
> >> "brian m. carlson" writes:
> >> > +static ssize_t stripped_path_suffix_offset(const char *path, const char
> >> > *suffix)
> >>
> >> Perhaps
Hi,
I observed this today:
$ git grep -F '('
fatal: unmatched parenthesis
Which doesn't make sense and I believe shouldn't happen.
$ git --version
git version 2.22.0
Hi, everyone
I just posted a new update on my project:
https://matheustavares.gitlab.io/posts/simplified-version-of-parallel-inflation
This week I sent a simplified version of the series I was working on
last week (which would still take some time to finish). And I'm
working to improve it with su
On Mon, Aug 12, 2019 at 11:18:35AM -0700, Junio C Hamano wrote:
> "Yagnatinsky, Mark" writes:
>
> > ... Assuming the repo has no .gitattributes,
> > is it possible to predict what line endings sample.txt will end up with in
> > my repo?
> > Or does it depend on more information than what I've ju
Hi All!
Here[1] is an update about the last week. Sorry for a late update.
I couldn't find time to post since we are in the middle of an
internship season.
Thanks for reading
Rohit
[1]: https://rashiwal.me/2019/another-iteration/
On Mon, Aug 12, 2019 at 10:40:21PM +, brian m. carlson wrote:
> I think "ends_with_path_components" might be the way forward, unless
> you think something else would be better.
FWIW, having read the rest of the thread, that was the name that clicked
for me.
-Peff
Thanks, a bunch Junio :)
On 12:40 Mon 12 Aug 2019, Junio C Hamano wrote:
A maintenance release Git v2.22.1 is now available at the usual
places. This backports many of the fixes that appeared already
on the 'master' front in preparation for the upcoming v2.23 release
of Git.
The tarballs are
On 2019-08-12 at 16:49:20, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > On 2019-08-12 at 00:32:26, Junio C Hamano wrote:
> >> "brian m. carlson" writes:
> >> > +static ssize_t stripped_path_suffix_offset(const char *path, const char
> >> > *suffix)
> >>
> >> Perhaps
> >>
> >>
Peff is completely right: the log showed host=smpt.gmail.com:587 as
expected. Keychain confirms.
Thanks!
D. Ben Knoble
P.S. Be sure to delete /tmp/credential.log afterwards to clean up your
passwords.
On Mon, Aug 12, 2019 at 6:18 PM Jeff King wrote:
>
> On Mon, Aug 12, 2019 at 06:00:14PM -0400
On Mon, Aug 12, 2019 at 06:00:14PM -0400, D. Ben Knoble wrote:
> I spent a frustrating hour today hoping to setup git-send-email with
> my gmail account. I've been able to confirm the following:
>
> 1. git credential works
>
> # git config credential.helper
> osxkeychain
> # git cred
Hello all,
I spent a frustrating hour today hoping to setup git-send-email with
my gmail account. I've been able to confirm the following:
1. git credential works
# git config credential.helper
osxkeychain
# git credential fill <
Hi,
On Mon, Aug 12, 2019, at 12:16 PM, Konstantin Ryabitsev wrote:
> We have it working in a similar configuration, but with CGit instead of
> GitWeb. Unless you have specific requirements to run GitWeb, I recommend
> you use CGit for your web frontend, as it offers many features GitWeb
> doesn
This allows users to default to parallel fetches, so they don't have to
pass --fetch-jobs=N on the command line every time. The implementation
matches submodule.fetchjobs by die()ing on invalid job counts.
I couldn't find any documentation for submodule.fetchjobs, so I didn't
write any for this o
This argument allows users to select the number of jobs that will run in
parallel when fetching, with each job fetching from a different remote.
This is particularly useful when fetching from many remotes that change
slowly on a high latency link, as the fetch time is dominated by
handshake latency
This is exactly the same as --jobs, but the more explicit name will
allow us to later change the behavior of --jobs to control both the
number of jobs for remotes as well as submodules.
Signed-off-by: Palmer Dabbelt
---
Documentation/fetch-options.txt | 1 +
builtin/fetch.c | 2 +
The existing --jobs argument was defined to control the number of jobs
used for submodule fetching, but it makes more sense to have this
argument control the number of jobs to be used when fetching from
multiple remotes as well.
This patch simply changes the --jobs argument parsing code to set bot
It seems like the feedback for v1 was fairly positive, so I managed to
find some time to go ahead finish it. The result is a much cleaner
patch set. I think this could be merged in its current state, but there
are a few outstanding concerns I have:
* fetch.jobs isn't documented because I couldn'
This does not change any functionality, but instead just prepares for
the upcoming "--fetch-jobs=" support. Essentially the "max_children"
variable is ambiguously named, which would complicate the diff in
squashed into the "--fetch-jobs=" patch.
Signed-off-by: Palmer Dabbelt
---
builtin/fetch.c
On Mon, Aug 12, 2019 at 01:04:55PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think it might be worth just eliminating the whole idea.
>
> I kinda like the simplification ;-) An even thinner wrapper that
> calls malloc() and dies if it gets NULL, without any "try-to-free"
> logic.
Team,
seeing as v2.23.0 is just around the corner, I decided on skipping a
full Git for Windows release for v2.22.1: while the list of patches
between v2.22.0 and v2.22.1 is extensive, nothing sticks out to me that
says that we need a new Git for Windows only to release another one in
six days any
On 12/08/2019 18:50, SZEDER Gábor wrote:
When running interactive rebase to reword a commit message, I would
expect that the commit whose message I'm rewording is checked out.
This is not quite the case when rewording multiple subsequent commit
messages.
Let's start with four commits, and start
Jeff King writes:
> I think it might be worth just eliminating the whole idea.
I kinda like the simplification ;-) An even thinner wrapper that
calls malloc() and dies if it gets NULL, without any "try-to-free"
logic.
On Sun, Aug 11, 2019 at 12:08:53PM -0700, Carlo Arenas wrote:
> there is also the risk that xmalloc might not be sufficiently thread
> safe (ex: when it triggers unuse_one_window() through the use of a
> try_to_free_routine in packfile.c but we could mitigate the risk for
> now by doing it only fi
The purpose of amend_author was to free() the malloc()'d string
obtained from get_author() while amending a commit. But we can
also use the variable to free() the author at our convenience.
Rename it to convey this meaning.
Signed-off-by: Rohit Ashiwal
---
sequencer.c | 6 +++---
1 file changed,
The previous commit introduced --ignore-date flag to interactive
rebase, but the name is actually very vague in context of rebase -i
since there are two dates we can work with. Add an alias to convey
the precise purpose.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt | 1 +
builti
I've tried to work on all the suggestion in this revision.
Based on: 2e27de94d485a6da0c8e264c165e55100f1a13a8 (tag: v2.23.0-rc2)
Rohit Ashiwal (6):
rebase -i: add --ignore-whitespace flag
sequencer: add NULL checks under read_author_script
rebase -i: support --committer-date-is-author-date
rebase am already has this flag to "lie" about the author date
by changing it to the committer (current) date. Let's add the same
for interactive machinery.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt| 6 +--
builtin/rebase.c| 21 +++---
There are two backends available for rebasing, viz, the am and the
interactive. Naturally, there shall be some features that are
implemented in one but not in the other. One such flag is
--ignore-whitespace which indicates merge mechanism to treat lines
with only whitespace changes as unchanged. Wi
rebase am already has this flag to "lie" about the committer date
by changing it to the author date. Let's add the same for
interactive machinery.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt| 8 +++-
builtin/rebase.c| 20 ++---
sequencer
read_author_script reads name, email and author date from the author
script. However, it does not check if the arguments are NULL. Adding
NULL checks will allow us to selectively get the required value, for
example:
char *date;
if (read_author_script(_path_, NULL, NULL, &date, _int_))
A maintenance release Git v2.22.1 is now available at the usual
places. This backports many of the fixes that appeared already
on the 'master' front in preparation for the upcoming v2.23 release
of Git.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following pu
Hi Carlo,
On Sun, 11 Aug 2019, Carlo Arenas wrote:
> On Sun, Aug 11, 2019 at 4:20 AM Johannes Schindelin
> wrote:
> > On Sat, 10 Aug 2019, Carlo Marcelo Arenas Belón wrote:
> > > cURL is very strict about its allocator being thread safe and so that
> > > might
> > > be an issue to look for.
> >
On Mon, Aug 12, 2019 at 08:09:22AM -0700, ko...@mailc.net wrote:
Hi all.
I'm setting up a local Git server, with Gitweb + Gitolite.
We have it working in a similar configuration, but with CGit instead of
GitWeb. Unless you have specific requirements to run GitWeb, I recommend
you use CGit fo
On Mon, Aug 12, 2019 at 11:17:01AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > ...
> > So far so good.
> > Save the updated commit message, and after the editor opens up the
> > third commit's log message, check again where HEAD is pointing to now:
> >
> > ~/tmp/reword (master +|R
Okay, let me be more explicit :)
Suppose "git check-attr -a ." produces no output.
Now, is predictable?
-Original Message-
From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of
Junio C Hamano
Sent: Monday, August 12, 2019 2:19 PM
To: Yagnatinsky, Mark
Cc: 'Torst
"Yagnatinsky, Mark" writes:
> ... Assuming the repo has no .gitattributes,
> is it possible to predict what line endings sample.txt will end up with in my
> repo?
> Or does it depend on more information than what I've just written?
Binary packagers can ship custom attributes and config that ap
SZEDER Gábor writes:
> ...
> So far so good.
> Save the updated commit message, and after the editor opens up the
> third commit's log message, check again where HEAD is pointing to now:
>
> ~/tmp/reword (master +|REBASE-i 2/3)$ head -n1 .git/COMMIT_EDITMSG
> third
> ~/tmp/reword (master +
Okay, I feel like I'm on the verge of understanding, but it keeps eluding me,
because you keep answering the question I actually asked, rather than the
one I should have asked... let me try again, and bear with me if it seems like
I'm
repeating the same question over and over, because I don't unde
When running interactive rebase to reword a commit message, I would
expect that the commit whose message I'm rewording is checked out.
This is not quite the case when rewording multiple subsequent commit
messages.
Let's start with four commits, and start an interactive rebase from
the first comm
Hi Phillip
On Thu, 8 Aug 2019 17:44:38 +0100 Phillip Wood
wrote:
>
> [...]
> > --ignore-whitespace::
> > + This flag is either passed to the 'git apply' program
> > + (see linkgit:git-apply[1]), or to 'git merge' program
> > + (see linkgit:git-merge[1]) as `-Xignore-space-change`,
> > +
The grammar for commits used a '?' rather than a '*' on the `merge`
directive line, despite the fact that the code allows multiple `merge`
directives in order to support n-way merges. In fact, elsewhere in
git-fast-import.txt there is an explicit declaration that "an unlimited
number of `merge` co
On Mon, Aug 12, 2019 at 01:47:18PM +, Yagnatinsky, Mark wrote:
> Wait a second... suppose a file is committed with CRLF line endings.
> You're saying that even if I have autocrlf set to "input" or "auto", the file
> will never get "converted" to LF format unless I explicitly renormalize?
Yes.
Hi Peff,
Thanks, I didn't think that would make any difference either, but changing the
case resolved it! I'm now able to find the relevant line in the .gitignore file.
Regards,
Geoff
-Original Message-
From: Jeff King
To: geoffsimons
CC: git
Sent: Mon, 12 Aug 2019 17:35
Subject:
"brian m. carlson" writes:
> On 2019-08-12 at 00:32:26, Junio C Hamano wrote:
>> "brian m. carlson" writes:
>> > +static ssize_t stripped_path_suffix_offset(const char *path, const char
>> > *suffix)
>>
>> Perhaps
>>
>> static ssize_t last_path_component_offset(const char *path, const cha
On Sat, Aug 10, 2019 at 09:05:33AM -0700, Gregory Szorc wrote:
> I tracked down a source of Git corrupting repositories to lock file
> design not being robust when containers / PID namespaces are present.
>
> In my case, the corruption stemmed from premature release of the `git
> gc` lock in the
On Mon, Aug 12, 2019 at 04:24:59PM +, geoffsim...@aim.com wrote:
> I can’t find anything relevant in .git/info/exclude either, or any of
> the .gitignore files I could find.
>
> git check-ignore
> .\Source\UI\Website\LiveFeeds\Releases\IO\ReleasesSerializer.cs
> git add .\Source\ui\Website\L
Hi,
I’m struggling with this. Adding a renamed file to git claims that it is
ignored, but git check-ignore returns no results.
I can’t find anything relevant in .git/info/exclude either, or any of the
.gitignore files I could find.
git check-ignore .\Source\UI\Website\LiveFeeds\Releases\IO\R
On Mon, Aug 12, 2019 at 09:04:36AM -0700, Junio C Hamano wrote:
> > t/perf/{p5600-clone-reference.sh => p5601-clone-reference.sh} | 0
> > 1 file changed, 0 insertions(+), 0 deletions(-)
> > rename t/perf/{p5600-clone-reference.sh => p5601-clone-reference.sh} (100%)
> >
> > diff --git a/t/perf/p
On Mon, Aug 12, 2019 at 12:15:19PM +0200, Jacob Vosmaer wrote:
> This is a tangent, but relevant: how do we feel about the fact that
> 'git bundle create' does not perform CRC32 checks when copying data
> out of an existing packfile?
>
> See
> https://github.com/git/git/blob/v2.22.0/builtin/pack
Jeff King writes:
> There are two perf scripts numbered p5600, but with otherwise different
> names ("clone-reference" versus "partial-clone"). We store timing
> results in files named after the whole script, so internally we don't
> get confused between the two. But "aggregate.perl" just prints
There are two perf scripts numbered p5600, but with otherwise different
names ("clone-reference" versus "partial-clone"). We store timing
results in files named after the whole script, so internally we don't
get confused between the two. But "aggregate.perl" just prints the test
number for each res
"Randall S. Becker" writes:
>> The lock design of gc.pid stores the current hostname and PID of the locking
>> process in the file. If another process comes along and its hostname matches
>> the stored hostname, it checks to see if the listed PID exists. If the PID is
>> missing, it assumes the l
But I don't even have a git attributes file! There's no attribute flipping
going on, I think.
The CRLF'd file was committed by someone else on my team, who probably has git
configured differently than I do.
Or am I missing the point?
-
"Yagnatinsky, Mark" writes:
> Wait a second... suppose a file is committed with CRLF line
> endings. You're saying that even if I have autocrlf set to
> "input" or "auto", the file will never get "converted" to LF
> format unless I explicitly renormalize? That sounds like a fairly
> sensible be
Hi all.
I'm setting up a local Git server, with Gitweb + Gitolite.
The gitolite wrapper is installed & working. Now I'm working on the Gitweb
frontend.
I run Nginx as my webserver. Usually with PHP, using fpm.
Gitweb's gitweb.cgi looks like it needs perl CGI.
For perl cgi I'm trying to get
Hello,Kindly be informed that this email that came to your mailbox is
not an error but was specifically addressed to you for your
consideration. I have a proposal of ($7.500.000.00) left by my late
client Engineer Carlos, I will give you more details upon
reply.contact me on this(barristermus...@gm
Wait a second... suppose a file is committed with CRLF line endings.
You're saying that even if I have autocrlf set to "input" or "auto", the file
will never get "converted" to LF format unless I explicitly renormalize?
That sounds like a fairly sensible behavior, but it's not what I've observed i
On August 10, 2019 12:06 PM, Gregory Szorc wrote:
> I tracked down a source of Git corrupting repositories to lock file design not
> being robust when containers / PID namespaces are present.
>
> In my case, the corruption stemmed from premature release of the `git gc`
> lock in the gc.pid file. B
On August 11, 2019 8:39 PM, Junio C Hamano wrote:
> Jeff King writes:
>
> > IMHO scripting around "action" commands like checkout is less bad than
> > around "output" commands like log. The general action of "switch to
> > this branch" is unlikely to be changed much over the years (or via
> > con
On August 9, 2019 5:24 PM, I wrote:
> On 12:29 Fri 09 Aug 2019, Junio C Hamano wrote:
> > >A release candidate Git v2.23.0-rc2 is now available for testing at
> > >the usual places. It is comprised of 483 non-merge commits since
> > >v2.22.0, contributed by 67 people, 24 of which are new faces.
>
On Mon, Aug 12, 2019 at 5:14 AM René Scharfe wrote:
>
> That looks like an issue worth its own commit.
OK, but then will make my topic interesting; indeed it almost feels
like it should be 3 different topics all depending of each other in a
chain:
* really use the match context
* move to xmalloc
Am 12.08.19 um 09:35 schrieb Carlo Arenas:
> On Sat, Aug 10, 2019 at 12:48 PM René Scharfe wrote:
>>> On Sat, Aug 10, 2019 at 12:57 AM René Scharfe wrote:
>>>
>>> Do you mind then if I "adopt" your patch and submit a reroll with it,
>>
>> I don't mind, sounds good.
>
> I had to squash another fix
This is a tangent, but relevant: how do we feel about the fact that
'git bundle create' does not perform CRC32 checks when copying data
out of an existing packfile?
See https://github.com/git/git/blob/v2.22.0/builtin/pack-objects.c#L2614-L2622 .
I understand the rationale of "skip CRC32 when serv
On Sat, Aug 10, 2019 at 12:48 PM René Scharfe wrote:
> > On Sat, Aug 10, 2019 at 12:57 AM René Scharfe wrote:
> >
> > Do you mind then if I "adopt" your patch and submit a reroll with it,
>
> I don't mind, sounds good.
I had to squash another fix that was reported[1] before but wasn't picked up
64 matches
Mail list logo
