(The patch is identical to v3 but I've tried to clarify the commit
message and added the missing sign-off.)
On Fri, May 24, 2019 at 4:10 PM Eric Rannaud wrote:
>
> At a checkpoint, fast-import resets all branches and tags on disk to the
> OID that we have in memory. If --force is not given, only
We would like you to solicit your services as our representative/partner
in your region at your request i will forward you the company's corporate
presentation
of our offer for your review and consideration. Kindly advise.
-Sebastian Miller
At a checkpoint, fast-import resets all branches and tags on disk to the
OID that we have in memory. If --force is not given, only branch resets
that result in fast forwards with respect to the state on disk are
allowed. fast-import never updates its internal view of branches in
response to externa
On 24/05/2019 23:30, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, May 24 2019, Ramsay Jones wrote:
>
>> [No, I won't be sending 52 patches to the list!]
>> [...]
>> This series does not fix any problems or add any new features, so it
>> is not important (hence the tendency to 'slip'). I don't wa
On Fri, May 24 2019, Ramsay Jones wrote:
> [No, I won't be sending 52 patches to the list!]
> [...]
> This series does not fix any problems or add any new features, so it
> is not important (hence the tendency to 'slip'). I don't want to
> flood the mailing list with patches that nobody wants, s
On 5/21/2019 8:21 PM, Matthew DeVore wrote:
Allow combining filters such that only objects accepted by all filters
are shown. The motivation for this is to allow getting directory
listings without also fetching blobs. This can be done by combining
blob:none with tree:. There are massive reposi
I wrote:
> Below are the compiler errors.
Well, to be precise, all but imap-send are warnings rather
than errors.
--
Todd
[No, I won't be sending 52 patches to the list!]
This series, started last year, has been hanging around because the
time never seemed right to send it to the list. It may still not be
the right time ... :-D
I would like to be able to compile git using '-Wall -Wextra -Werror'
compiler options.
On Fri, May 24, 2019 at 7:08 PM Matthew DeVore wrote:
>
> On Fri, May 24, 2019 at 02:03:18PM +0200, Christian Couder wrote:
> > For now though, let's just disable 'sparse:path' filters.
>
> This is probably the right thing to do. I did jump through a lot of hoops to
> support escaping sub-filters
On 5/24/2019 8:03 AM, Christian Couder wrote:
If someone wants to use as a filter a sparse file that is in the
repository, something like "--filter=sparse:oid=:"
already works.
So 'sparse:path' is only interesting if the sparse file is not in
the repository. In this case though the current im
Jonathan Tan wrote:
> Currently, if any server options are specified during a protocol v2
> fetch, server options will be sent before "command=fetch". Write server
> options to the request buffer in send_fetch_request() so that the
> components of the request are sent in the correct order.
>
> The
On Fri, May 24, 2019 at 01:48:35PM -0400, Konstantin Ryabitsev wrote:
> I seem to be getting a segfault trying to verify bundles created from
> linux.git. It's easy to reproduce:
>
> $ cd linux
> $ git show-ref master
> c50bbf615f2f0028ad1771506ef8807130ccc2ce refs/heads/master
> $ git bundle crea
On 5/24/2019 8:39 AM, Christian Couder wrote:
On Fri, May 24, 2019 at 2:21 PM Ævar Arnfjörð Bjarmason
wrote:
On Fri, May 24 2019, Christian Couder wrote:
If someone wants to use as a filter a sparse file that is in the
repository, something like "--filter=sparse:oid=:"
already works.
So
From: Vishal Verma
Convert option_commit to tristate, representing the states of
'default/untouched', 'enabled-by-cli', 'disabled-by-cli'. With this in
place, check whether option_commit was enabled by cli when squashing a
merge. If so, error out, as this is not supported.
Previously, when --squ
Hello:
I seem to be getting a segfault trying to verify bundles created from
linux.git. It's easy to reproduce:
$ cd linux
$ git show-ref master
c50bbf615f2f0028ad1771506ef8807130ccc2ce refs/heads/master
$ git bundle create /tmp/linux.bundle master
Enumerating objects: 6705678, done.
Counting
Hi,
Nguyễn Thái Ngọc Duy wrote:
> This should fix the diff tests failure on s360x. It's a serious problem
> and I plan to do something to prevent it from happening again.
Thanks for looking at this!
I applied this on top of master/2.22.0-rc1 and see a number
of compiler errors using gcc-9.1.1 wi
Ubuntu 14.04
I was using some prior v2.x using linuxbrew, everything was fine, took
an update, this started happening.
I verified also happens using the 2.21.0 from the Ubuntu 14.04 PPA
(this reproduction was using that build, not linuxbrew build).
bboerner@myhost:~/funproject/Src/bash$ git --ve
On Mai 24 2019, Robert Dailey wrote:
> Can anyone provide some advice on how to properly restructure this
> repository to create some ancestry, as if all along a `master` existed
> and all release branches were based on this in a linear fashion?
How about using git replace --graft, then git filt
On Fri, May 24, 2019 at 02:03:18PM +0200, Christian Couder wrote:
> For now though, let's just disable 'sparse:path' filters.
This is probably the right thing to do. I did jump through a lot of hoops to
support escaping sub-filters in my pending filter combination patchset, since
sparse spec path
On Fri, May 24 2019, Robert Dailey wrote:
> Everything I'm going to describe is related to this repository:
>
> https://github.com/powervr-graphics/Native_SDK
>
> This repo has several distinct branches. None of them seem to be tied
> to each other. Instead of having a `master` where they branch
On Fri, May 24, 2019 at 9:04 AM Robert Dailey wrote:
>
> Everything I'm going to describe is related to this repository:
>
> https://github.com/powervr-graphics/Native_SDK
>
> This repo has several distinct branches. None of them seem to be tied
> to each other. Instead of having a `master` where
Everything I'm going to describe is related to this repository:
https://github.com/powervr-graphics/Native_SDK
This repo has several distinct branches. None of them seem to be tied
to each other. Instead of having a `master` where they branched off
each of their releases (e.g. 3.1, 3.2, 4.0), it
On Fri, May 24 2019, SZEDER Gábor wrote:
> On Fri, May 24, 2019 at 01:58:03PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, May 24 2019, SZEDER Gábor wrote:
>>
>> > On Fri, May 24, 2019 at 01:17:06PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> >>
>> >> On Fri, May 24 2019, SZEDER Gábor wrote:
On Fri, May 24, 2019 at 2:21 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Fri, May 24 2019, Christian Couder wrote:
>
> > If someone wants to use as a filter a sparse file that is in the
> > repository, something like "--filter=sparse:oid=:"
> > already works.
> >
> > So 'sparse:path' is only intere
On Fri, May 24, 2019 at 01:58:03PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, May 24 2019, SZEDER Gábor wrote:
>
> > On Fri, May 24, 2019 at 01:17:06PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >>
> >> On Fri, May 24 2019, SZEDER Gábor wrote:
> >>
> >> > On Fri, May 24, 2019 at 11:01:39AM +0
From: Johannes Schindelin
We will need to pass down the `struct index_state` to
`mark_fsmonitor_valid()` for an upcoming bug fix, and this here function
calls that there function, so we need to extend the signature of
`fill_stat_cache_info()` first.
Signed-off-by: Johannes Schindelin
---
apply
From: Johannes Schindelin
Without this bug fix, t7519's four "status doesn't detect unreported
modifications" test cases would fail occasionally (and, oddly enough,
*a lot* more frequently on Windows).
The reason is that these test cases intentionally use the side effect of
`git status` to re-wr
The t7519-status-fsmonitor.sh tests became a lot more flaky with the recent
fsmonitor fix (js/fsmonitor-refresh-after-discarding-index). That fix,
however, did not introduce the flakiness, but it just made it much more
likely to be hit. And it seemed to be hit only on Windows.
The reason, though,
On Fri, May 24 2019, Christian Couder wrote:
> If someone wants to use as a filter a sparse file that is in the
> repository, something like "--filter=sparse:oid=:"
> already works.
>
> So 'sparse:path' is only interesting if the sparse file is not in
> the repository. In this case though the cu
If someone wants to use as a filter a sparse file that is in the
repository, something like "--filter=sparse:oid=:"
already works.
So 'sparse:path' is only interesting if the sparse file is not in
the repository. In this case though the current implementation has
a big security issue, as it makes
On Fri, May 24 2019, SZEDER Gábor wrote:
> On Fri, May 24, 2019 at 01:17:06PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, May 24 2019, SZEDER Gábor wrote:
>>
>> > On Fri, May 24, 2019 at 11:01:39AM +0200, Ævar Arnfjörð Bjarmason wrote:
>> >> I don't think it's a performance problem to ha
On Fri, May 24, 2019 at 01:17:06PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, May 24 2019, SZEDER Gábor wrote:
>
> > On Fri, May 24, 2019 at 11:01:39AM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> I don't think it's a performance problem to have an old commit-graph
> >> lying around. But if
On Fri, May 24, 2019 at 12:49:12PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> > On Thu, May 23, 2019 at 07:48:33PM -0400, Derrick Stolee wrote:
> >> >> On 5/23/2019 6:20 PM, SZEDER Gábor wrote:
> >> >> > On Thu, May 23, 2019 at 11:54:22PM +0200, Ævar Arnfjörð Bjarmason
> >> >> > wrote:
> >> >
> >>
If we try to do a range query such as C..D with topology as
A_0 - ... - A_1 - B - C_1 - ... - C_1000 - C
\
D_1 - ... - D_1000 - D
and none of the commits in {A_i, B, C_j, C} have a computed
bitmap, then we will very likely walk many many tr
On Fri, May 24 2019, SZEDER Gábor wrote:
> On Fri, May 24, 2019 at 11:01:39AM +0200, Ævar Arnfjörð Bjarmason wrote:
>> I don't think it's a performance problem to have an old commit-graph
>> lying around. But if you turn on the commit-graph, run gc a bunch, then
>> turn it off in config we'll ha
On Fri, May 24 2019, SZEDER Gábor wrote:
> On Fri, May 24, 2019 at 11:49:28AM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Fri, May 24 2019, SZEDER Gábor wrote:
>>
>> > On Thu, May 23, 2019 at 07:48:33PM -0400, Derrick Stolee wrote:
>> >> On 5/23/2019 6:20 PM, SZEDER Gábor wrote:
>> >> > On Th
On 5/24/2019 3:24 AM, Jeff King wrote:
> On Thu, May 23, 2019 at 08:53:56AM -0400, Derrick Stolee wrote:
>
>>> I spent a while thinking and experimenting with this tonight. The result
>>> is the patch below. Ævar, do you still have a copy of the repo that
>>> misbehaved? I'd be curious to see how
On Fri, May 24 2019, Jakub Narebski wrote:
> Jeff King writes:
>> On Mon, May 20, 2019 at 11:53:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>>> Clarify the hash-object docs to explicitly note that the --literally
>>> option guarantees that a loose object will be written, but that a
>>> normal
On Fri, May 24 2019, Duy Nguyen wrote:
> On Wed, May 22, 2019 at 7:35 AM Ramsay Jones
> wrote:
>>
>>
>>
>> On 22/05/2019 01:11, Duy Nguyen wrote:
>> > On Wed, May 22, 2019 at 2:56 AM Ramsay Jones
>> > wrote:
>> >>
>> >> Hi Duy,
>> >>
>> >> I am in the middle of rebasing a long running branch o
On Fri, May 24, 2019 at 11:49:28AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, May 24 2019, SZEDER Gábor wrote:
>
> > On Thu, May 23, 2019 at 07:48:33PM -0400, Derrick Stolee wrote:
> >> On 5/23/2019 6:20 PM, SZEDER Gábor wrote:
> >> > On Thu, May 23, 2019 at 11:54:22PM +0200, Ævar Arnfjörð
Jeff King writes:
> On Mon, May 20, 2019 at 11:53:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> Clarify the hash-object docs to explicitly note that the --literally
>> option guarantees that a loose object will be written, but that a
>> normal -w ("write") invocation doesn't.
>
> I had to double
On Thu, May 23, 2019 at 11:51 PM Matheus Tavares Bernardino
wrote:
>
> Hi, everyone
>
> As one of my first tasks in GSoC, I'm looking to protect the global
> states at sha1-file.c for future parallelizations. Currently, I'm
> analyzing how to deal with the cached_objects array, which is a small
>
On Fri, May 24 2019, SZEDER Gábor wrote:
> On Thu, May 23, 2019 at 07:48:33PM -0400, Derrick Stolee wrote:
>> On 5/23/2019 6:20 PM, SZEDER Gábor wrote:
>> > On Thu, May 23, 2019 at 11:54:22PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> >> and since the commit graph doesn't include any commits out
On Wed, May 22, 2019 at 7:35 AM Ramsay Jones
wrote:
>
>
>
> On 22/05/2019 01:11, Duy Nguyen wrote:
> > On Wed, May 22, 2019 at 2:56 AM Ramsay Jones
> > wrote:
> >>
> >> Hi Duy,
> >>
> >> I am in the middle of rebasing a long running branch onto
> >> current master (v2.22.0-rc1) and noticed someth
There is a disconnect between the actual value type from parse-options
user and the parser itself. This is because we have to store 'value'
pointer as 'void *' and the compiler cannot help point out that the user
is passing a 'long' while the parser expects an 'int'. This could lead
to memory corru
On Thu, May 23, 2019 at 07:48:33PM -0400, Derrick Stolee wrote:
> On 5/23/2019 6:20 PM, SZEDER Gábor wrote:
> > On Thu, May 23, 2019 at 11:54:22PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> and since the commit graph doesn't include any commits outside of
> >> packs you'd miss any loose commits.
>
On Fri, May 24, 2019 at 11:01:39AM +0200, Ævar Arnfjörð Bjarmason wrote:
> I don't think it's a performance problem to have an old commit-graph
> lying around. But if you turn on the commit-graph, run gc a bunch, then
> turn it off in config we'll have it lying around forever, even if you do
> subs
On Fri, May 24, 2019 at 10:31 AM Jeff King wrote:
>
> On Fri, May 24, 2019 at 10:05:45AM +0200, Christian Couder wrote:
> > The way I see it could be restricted is by adding a config option on
> > the server, maybe called "uploadpack.sparsePathFilter", to tell which
> > filenames can be accessed
This should fix the diff tests failure on s360x. It's a serious problem
and I plan to do something to prevent it from happening again.
The second patch should bring '-U' (no argument) back. Whether it makes
sense to accept this behavior is not part of this conversion. We can
deal with that later.
Before d473e2e0e8 (diff.c: convert -U|--unified, 2019-01-27), -U and
--unified are implemented with a custom parser opt_arg() in diff.c. I
didn't check this code carefully and not realize that it's the
equivalent of PARSE_OPT_NONEG | PARSE_OPT_OPTARG.
In other words, if -U is specified without any
When parsing the argument for OPT_INTEGER and OPT_ABBREV, we check if we
can parse the entire argument to a number with "if (*s)". There is one
missing check: if "arg" is empty to begin with, we fail to notice.
This could happen with long option by writing like
git diff --inter-hunk-context= bl
Most number-related OPT_ macros store the value in an 'int'
variable. Many of the variables in 'struct diff_options' have a
different type, but during the conversion to using parse_options() I
failed to notice and correct.
The problem was reported on s360x which is a big-endian
architechture. The
Hi,
git fetch in my repository *when nothing new is received* takes 2.5x
the time when comparing 2.20 against 2.21 (on Windows it's 4x).
I have 5 initialized submodules in this working directory.
I reported this issue on git-for-windows github:
https://github.com/git-for-windows/git/issues/2199
On Fri, May 24 2019, Jeff King wrote:
> On Fri, May 24, 2019 at 09:55:05AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > I'm not sure what tickles the bitmap-writer to fail so hard. Is it
>> > having too many refs? Weird patterns in the graph? Just a ton of
>> > commits?
>>
>> Ah, why did only th
On Fri, May 24, 2019 at 10:05:45AM +0200, Christian Couder wrote:
> (Sorry for the late reply to this.)
No problem. I've been meaning to pick it up again, and somehow it's been
6 months. ;)
> > > But mainly I was thinking of a use case on the client of the form:
> > >
> > > git rev-list
> >
On Fri, May 24, 2019 at 09:55:05AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I'm not sure what tickles the bitmap-writer to fail so hard. Is it
> > having too many refs? Weird patterns in the graph? Just a ton of
> > commits?
>
> Ah, why did only this ancient (big) pack have a bitmap?
>
> The bi
On Thu, May 23 2019, Eric Wong wrote:
> Jeff King wrote:
>> On Thu, May 23, 2019 at 08:59:59AM +, Eric Wong wrote:
>>
>> > > We never delete entries from the in-memory packed_git list; a reprepare
>> > > only adds to the list. You'd need to teach update_server_info() to
>> > > ignore packs
On Fri, May 24, 2019 at 09:35:51AM +0200, Keegan Carruthers-Smith wrote:
> > I can't reproduce on Linux, using GNU tar (1.30) nor with bsdtar 3.3.3
> > (from Debian's bsdtar package). What does your "tar --version" say?
>
> bsdtar 2.8.3 - libarchive 2.8.3
Interesting. I wonder if there was a lib
(Sorry for the late reply to this.)
On Sat, Nov 24, 2018 at 8:07 AM Jeff King wrote:
>
> On Thu, Nov 08, 2018 at 01:57:52PM -0500, Jeff Hostetler wrote:
>
> > > Should we simply be disallowing sparse:path filters over upload-pack?
I agree that it should either be disallowed or heavily restricted
On Fri, May 24 2019, Jeff King wrote:
> On Thu, May 23, 2019 at 09:26:34PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > I spent a while thinking and experimenting with this tonight. The result
>> > is the patch below. Ævar, do you still have a copy of the repo that
>> > misbehaved? I'd be curiou
On Fri, 24 May 2019 at 09:06, Jeff King wrote:
>
> On Fri, May 24, 2019 at 08:45:23AM +0200, Keegan Carruthers-Smith wrote:
>
> > git archive can generate a malformed tar archive. bsdtar reports the
> > error "tar: Ignoring malformed pax extended attribute" when reading
> > the archive. Go's "tar/
On Thu, May 23, 2019 at 09:26:34PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I spent a while thinking and experimenting with this tonight. The result
> > is the patch below. Ævar, do you still have a copy of the repo that
> > misbehaved? I'd be curious to see how it fares.
>
> No, sorry. I think
On Thu, May 23, 2019 at 08:53:56AM -0400, Derrick Stolee wrote:
> > I spent a while thinking and experimenting with this tonight. The result
> > is the patch below. Ævar, do you still have a copy of the repo that
> > misbehaved? I'd be curious to see how it fares.
>
> This patch caught my attenti
On Fri, May 24, 2019 at 08:45:23AM +0200, Keegan Carruthers-Smith wrote:
> git archive can generate a malformed tar archive. bsdtar reports the
> error "tar: Ignoring malformed pax extended attribute" when reading
> the archive. Go's "tar/archive" package also reports the error
> "archive/tar: inv
64 matches
Mail list logo
