All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Sep 2026, #04)
Date: Fri, 11 Sep 2026 21:01:41 +0200	[thread overview]
Message-ID: <aqRQFQz_E0ZPzrfe@pks.im> (raw)
In-Reply-To: <xmqqld97dbsa.fsf@gitster.g>

On Fri, Sep 11, 2026 at 08:53:57AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > On Thu, Sep 10, 2026 at 10:39:02AM -0700, Junio C Hamano wrote:
> >> * ps/libgit-in-subdir (2026-07-12) 2 commits
> >>  . Move libgit.a sources into separate "lib/" directory
> >>  . t/helper: prepare "test-example-tap.c" for introduction of "lib/"
> >>  . Merge branch 'ps/odb-source-packed' into ps/libgit-in-subdir
> >> 
> >>  The source files for 'libgit.a' have been moved into a new 'lib/'
> >>  directory to clean up the top-level directory and clearly separate
> >>  library code.  This topic has been ejected for now, as it causes too
> >>  many evil merges with other topics.
> >> ...
> > I didn't really have the feeling that I was gaining consensus on this
> > series. Maybe I'll be able to build consensus at the Contributor's
> > Summit, but until then we can probably just discard this series.
> 
> To be fair, I do not think anybody would unwelcome a change that
> makes the sources easier to navigate---otherwise we wouldn't have
> odb/ or even builtin/ hierarchies today.  It is just that different
> people views how easier to navigate a concrete change proposed makes
> the sources.

Yeah. Thing is, changes like this are always going to be subjective. I
expected lots of discussion around this particular one, so I knew that
it was quite likely that I won't be able to build consensus and that
there'd be lots of different opinions.

I personally still think that having library sources properly split out
into its own hierarchy is a sensible first step. But I also agree with
others that it makes sense to then further group files that belong to
specific subsystems into their own directories. I don't really see these
as mutually exclusive, we can have both.

Patrick

  reply	other threads:[~2026-09-11 19:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10 17:39 What's cooking in git.git (Sep 2026, #04) Junio C Hamano
2026-09-11  6:01 ` Patrick Steinhardt
2026-09-11 15:53   ` Junio C Hamano
2026-09-11 19:01     ` Patrick Steinhardt [this message]
2026-09-11  6:50 ` jk/ci-use-system-asciidoctor Tuomas Ahola
2026-09-11 15:56   ` jk/ci-use-system-asciidoctor Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aqRQFQz_E0ZPzrfe@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.