{"thread":{"id":"29521","subject":"Re: Finding all commits which modify a file","startedAt":"2012-02-02T14:55:47Z","lastAt":"2012-02-02T19:13:32Z","messageCount":2,"participants":["Neal Groothuis","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"183607","messageId":"5456.38.96.167.131.1328194547.squirrel@mail.lo-cal.org","threadId":"29521","inReplyTo":null,"subject":"Re: Finding all commits which modify a file","fromName":"Neal Groothuis","fromEmail":"ngroot@lo-cal.org","sentAt":"2012-02-02T14:55:47Z","receivedAt":"2012-02-02T14:55:47Z","isPatch":false,"sender":{"key":"ngroot@lo-cal.org","avatar":null},"body":"> \"Neal Groothuis\" <ngroot@lo-cal.org> writes:\n>\n>> Is there a situation where checking for TREESAMEness before\n>> simplification\n>> is desirable and checking after would not be?\n>\n> When you do not want to see a side branch that does not contribute to\nthe end result at all, obviously ;-). Outside that situation, before or\nafter should not make a difference, I would think.\n\nIn that case, you wouldn't be using the --full-history flag at all, yeah?\n\nRight now, we can see where the file gets changed (A1), we just can't see\nwhere it gets changed back (B2).  In fact, if I run git-log --full-history\n--simplify-merges foo.txt, it looks like A1 was the last thing to make\nchanges to foo.txt, which seems misleading to me---history has been\nsimplified to the point of not being true.\n"},{"id":"183634","messageId":"7vk445vyjn.fsf@alter.siamese.dyndns.org","threadId":"29521","inReplyTo":"5456.38.96.167.131.1328194547.squirrel@mail.lo-cal.org","subject":"Re: Finding all commits which modify a file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-02T19:13:32Z","receivedAt":"2012-02-02T19:13:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Neal Groothuis\" <ngroot@lo-cal.org> writes:\n\n>> \"Neal Groothuis\" <ngroot@lo-cal.org> writes:\n>>\n>>> Is there a situation where checking for TREESAMEness before\n>>> simplification\n>>> is desirable and checking after would not be?\n>>\n>> When you do not want to see a side branch that does not contribute to\n> the end result at all, obviously ;-). Outside that situation, before or\n> after should not make a difference, I would think.\n>\n> In that case, you wouldn't be using the --full-history flag at all, yeah?\n\nYes. In case my tongue-in-cheek comment was too obscure, I was saying that\nI do not think the change to TREESAME-ness check you were alluding to would\nbreak any use case I would think of off the top of my head.\n\nWe of course might discover undesired consequences in unexpected corners\nafter we try your change, but I do not think we can discuss such corner\ncases further without seeing a patch.\n"}]}