From: Patrick Steinhardt <ps@pks.im>
To: eugenio gigante <giganteeugenio2@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com,
karthik nayak <karthik.188@gmail.com>,
phillip.wood123@gmail.com
Subject: Re: [PATCH 2/5] refs: make `is_pseudoref_syntax()` stricter
Date: Thu, 21 Mar 2024 14:09:10 +0100 [thread overview]
Message-ID: <ZfwxdiF2RPS23zAl@tanuki> (raw)
In-Reply-To: <CAFJh0PSRrz=WYvuXgFGER6_E5qshVKSWNxBDgVo6GcCGfFDK8A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]
On Fri, Mar 15, 2024 at 11:05:41AM +0100, eugenio gigante wrote:
> On Wed, 24 Jan 2024 09:51:52 +0100 Patrick Steinhardt <ps@pks.im> wrote:
>
> > We also have consider that there may be alternate implementations of Git
> > that would only know to handle the old layout. Those tools would be
> > broken in case we did such a migration, but they would be broken anyway
> > if the bisect was started via Git and not via the tool.
>
> The first implementations that come to my mind are Jgit and libgit2.
> I took a look at these two and apparently there is no support for git-bisect.
> Maybe you are not referring to those.
I'm basically referring to everything that has wider use out there and
that knows to access Git repositories. I don't know about all the
implementations out there and whether they do or don't support
bisections. If they don't then this is great, because it makes it a ton
easier for us to argue why the proposed refactoring is okay to do.
> Also, do we care about several GUIs for git?
Many users do use graphical frontends, so we likely should investigate
how they'd behave, yes.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-03-21 13:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-15 10:05 [PATCH 2/5] refs: make `is_pseudoref_syntax()` stricter eugenio gigante
2024-03-21 13:09 ` Patrick Steinhardt [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-01-19 14:27 [PATCH 0/5] for-each-ref: print all refs on empty string pattern Karthik Nayak
2024-01-19 14:27 ` [PATCH 2/5] refs: make `is_pseudoref_syntax()` stricter Karthik Nayak
2024-01-19 20:44 ` Junio C Hamano
2024-01-22 20:13 ` Phillip Wood
2024-01-22 20:22 ` Junio C Hamano
2024-01-23 11:03 ` Phillip Wood
2024-01-23 12:49 ` Karthik Nayak
2024-01-23 16:40 ` phillip.wood123
2024-01-23 17:46 ` Junio C Hamano
2024-01-23 17:38 ` Junio C Hamano
2024-01-23 11:16 ` Patrick Steinhardt
2024-01-23 16:30 ` Phillip Wood
2024-01-23 17:44 ` Junio C Hamano
2024-01-24 8:51 ` Patrick Steinhardt
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=ZfwxdiF2RPS23zAl@tanuki \
--to=ps@pks.im \
--cc=giganteeugenio2@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=karthik.188@gmail.com \
--cc=phillip.wood123@gmail.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.