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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:45:08

Linus Torvalds [off-list ref] writes:
On Sun, 10 Aug 2008, Junio C Hamano wrote:
quoted
Personally I do not think --full-history without --parents is of much
usefulness (I'd let Linus or somebody else defend this usage, or make it
imply revs.rewrite_parents otherwise).  If you remove that case from your
set of experiments in the equation, do the rest of the results make sense?
Oh, it's _very_ useful.

The most common case is "git whatchanged". It's useful to find a commit 
that did some change _without_ any graphical front-end. 

And then the merges and parenthood are totally pointless - no human can 
try to tie things together in their head _anyway_, so why show them? You 
just want to find the change.
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.

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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:45:08


On Sun, 10 Aug 2008, Junio C Hamano wrote:
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help