git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Let format-patch and rebase ignore trivial merges.

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 17, 2009, 22:44 UTC
Message-ID
<7vaaxhfcfe.fsf@alter.siamese.dyndns.org>
In-Reply-To
<4B29106C.1040501@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
Show 10 quoted lines
> Please do not set Mail-Followup-To (and use reply-to-all to keep the Cc list).
>
> Bernhard R. Link schrieb:
>> --prune-tree makes rev-list without paths equivalent to
>> "git rev-list $options -- ." (or .. or ../.. and so on,
>> if you are in some subdirectory).
>> This is the new default for format-patch and rebase
>
> Why do you need a new option when you can just add "-- ." to the rev-list
> invocation?

I agree that --[no-]prune-tree options are unnecessary. The patch to builtin-log.c, the second hunk to revision.c, and revision.h would be sufficient and all others should be dropped. Instead, the shell script Porcelains can simply add "-- ." at the end of their rev-list invocations.

That way, we don't have to add anything to the documentation either.

But I wonder if it is an indication of something screwy in the workflow, if a branch that merges others with "-s ours" is where the patches for upstream submission is taken from with format-patch, or what is rebased and internally gets its patches extracted with format-patch.

A branch that merges with "-s ours" is typically done so that others can pull and build against (and "-s ours" is used to cauterize the history of a bad side branch), and good bits merged into it would also have come from a different clean branch that is merged into that branch. It might make more sense to format-patch that clean branch when preparing for upstream submission, than the "aggregated mesh of commits" branch with "-s ours" fix-ups.

On the other hand, a branch that will be rebased to keep up with others is by definition private, and I don't see a reason to mark with "-s ours" to cauterize history of an unrelated side branch that tried to do something similar to what the branch is trying to achieve in that setting. You can instead ignore such a side branch and not merge with it. So I don't know how a sane history you are going to rebase ends up containing a "-s ours" merge to begin with.

Previous: Bernhard R. LinkNext: Bernhard R. Link
Message 6 of 11 in “Let format-patch and rebase ignore trivial merges.”
  1. Let format-patch and rebase ignore trivial merges.Bernhard R. Link, Dec 16, 2009
  2. Johannes SixtDec 16, 2009
  3. Bernhard R. LinkDec 17, 2009
  4. Johannes SixtDec 17, 2009
  5. Bernhard R. LinkDec 17, 2009
  6. Junio C HamanoDec 17, 2009
  7. Bernhard R. LinkDec 18, 2009
  8. Johannes SixtDec 18, 2009
  9. Bernhard R. LinkDec 18, 2009
  10. Let format-patch and rebase ignore trivial merges.Bernhard R. Link, Dec 18, 2009
  11. Junio C HamanoDec 18, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.