On Tue, Oct 22, 2019 at 04:06:16PM -0400, Jeff King wrote:
I'm biased, but I think the commit-graph is generally really good to
have
in almost all cases. I actually do not know of a good reason to _not_ have
it.
A lot depends on how much you do on the server. If you're serving a web
interface
On Tue, Oct 22, 2019 at 09:18:35PM +0200, Johannes Schindelin wrote:
As to recreating blobs from mails: Wow. That's quite a length you're
going, and I think it is a shame that you have to. If only every
contribution came accompanied with a pullable branch in a public
repository.
Trouble is, tho
Hi, all:
I've read the docs on commitGraph and it's not 100% clear to me if
turning it on and generating commit graphs would be useful on the
server-side. I know it's going to be enabled by default and
automatically generated whenever "git gc" runs, so I'm trying to figure
out if it'll be use
On Fri, Oct 18, 2019 at 12:11:22PM -0400, Santiago Torres Arias wrote:
It's smaller, but it's not a one-liner. Here's a comparison using
ED25519
keys of the same length:
minisign:
RWQ4kF9UdFgeSt3LqnS3WnrLlx2EnuIFW7euw5JnLUHY/79ipftmj7A2ug7FiR2WmnFNoSacWr7llBuyInVmRL/VRovj1LFtvA0=
pgp:
-B
On Fri, Oct 18, 2019 at 11:54:09AM -0400, Santiago Torres Arias wrote:
Seeing how large this signature is, I have to admit that I am partial to
Konstantin's suggestion of using minisign. This seems like something
that could be added to git as an alternative to gpg without too much
trouble, I thin
On Thu, Oct 17, 2019 at 06:30:29PM -0700, Greg KH wrote:
It could only possibly work if nobody ever adds their own
"Signed-Off-By" or
any other bylines. I expect this is a deal-breaker for most maintainers.
Yeah it is :(
But, if we could just have the signature on the code change, not the
cha
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 Fri, Sep 27, 2019 at 08:24:37AM -0700, d...@linuxprogrammer.org wrote:
- generate a signify-compatible cryptographic signature of the
verbatim
patch content, perhaps slightly normalized for things like LF vs. CRLF
line endings (see minisign/libsodium for crypto details)
- include both the sig
; taglines
For example:
---8<---
>From b41a2a0f817caddc9a76f43c3c9ed7d8edd6b2de Mon Sep 17 00:00:00 2001
From: Konstantin Ryabitsev
Date: Tue, 10 Sep 2019 06:15:36 -0400
Subject: [PATCH] Second commit
Change the greeting.
Signed-off-by: Konstantin Ryabitsev
---
foo.c | 2 +-
1 file ch
On Wed, Aug 28, 2019 at 07:47:06PM -0400, Jeff King wrote:
On Wed, Aug 28, 2019 at 04:32:24PM -0400, Konstantin Ryabitsev wrote:
If I know that a project uses tag signing, would "git clone" followed by
"git verify-tag" be meaningful without a "git fsck" in-be
Hi, all:
If I know that a project uses tag signing, would "git clone" followed by
"git verify-tag" be meaningful without a "git fsck" in-between? I.e. if
an attacker has control over the remote server, can they sneak in any
badness into any of the resulting files and still have the clone,
che
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
er
> has to perform a big transfer for the repositories.
We use grokmirror to replicate several thousand repositories worldwide
using git-native protocols. It is fast and very efficient.
https://github.com/mricon/grokmirror
Regards,
--
Konstantin Ryabitsev
Director, Projects IT
The Linux Foundation
Montréal, Québec
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
#x27;re still in Europe :), Ottawa (if you like museums
and large historical government buildings)
Best,
--
Konstantin Ryabitsev
Montréal, Québec
On Wed, Jan 09, 2019 at 02:27:25PM -0800, Stefan Beller wrote:
> > > I would've thought somebody had done this by now, but I guess
> > > it's dependent on a bunch of things (TLS layer nowadays, maybe
> > > HTTP/2), so git-daemon support alone wouldn't cut it...
> >
> > Polling is not all bad, espec
On Sat, Dec 29, 2018 at 03:56:21AM +, Eric Wong wrote:
> Hey all, I just added this to the TODO file for public-inbox[1] but
> obviously it's intended for git.git (meta@public-inbox cc-ed):
>
> > +* Contribute something like IMAP IDLE for "git fetch".
> > + Inboxes (and any git repos) can be
Hi, all:
Every now and again I come across a patch sent to LKML without a leading
"diff a/foo b/foo" -- usually produced by quilt. E.g.:
https://lore.kernel.org/lkml/20181125185004.151077...@linutronix.de/
I am guessing quilt does not bother including the leading "diff a/foo
b/foo" because it's
On Thu, Nov 15, 2018 at 07:54:32PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > I think that if we use the "principle of least surprise," insteadOf
> > rules shouldn't be applied for git-request-pull URLs.
>
> I haven't used request-pull so I don't have much of an opinion on this,
> but do you think
Hi, all:
Looks like setting url.insteadOf rules alters the output of
git-request-pull. I'm not sure that's the intended use of insteadOf,
which is supposed to replace URLs for local use, not to expose them
publicly (but I may be wrong). E.g.:
$ git request-pull HEAD^ git://foo.example.com/example
Michal:
This is strictly a development list. If you would like to discuss any
and all monetization features, please feel free to reach out to me via
email.
Regards,
-K
On Thu, May 17, 2018 at 04:45:18PM +0300, Michal Sapozhnikov wrote:
Hi,
I would like to schedule a quick call this week.
Wha
tually. :)
I feel like a whitepaper on "how we deal with bajillions of forks at
GitHub" would be nice. :) I was previously told that it's unlikely such
paper could be written due to so many custom-built things at GH, but I
would be very happy if that turned out not to
" (followed by prune)
Currently, we do "-Adl" regardless, but we already track whether a repo
is being used for alternates anywhere (so we don't prune it) and can do
different flags if that improves performance.
Best,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
T
ing a bunch of loose objects would be greater. For the
sake of simplicity, I think I'll leave things as they are -- it's
cheaper to fix this via reducing seek times than by applying complicated
logic trying to optimize on a per-repo basis.
Best,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation
signature.asc
Description: OpenPGP digital signature
e) performance degradation. On the other
hand, I don't want to keep useless objects in the pack, because that
would also cause performance degradation for people cloning the "mother
repo." If my assumptions on any of that are incorrect, I'm happy to
learn more.
Best,
--
Konstantin Rya
On 05/16/18 14:02, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, May 16 2018, Konstantin Ryabitsev wrote:
>
>> Maybe git-repack can be told to only borrow parent objects if they are
>> in packs. Anything not in packs should be hardlinked into the child
>> repo. That
On 05/16/18 13:14, Martin Fick wrote:
> On Wednesday, May 16, 2018 10:58:19 AM Konstantin Ryabitsev
> wrote:
>>
>> 1. Find every repo mentioning the parent repository in
>> their alternates 2. Repack them without the -l switch
>> (which copies all the borrowed object
On Wed, May 16, 2018 at 05:34:34PM +0200, Ævar Arnfjörð Bjarmason wrote:
I may have missed some edge case, but I believe this entire workaround
isn't needed if you guarantee that the parent repo doesn't contain any
objects that will get un-referenced.
You can't guarantee that, because the paren
nterested in GVFS, because it would certainly make my life
easier maintaining source.codeaurora.org, which is many thousands of
repos that are mostly forks of the same stuff. However, GVFS appears to
only exist for Windows (hint-hint, nudge-nudge). :)
Best,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation
signature.asc
Description: OpenPGP digital signature
On Tue, May 08, 2018 at 01:51:30AM +, brian m. carlson wrote:
> On Mon, May 07, 2018 at 11:15:46AM -0700, Stefan Beller wrote:
> > There I would try to mirror Junios list of "public repositories"
> > https://git-blame.blogspot.com/p/git-public-repositories.html
> > without officially endorsing
pinion of where the links should
be pointing at, but it's important to point out that kernel.org and
GitHub serve different purposes:
- kernel.org provides free-as-in-liberty archive hosting on a platform
that is not locked into any vendor.
- github.com provides an integrated development infrastr
streaming services. It
seems a shame to have them sitting idle if I can offload some of the
RAM- and CPU-hungry tasks like repacking to be running there.
Best,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation
signature.asc
Description: OpenPGP digital signature
iest outliers, so let me
try to run with this.
Thanks for the suggestion!
Best,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation
signature.asc
Description: OpenPGP digital signature
2 or in_common > len(refs2)/2:
print('Lots of shared refs')
else:
print('None or too few shared refs')
This works well enough at least for those repos with lots of shared
tags, but will miss potentially large repos where there's only heads
that can be pointi
for
repos without tags.
Best,
--
Konstantin Ryabitsev
signature.asc
Description: OpenPGP digital signature
th it,
perhaps we can benefit from all the GPU computation libs written for
cryptocoin mining and use them for something good. :)
Best,
--
Konstantin Ryabitsev
signature.asc
Description: OpenPGP digital signature
instead of just gc is because
we use alternates to save on disk space and try not to prune repos that
are used as alternates by other repos in order to avoid potential
corruption.
Am I not doing something that needs to be doing in order to avoid the
same problem?
Thanks for your help.
Regards,
--
Konstantin Ryabitsev
Linux Foundation Collab Projects
Montréal, Québec
signature.asc
Description: PGP signature
k space,
you can find the tarball of the problematic repository here:
http://mricon.com/misc/src.git.tar.xz (warning: 6.6GB)
You can clone the non-problematic version of this repository from
git://codeaurora.org/quic/chrome4sdp/breakpad/breakpad/src.git
Best,
--
Konstantin Ryabitsev
Linux Foundation
> The tooling to allow this kind of "bundle" (and possibly other forms
> of "CDN offload" material) transparently used by "git clone" was the
> proposal by Shawn Pearce mentioned elsewhere in this thread.
To reiterate, I believe that would be an awesome featu
ge, or is it merely a
debug statement?
Best,
--
Konstantin Ryabitsev
Sr. Systems Administrator
Linux Foundation Collab Projects
541-224-6067
Montréal, Québec
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 20/10/14 06:28 PM, brian m. carlson wrote:
>> Junio, quite frankly, I don't think that that fix was a good idea. I'd
>> > suggest having a *separate* umask for the pax headers, so that we do
>> > not break this long-lasting stability of "git archive" output in ways
>> > that are unfixable and n
On 20/10/14 02:28 PM, Junio C Hamano wrote:
> I have to wonder why 10f343ea (archive: honor tar.umask even for pax
> headers, 2014-08-03) is a problem but an earlier change v1.8.1.1~8^2
> (archive-tar: split long paths more carefully, 2013-01-05), which
> also should have broken bit-for-bit compati
't have immediate statistics on how many people release using "kup
--tar", but I know that at least you and Linus rely on that exclusively.
Regards,
--
Konstantin Ryabitsev
Systems Administrator
Linux Foundation, kernel.org
Montréal, Québec
signature.asc
Description: OpenPGP digital signature
43 matches
Mail list logo