Re: A note on the 5.12-rc1 tag

[Christian Couder]

On Fri, Mar 5, 2021 at 1:58 AM Josh Triplett  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-` 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-` 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.

Re: [ANNOUNCE] Git v2.30.0-rc2

[Christian Couder]

Most of the suggestions below are found by GMail.

On Thu, Dec 24, 2020 at 12:08 AM Junio C Hamano  wrote:
>
> A release candidate Git v2.30.0-rc2 is now available for testing
> at the usual places.  It is comprised of 19 non-merge commits since

Maybe: s/is comprised of/comprises/

> v2.30.0-rc1, contributed by 5 people, none of which are new faces.

[..]

>  * Various subcommands of "git config" that takes value_regex

s/takes/take/

>learn the "--literal-value" option to take the value_regex option

s/learn/learned/

>as a literal string.

[...]

> * More preliminary tests have been added to document desired outcome

s/outcome/outcomes/

>   of various "directory rename" situations.

[...]

>  * The code to see if "git stash drop" can safely remove refs/stash
>has been made more carerful.

s/carerful/careful/

>(merge 4f44c5659b rs/empty-reflog-check-fix later to maint).

[...]

>  * Since jgit does not yet work with SHA-256 repositories, mark the
>tests that uses it not to run unless we are testing with ShA-1

s/uses/use/

>repositories.
>(merge ea699b4adc sg/t5310-jgit-wants-sha1 later to maint).

[...]

>  * "git apply" adjusted the permission bits of working-tree files and
>directories according core.sharedRepository setting by mistake and

s/according/according to/

>for a long time, which has been corrected.
>(merge eb3c027e17 mt/do-not-use-scld-in-working-tree later to maint).

[...]

>  * "git pack-redandant" when there is only one packfile used to crash,

s/pack-redandant/pack-redundant/

>which has been corrected.
>(merge 0696232390 jx/pack-redundant-on-single-pack later to maint).

Re: [ANNOUNCE] Git v2.14.0-rc0

[Christian Couder]

On Sat, Jul 15, 2017 at 1:17 AM, Ævar Arnfjörð Bjarmason
 wrote:
>
> On Thu, Jul 13 2017, Junio C. Hamano jotted:

>>  * "git send-email" learned to overcome some SMTP server limitation
>>that does not allow many pieces of e-mails to be sent over a single
>>session.
>
> Makes it sound like it does that automatically, also "pieces of e-mails"
> and "sent over" is odd, maybe:
>
> * "git send-email" now has --batch-size and --relogin-delay options
>which can be used to overcome limitations on SMTP servers that have
>limits on how many of e-mails can be sent in a single session.

Maybe s/that have limits on how/that restrict how/

Re: [ANNOUNCE] Git v2.14.0-rc0

[Christian Couder]

On Sat, Jul 15, 2017 at 1:17 AM, Ævar Arnfjörð Bjarmason
 wrote:
>
> On Thu, Jul 13 2017, Junio C. Hamano jotted:

>>  * "git send-email" learned to overcome some SMTP server limitation
>>that does not allow many pieces of e-mails to be sent over a single
>>session.
>
> Makes it sound like it does that automatically, also "pieces of e-mails"
> and "sent over" is odd, maybe:
>
> * "git send-email" now has --batch-size and --relogin-delay options
>which can be used to overcome limitations on SMTP servers that have
>limits on how many of e-mails can be sent in a single session.

Maybe s/that have limits on how/that restrict how/

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Christian Couder]

On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
 wrote:
> On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> [snip]
>>
>> I'd welcome any feedback, whether on the interface and workflow, the
>> internals and collaboration, ideas on presenting diffs of patch series,
>> or anything else.
>
> This looks awesome!
>
> I've been working on some similar stuff for a while also.[1][2]
>
> I'm particularly interested in trying to establish a standard for
> storing review data in git. I've got a prototype for doing that[3],
> and an example tool that uses it[4]. The tool is still incomplete/buggy 
> though.

