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

Re: [RFC PATCH] Documentation: rev-list-options: clarify history simplification with paths

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Aug 10, 2008, 22:16 UTC
Message-ID
<alpine.LFD.1.10.0808101507510.3462@nehalem.linux-foundation.org>
In-Reply-To
<7v63q8353m.fsf@gitster.siamese.dyndns.org>
On Sun, 10 Aug 2008, Junio C Hamano wrote:
Show 6 quoted lines
> 
> Oh, I was not talking about revs.print_parents part, but about
> revs.rewrite_parents part.  What got Thomas puzzled about was exactly how
> the set of commits _shown_ are different with and without --parents, which
> sets both of these internal flags.  Your "pointless" argument applies to
> "print_parents" part, but "rewrite_parents" affects the resulting set.
Umm. Since --parents sets both, I don't see the point of that statement.

The fact is, --parents makes us show parenthood. That means that we need the merges to show up, otherwise the parenthood is meaningless.

So without "--parents", there is absolutely no point in showing the merges that don't have any other reason to be shown. And _with_ --parents, we need to show them because they matter for parenthood.

What's so confusing or hard to understand?

And yes, we now have split that "parents" flag into two separate flags internally, but that has absolutely _zero_ meaning for "--parents" itself, and it is totally irrelevant and meaningless to bring up that internal implementation issue and mentioning "print_parents" and "rewrite_parents".

They are immaterial to the actual argument, and the split-up happened because of the "--graph" flag, where we actually *do* show parents too, but we show them through the graph, not by printing the SHA1 of the parent. So the reason "rewrite_parents" is the one that affects the set of commits that get output is a small _internal_ implementation detail, and I really don't see what it has to do with anything at all.

So the fact is:
 - "rewrite_parents" is the flag that says that we are interested in 
   parenthood and keeping the graph consistent and dense.
   This very much implies showing merges that would otherwise not be 
   relevant.
 - "print_parents" is just a flag whether we should print the parent SHA1 
   or not. Nothing less, nothing more.
   This one has absolutely no relevance to whether a merge should be shown 
   or not, since it only affects the output _format_. It's related to 
   pretty-printing, not to anything else!

I really don't see what the confusion is all about. It's very straightforward and obvious.

			Linus
Previous: Junio C HamanoNext: Thomas Rast
Message 5 of 12 in “Documentation: rev-list-options: clarify history simplification with paths”
  1. Documentation: rev-list-options: clarify history simplification with pathsThomas Rast, Aug 10, 2008
  2. Junio C HamanoAug 10, 2008
  3. Linus TorvaldsAug 10, 2008
  4. Junio C HamanoAug 10, 2008
  5. Linus TorvaldsAug 10, 2008
  6. Thomas RastAug 10, 2008
  7. Junio C HamanoAug 11, 2008
  8. Junio C HamanoAug 11, 2008
  9. Thomas RastAug 11, 2008
  10. 1/3 Documentation: rev-list-options: Fix a typoThomas Rast, Aug 11, 2008
  11. 2/3 Documentation: rev-list-options: Rewrite simplification descriptions for clarityThomas Rast, Aug 11, 2008
  12. 3/3 Documentation: rev-list-options: move --simplify-merges documentationThomas Rast, Aug 11, 2008

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.