RFE: git-patch-id should handle patches without leading "diff"

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

Re: insteadOf and git-request-pull output

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

insteadOf and git-request-pull output

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^

Re: Generate more revenue from Git

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.

Re: worktrees vs. alternates

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 be the case. Best, -- Konsta

Re: worktrees vs. alternates

; (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 The Linux F

Re: worktrees vs. alternates

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

Re: worktrees vs. alternates

rformance 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 Ryabitsev Director

Re: worktrees vs. alternates

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's m

Re: worktrees vs. alternates

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

Re: worktrees vs. alternates

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

Re: worktrees vs. alternates

inly 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

Re: main url for linking to git source?

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

Re: main url for linking to git source?

here 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 infrastructure that is f

Re: Is offloading to GPU a worthwhile feature?

ices. 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

Re: The most efficient way to test if repositories share the same objects

s, 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

Re: The most efficient way to test if repositories share the same objects

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 pointing at commits that aren't necessarily the same between two repos. Tha

The most efficient way to test if repositories share the same objects

for repos without tags. Best, -- Konstantin Ryabitsev signature.asc Description: OpenPGP digital signature

Is offloading to GPU a worthwhile feature?

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

Re: Repacking a repository uses up all available disk space

s 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

Repacking a repository uses up all available disk space

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 Collab Projects Montréal

Re: Resumable git clone?

cloning-linux-from-a-bundle.html > 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

Re: [PATCH v2 3/3] http-backend: spool ref negotiation requests to buffer

, -- 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

Re: Sources for 3.18-rc1 not uploaded

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

Re: Sources for 3.18-rc1 not uploaded

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 not

Re: git archve --format=tar output changed from 1.8.1 to 1.8.2.1

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