git/Documentation/git-rebase.adoc, branch main

rebase: support --trailer

2026-03-06T21:02:20Z

Add a new --trailer= option to git rebase to append trailer lines to each rewritten commit message (merge backend only). Because the apply backend does not provide a commit-message filter, reject --trailer when --apply is in effect and require the merge backend instead. This option implies --force-rebase so that fast-forwarded commits are also rewritten. Validate trailer arguments early to avoid starting an interactive rebase with invalid input. Add integration tests covering error paths and trailer insertion across non-interactive and interactive rebases. Signed-off-by: Li Chen Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

Merge branch 'ja/doc-misc-fixes'

2025-12-28T08:36:16Z

Various documentation fixes. * ja/doc-misc-fixes: doc: correct minor wording issues doc: fix asciidoc markup issues in several files

doc: correct minor wording issues

2025-12-20T05:55:43Z

* use imperative mood for consistency in options descriptions * add missing parenthesis * reword verbose phrase in git-repack.adoc Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

Merge branch 'kh/doc-committer-date-is-author-date'

2025-12-05T05:49:57Z

The "--committer-date-is-author-date" option of "git am/rebase" is a misguided one. The documentation is updated to discourage its use. * kh/doc-committer-date-is-author-date: doc: warn against --committer-date-is-author-date

doc: warn against --committer-date-is-author-date

2025-11-20T18:03:31Z

This option could create a commit history which violates the assumption that commits have non-decreasing commit timestamps. Warn against that in both git-am(1) and git-rebase(1). The genesis of this option is from git-am(1) and was added in 3f01ad66 (am: Add --committer-date-is-author-date option, 2009-01-22). The commit message doesn’t give us an example of a use case, but the thread starter does:[1] I've a big set of patches in a mbox file: there's sufficient info inside for git-am to work. Yet, each time I do import these, my sha1sums are changing because of different commit dates. I'd like to force the commit date to match the info/date from the time I received the email (and therefore always get back the right sha1sums). [1]: https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/ So the motivation was to treat git-am(1) as an import command that creates the same commit IDs. Putting aside the question of whether you should be using git-am(1) for importing commits, this approach is problematic: • you still need to apply the commits to the same base if you want the same hashes; and • you need the same committer. And if you expect the same committer, why is this person applying the same patches multiple times with the goal of making *identical* commits? That was all for git-am(1). It was added to git-rebase(1) in 570ccad3 (rebase: add options passed to git-am, 2009-03-18)[2] in order to plug options that could not be sent on to git-am(1). At this point the utility of the option graduated to making no sense; a use case for `git rebase --committer-date-is-author- date` is still yet to be found. Just warn against using this option on both commands and remind the user to consider whether they really need it. † 2: See also 7573cec5 (rebase -i: support --committer-date-is-author-date, 2020-08-17) for the commit for the merge backend Suggested-by: Johannes Sixt Signed-off-by: Kristoffer Haugsbakk Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

Merge branch 'je/doc-rebase'

2025-08-28T18:28:57Z

Documentation for "git rebase" has been updated. * je/doc-rebase: doc: git-rebase: update discussion of internals doc: git-rebase: move --onto explanation down doc: git rebase: clarify arguments syntax doc: git rebase: dedup merge conflict discussion doc: git-rebase: start with an example

doc: git-rebase: update discussion of internals

2025-08-23T16:03:30Z

- make it clearer that we're talking about a multistep process - give a more technically accurate description how rebase works with the merge backend. - condense the explanation of how git rebase skips commits with the same textual changes into a single bullet point and remove the explanatory diagram. Lots of things which are more complicated are already being explained without a diagram. - remove the explanation of how exactly `--fork-point` and `--root` work since that information is in the OPTIONS section - put all discussion of `ORIG_HEAD` inside the note Signed-off-by: Julia Evans Signed-off-by: Junio C Hamano

doc: git-rebase: move --onto explanation down

2025-08-23T16:03:29Z

There's a very clear explanation with examples of using --onto which is currently buried in the very long DESCRIPTION section. This moves it to its own section, so that we can reference the explanation from the `--onto` option by name. Signed-off-by: Julia Evans Signed-off-by: Junio C Hamano

doc: git rebase: clarify arguments syntax

2025-08-23T16:03:29Z

Remove duplicate explanation of `git rebase ` which is already explained above. Signed-off-by: Julia Evans Signed-off-by: Junio C Hamano

doc: git rebase: dedup merge conflict discussion

2025-08-23T16:03:29Z

Previously there were two explanations, this combines them both into a single explanation. Signed-off-by: Julia Evans Signed-off-by: Junio C Hamano