There is also git-appraise (https://github.com/google/git-appraise)
written in Go to store code review data in Git.
It looks like it stores its data in git notes and can be integrated
with Rust (https://github.com/Nemo157/git-appraise-rs).

> There seem to be a number of us trying to solve this in our different ways,
> it would be great to coordinate our efforts.

Yeah, I agree.

Re: [ANNOUNCE] git-series: track changes to a patch series over time

[Christian Couder]

On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
 wrote:
> On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> [snip]
>>
>> I'd welcome any feedback, whether on the interface and workflow, the
>> internals and collaboration, ideas on presenting diffs of patch series,
>> or anything else.
>
> This looks awesome!
>
> I've been working on some similar stuff for a while also.[1][2]
>
> I'm particularly interested in trying to establish a standard for
> storing review data in git. I've got a prototype for doing that[3],
> and an example tool that uses it[4]. The tool is still incomplete/buggy 
> though.

There is also git-appraise (https://github.com/google/git-appraise)
written in Go to store code review data in Git.
It looks like it stores its data in git notes and can be integrated
with Rust (https://github.com/Nemo157/git-appraise-rs).

> There seem to be a number of us trying to solve this in our different ways,
> it would be great to coordinate our efforts.

Yeah, I agree.

Re: [PATCH] apply: refuse touching a file beyond symlink

[Christian Couder]

On Thu, Jan 29, 2015 at 9:45 PM, Junio C Hamano  wrote:
>
> Instead, for any patch in the input that leaves a path (i.e. a non
> deletion) in the result, we check all leading paths against interim
> result and then either the index or the working tree.  The interim
> results of applying patches are kept track of by fn_table logic for
> us already, so use it to fiture out if existing a symbolic link will

s/fiture/figure/
s/existing a symbolic link/an existing symbolic link/

> cause problems, if a new symbolic link that will cause problems will
> appear, etc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] apply: refuse touching a file beyond symlink

[Christian Couder]

On Thu, Jan 29, 2015 at 9:45 PM, Junio C Hamano gits...@pobox.com wrote:

 Instead, for any patch in the input that leaves a path (i.e. a non
 deletion) in the result, we check all leading paths against interim
 result and then either the index or the working tree.  The interim
 results of applying patches are kept track of by fn_table logic for
 us already, so use it to fiture out if existing a symbolic link will

s/fiture/figure/
s/existing a symbolic link/an existing symbolic link/

 cause problems, if a new symbolic link that will cause problems will
 appear, etc.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] Git v1.8.5-rc1

[Christian Couder]

On Thu, Nov 7, 2013 at 12:57 AM, Junio C Hamano  wrote:
>
>  * "git replace" helper no longer allows an object to be replaced with
>another object of a different type to avoid confusion (you can
>still manually craft such replacement using "git update-ref", as an
>escape hatch).

Maybe it would be more helpful to say "you can still do that using the
--force option" instead of pointing people to "git update-ref".

Thanks,
Christian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] Git v1.8.5-rc1

[Christian Couder]

On Thu, Nov 7, 2013 at 12:57 AM, Junio C Hamano gits...@pobox.com wrote:

  * git replace helper no longer allows an object to be replaced with
another object of a different type to avoid confusion (you can
still manually craft such replacement using git update-ref, as an
escape hatch).

Maybe it would be more helpful to say you can still do that using the
--force option instead of pointing people to git update-ref.

Thanks,
Christian.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] commit: Add -f, --fixes option to add Fixes: line

[Christian Couder]

[Sorry I already sent the reply below to Johan only instead of everyone.]

Hi Johan,

On Sun, Oct 27, 2013 at 11:59 AM, Johan Herland  wrote:
> On Sun, Oct 27, 2013 at 10:20 AM, Josh Triplett  wrote:
>>
>> ...good suggestion:
>>
>> ~/src/linux$ git log --grep='stable@' --oneline --since='1 year ago' | wc -l
>> 2769
>> ~/src/linux$ git log --grep='stable@' --oneline --since='1 year ago' 
>> --pretty=format:%an | sort -u | wc -l
>> 839
>>
>> Several thousand commits per year by hundreds of unique people seems
>> like enough to justify a short option.
>
> I think this can be solved just as well (if not better) using a
> combination of a commit message template (or a prepare-commit-msg
> hook) and a commit-msg hook.

Your suggestion is very good, and it is not incompatible with command
line options.
So both could be implemented and even work together.

For example if "-f ack:Peff" was passed to the command line, "git commit" could
lookup in the commit message template and see if there is one
RFC822-style header
that starts with or contains "ack" (discarding case) and it could look
in some previous commits if
there is an author whose name contains "Peff" (discarding case) and if
it is the case
it could append the following to the bottom of the commit message:

Fixes:
Reported-by:
Suggested-by:
Improved-by:
Acked-by: Jeff King 
Reviewed-by:
Tested-by:
Signed-off-by: Myself 

(I suppose that the sob is automatically added.)

It would work also with "-f fix:security-bug" and would put something
like what you suggested:

Fixes: 1234beef56 (Commit message summmary)

