releng/tickets

Fork 2

mail-templates: adjust text about git #11272

Merged

jnsamyak merged 3 commits from git-text into main

2026-06-08 03:10:59 +00:00

zbyszek commented

2023-02-10 18:08:19 +00:00

Contributor

The text is reflown to 79 columns.

Signed-off-by: Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl

The text is reflown to 79 columns. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>

tmz commented

2023-02-10 18:16:46 +00:00

First-time contributor

I'm happy to see git pull --rebase stop being suggested. It's a rather circuitous (and potentially dangerous) way to pick up a new remote branch. Thanks!

IMO, 79 columns is a bit wide for email. Ideally, mail is under 72 or so columns, to allow for others to quote it and still stay less than 80 columns.

But if re-flowing is desired, that seems better done in a separate commit, likely applied to all of the templates. And maybe a README in the templates dir which denotes the desired column-width?

I'm happy to see `git pull --rebase` stop being suggested. It's a rather circuitous (and potentially dangerous) way to pick up a new remote branch. Thanks! IMO, 79 columns is a bit wide for email. Ideally, mail is under 72 or so columns, to allow for others to quote it and still stay less than 80 columns. But if re-flowing is desired, that seems better done in a separate commit, likely applied to all of the templates. And maybe a README in the templates dir which denotes the desired column-width?

churchyard commented

2023-02-11 16:55:42 +00:00

Contributor

The text is reflown to 79 columns.

This makes the change a tad hard to review. Could you please not mix that in the same commit?

> The text is reflown to 79 columns. This makes the change a tad hard to review. Could you please not mix that in the same commit?

ngompa commented

2023-02-11 17:54:03 +00:00

Member

The reason we recommend git pull --rebase is so that anything stored locally gets replayed on top in the event that a commit was done by someone else (mass build and branching events usually include that). Since we don't have force pushes, this ensures that we don't break something or randomly introduce merge commits.

The reason we recommend `git pull --rebase` is so that anything stored locally gets replayed on top in the event that a commit was done by someone else (mass build and branching events usually include that). Since we don't have force pushes, this ensures that we don't break something or randomly introduce merge commits.

tmz commented

2023-02-11 18:31:32 +00:00

First-time contributor

The reason we recommend git pull --rebase is so that anything stored locally gets replayed on top in the event that a commit was done by someone else (mass build and branching events usually include that). Since we don't have force pushes, this ensures that we don't break something or randomly introduce merge commits.

That's not relevant in this case. No one is arguing that we should recommend git pull instead of git pull --rebase. Rather, git fetch is all that is needed to pick up the new branch, with no other side-effects.

And as I wrote on the devel list here, git pull uses --ff-only by default these days, which is generally better than starting with git pull --rebase for most users. But the arguments/options to git pull aren't the core issue here.

> The reason we recommend `git pull --rebase` is so that anything stored locally gets replayed on top in the event that a commit was done by someone else (mass build and branching events usually include that). Since we don't have force pushes, this ensures that we don't break something or randomly introduce merge commits. That's not relevant in this case. No one is arguing that we should recommend `git pull` instead of `git pull --rebase`. Rather, `git fetch` is all that is needed to pick up the new branch, with no other side-effects. And as I wrote on the devel list [here](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GIGM4225NUZ5YZHKHGXGHJKE4422IWBQ/), `git pull` uses `--ff-only` by default these days, which is generally better than starting with `git pull --rebase` for most users. But the arguments/options to `git pull` aren't the core issue here.

zbyszek commented

2023-02-21 12:08:53 +00:00

Author

Contributor

rebased onto bc444875265a104e6880023a76643acf80119274

zbyszek commented

2023-02-21 12:09:35 +00:00

Author

Contributor

OK. I split this into three commits now:

the first one wraps the text to 72 characters.
the second one fixes various bits and pieces. It is separate to make review easier.
the third one has the actual change.

OK. I split this into three commits now: - the first one wraps the text to 72 characters. - the second one fixes various bits and pieces. It is separate to make review easier. - the third one has the actual change.

zbyszek commented

2023-02-21 12:11:18 +00:00

Author

Contributor

3 new commits added

mail-templates: adjust text about git
mail-templates: add missing punctuation and such
mail-templates: reflow text to 72 characters

**3 new commits added** * ``mail-templates: adjust text about git`` * ``mail-templates: add missing punctuation and such`` * ``mail-templates: reflow text to 72 characters``

tmz commented

2023-02-21 18:13:11 +00:00

First-time contributor

That looks great @zbyszek, thanks!

Very minor, there are a few stray characters in the commit body for the last commit:

'git pull --rebase' is a s a rather ...

s/ s a// :)

That looks great @zbyszek, thanks! Very minor, there are a few stray characters in the commit body for the last commit: > 'git pull --rebase' is a s a rather ... `s/ s a//` :)

zbyszek commented

2023-02-21 20:19:48 +00:00

Author

Contributor

3 new commits added

mail-templates: adjust text about git
mail-templates: add missing punctuation and such
mail-templates: reflow text to 72 characters

**3 new commits added** * ``mail-templates: adjust text about git`` * ``mail-templates: add missing punctuation and such`` * ``mail-templates: reflow text to 72 characters``

zbyszek commented

2023-02-21 20:19:54 +00:00

Author

Contributor

Update with just the commit message fix.

churchyard commented

2023-02-22 00:30:06 +00:00

Contributor

Looks good, thanks!

churchyard commented

2023-02-22 00:30:49 +00:00

Contributor

rebased onto 85827321087fe4bb64d4b94e2ab4aa3fc6afba9b

jwakely commented

2023-02-22 11:30:27 +00:00

First-time contributor

The reason we recommend git pull --rebase is so that anything stored locally gets replayed on top in the event that a commit was done by someone else (mass build and branching events usually include that).

But what has that got to do with the creation of the f38 branch?

Rebasing your local commits when there are upstream changes by other packagers is just entirely normal dist-git workflow, and nothing to do with branching from rawhide. Why should this email about branching be the place for general "how to git" info?

Since we don't have force pushes, this ensures that we don't break something or randomly introduce merge commits.

If we don't want merge commits, we should add a pre-receive hook to reject them. This email about branching is not the place to enforce that policy.

> The reason we recommend `git pull --rebase` is so that anything stored locally gets replayed on top in the event that a commit was done by someone else (mass build and branching events usually include that). But what has that got to do with the creation of the `f38` branch? Rebasing your local commits when there are upstream changes by other packagers is just entirely normal dist-git workflow, and nothing to do with branching from rawhide. Why should *this* email about branching be the place for general "how to git" info? > Since we don't have force pushes, this ensures that we don't break something or randomly introduce merge commits. If we don't want merge commits, we should add a pre-receive hook to reject them. This email about branching is not the place to enforce that policy.

jwakely commented

2023-02-22 11:31:39 +00:00

First-time contributor

Should "pending updates will be pushed ..." start a new sentence?