From: Christian Couder <email@example.com> To: Josh Triplett <firstname.lastname@example.org> Cc: LKML <email@example.com>, git <firstname.lastname@example.org>, Linus Torvalds <email@example.com> Subject: Re: A note on the 5.12-rc1 tag Date: Fri, 5 Mar 2021 06:39:51 +0100 Message-ID: <CAP8UFD07ezNOXU5Q3RZAHOJGMjuaJY-R=x=hhQcQvYOAKzKF2g@mail.gmail.com> (raw) In-Reply-To: <YEFIXFyP5tWrPDMw@localhost> On Fri, Mar 5, 2021 at 1:58 AM Josh Triplett <firstname.lastname@example.org> wrote: > On Wed, Mar 03, 2021 at 12:53:18PM -0800, Linus Torvalds wrote: > > One additional reason for this note is that I want to not just warn > > people to not run this if you have a swapfile - even if you are > > personally not impacted (like I am, and probably most people are - > > swap partitions all around) - I want to make sure that nobody starts > > new topic branches using that 5.12-rc1 tag. I know a few developers > > tend to go "Ok, rc1 is out, I got all my development work into this > > merge window, I will now fast-forward to rc1 and use that as a base > > for the next release". Don't do it this time. It may work perfectly > > well for you because you have the common partition setup, but it can > > end up being a horrible base for anybody else that might end up > > bisecting into that area. > > Even if people avoid basing their topic branches on 5.12-rc1, it's still > possible for a future bisect to end up wandering to one of the existing > dangerous commits, if someone's trying to find a historical bug and git > happens to choose that as a halfway point. And if they happen to be > using a swap file, they could end up with serious data loss, years from > now when "5.12-rc1 is broken" isn't on the top of their mind or even > something they heard about originally. > > Would it make sense to add a feature to git that allows defining a > "dangerous" region for bisect? Rough sketch: > - Add a `/.git-bisect-dangerous` file to the repository, containing a > list of of commit range expressions (contains commit X, doesn't > contain commit Y) and associated messages ("Do not use these kernels > if you have a swap file; if you need to bisect into here, disable swap > files first"). > - git-bisect, as it navigates commits, always checks that file for any > commit it processes, and adds any new entries it sees into > `.git/bisect-dangerous`; it never removes entries from there. The `git bisect skip` machinery uses `refs/bisect/skip-<commit>` refs instead of such a file, so I wonder if such a file is needed. It could be used to store a map between skipped commits and the associated messages though. Or git notes could be used for that purpose. By the way I wonder what should happen if a commit is associated with a message by a `/.git-bisect-dangerous` file, but in another branch such file associates it with a different message. I guess all the different messages should be stored, and then displayed. > - git-bisect avoids choosing bisection points anywhere in that range > until it absolutely has to (because it's narrowed an issue to that > range). This can use something similar to the existing `git bisect > skip` machinery. Manual bisections print the message at that point. > Automated bisections (`git bisect run`) stop and print the range > without narrowing further, unless the user passes something like > `--dangerous-ok=commit-range`. Yeah, using the `git bisect skip` machinery looks like a good idea. Instead of `/.git-bisect-dangerous`, the file could actually be called `/.git-bisect-skip` and could also store ranges where the code doesn't compile, or completely misbehave, without necessarily being dangerous. The dangerous status would only be conveyed by the associated messages then. Another way could be to directly share some special refs similar to the existing `refs/bisect/skip-<commit>` refs, instead of a `/.git-bisect-dangerous` file. This would likely raise some issues about how to create and share these refs and the associated messages though. > (git notes would be nice for this, but they're hard to share reliably; > the above mechanism to accumulate entries from a file in the repo seems > simpler. I can imagine other possibilities.) If the notes are created automatically from the `/.git-bisect-skip` files and stored in `refs/notes/skip`, then they might not need to be shared. If people already share notes, they would just need to stop sharing those in `refs/notes/skip`. > Does something like this seem potentially reasonable, and worth doing to > help people avoid future catastrophic data loss? It seems reasonable as part of the skip mechanism.
next prev parent reply index Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-03 20:53 Linus Torvalds 2021-03-04 12:43 ` Pavel Machek 2021-03-04 13:23 ` Krzysztof Kozlowski 2021-03-04 17:57 ` Linus Torvalds 2021-03-06 12:54 ` Ingo Molnar 2021-03-04 15:00 ` Geert Uytterhoeven 2021-03-04 16:56 ` David Laight 2021-03-04 18:58 ` Geert Uytterhoeven 2021-03-05 9:14 ` David Laight 2021-03-04 20:51 ` Josh Triplett 2021-03-05 5:39 ` Christian Couder [this message] 2021-03-05 18:10 ` Junio C Hamano 2021-03-05 23:06 ` Josh Triplett 2021-03-05 23:38 ` 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='CAP8UFD07ezNOXU5Q3RZAHOJGMjuaJY-R=x=hhQcQvYOAKzKF2g@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git