> Then, the commit-msg hook can clean up and transform this into the
> final commit message:
>
>   My commit subject
>
>   This is the commit message body.
>
>   Fixes: 1234beef56 (Commit message summmary)
>   Reported-by: Joe User 
>   Improved-by: Joe Hacker 
>   Tested-by: Joe Tester 
>   Signed-off-by: Myself 
>
> Here, the commit-msg hook removes the fields that were not filled in,
> and performs additional filtering on the "Fixes" line (Adding commit
> message summary). The filtering could also resolve ref names, so that
> if you had refs/tags/security-bug pointing at the buggy commit, then:
>
>   Fixes: security-bug
>
> would be expanded/DWIMed into:
>
>   Fixes: 1234beef56 (Commit message summmary)
>
> Obviously, any other fancy processing you want to do into in the
> commit-msg hook can be done as well, adding footnotes, checking that
> commits are present in the ancestry, etc, etc.

Yeah, the commit message hook could do some more processing if the
user adds or changes stuff.

> Three good reasons to go this way:
>
>  1. If the user forgets to supply command-line options like -s,
> --fixes, etc, there is a nice reminder in the supplied form.

Great!

>  2. No need to add any command-line options to Git.

This is not a good reason. If many users prefer a command line option,
why not let them use that?

>  3. The whole mechanism is controlled by the project. The kernel folks
> can do whatever they want in their templates/hooks without needing
> changes to the Git project.

The Git project already manages sob lines. It would be a good thing if
it could manage
more of this stuff to help users in a generic way while taking care of
user preferences.

Best regards,
Christian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] commit: Add -f, --fixes commit option to add Fixes: line

[Christian Couder]

[Sorry I already sent the reply below to Johan only instead of everyone.]

Hi Johan,

On Sun, Oct 27, 2013 at 11:59 AM, Johan Herland jo...@herland.net wrote:
 On Sun, Oct 27, 2013 at 10:20 AM, Josh Triplett j...@joshtriplett.org wrote:

 ...good suggestion:

 ~/src/linux$ git log --grep='stable@' --oneline --since='1 year ago' | wc -l
 2769
 ~/src/linux$ git log --grep='stable@' --oneline --since='1 year ago' 
 --pretty=format:%an | sort -u | wc -l
 839

 Several thousand commits per year by hundreds of unique people seems
 like enough to justify a short option.

 I think this can be solved just as well (if not better) using a
 combination of a commit message template (or a prepare-commit-msg
 hook) and a commit-msg hook.

Your suggestion is very good, and it is not incompatible with command
line options.
So both could be implemented and even work together.

For example if -f ack:Peff was passed to the command line, git commit could
lookup in the commit message template and see if there is one
RFC822-style header
that starts with or contains ack (discarding case) and it could look
in some previous commits if
there is an author whose name contains Peff (discarding case) and if
it is the case
it could append the following to the bottom of the commit message:

Fixes:
Reported-by:
Suggested-by:
Improved-by:
Acked-by: Jeff King p...@peff.net
Reviewed-by:
Tested-by:
Signed-off-by: Myself mys...@example.com

(I suppose that the sob is automatically added.)

It would work also with -f fix:security-bug and would put something
like what you suggested:

Fixes: 1234beef56 (Commit message summmary)

 Then, the commit-msg hook can clean up and transform this into the
 final commit message:

   My commit subject

   This is the commit message body.

   Fixes: 1234beef56 (Commit message summmary)
   Reported-by: Joe User j.u...@example.com
   Improved-by: Joe Hacker j.hac...@example.com
   Tested-by: Joe Tester j.tes...@example.com
   Signed-off-by: Myself mys...@example.com

 Here, the commit-msg hook removes the fields that were not filled in,
 and performs additional filtering on the Fixes line (Adding commit
 message summary). The filtering could also resolve ref names, so that
 if you had refs/tags/security-bug pointing at the buggy commit, then:

   Fixes: security-bug

 would be expanded/DWIMed into:

   Fixes: 1234beef56 (Commit message summmary)

 Obviously, any other fancy processing you want to do into in the
 commit-msg hook can be done as well, adding footnotes, checking that
 commits are present in the ancestry, etc, etc.

Yeah, the commit message hook could do some more processing if the
user adds or changes stuff.

 Three good reasons to go this way:

  1. If the user forgets to supply command-line options like -s,
 --fixes, etc, there is a nice reminder in the supplied form.

Great!

  2. No need to add any command-line options to Git.

This is not a good reason. If many users prefer a command line option,
why not let them use that?

  3. The whole mechanism is controlled by the project. The kernel folks
 can do whatever they want in their templates/hooks without needing
 changes to the Git project.

The Git project already manages sob lines. It would be a good thing if
it could manage
more of this stuff to help users in a generic way while taking care of
user preferences.

Best regards,
Christian.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/