Re: Following renames

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

Re: Following renames

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

Petr Baudis [off-list ref] writes:
quoted
No, it's the expected output just because you expected merges to always 
show up. Merges get ignored if any of the parents have the same content 
already.
Eek. Can I avoid that? What was the reason for choosing this behavior?
Perhaps rev-list --sparse?

Re: Following renames

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:42:22


On Sun, 26 Mar 2006, Junio C Hamano wrote:
Petr Baudis [off-list ref] writes:
quoted
quoted
No, it's the expected output just because you expected merges to always 
show up. Merges get ignored if any of the parents have the same content 
already.
Eek. Can I avoid that? What was the reason for choosing this behavior?
Perhaps rev-list --sparse?
No. "--sparse" still removes the uninteresting parents of merges. It just 
doesn't then make the linear history any denser.

		Linus

Re: Following renames

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

Linus Torvalds [off-list ref] writes:
No. "--sparse" still removes the uninteresting parents of merges. It just 
doesn't then make the linear history any denser.
Hmph, you are right.  add_parents_to_list() calls prune_fn
unconditionally while running limit_list().

Disabling that with yet another flag might be a possibility but
I suspect then it would not be much different from running
rev-list without path limiter and having the caller process the
result.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help