# Re: Finding all commits which modify a file 2 messages from 2012-02-02 to 2012-02-02. Participants: Neal Groothuis, Junio C Hamano. Thread: https://gitlist.dev/t/29521 ## Neal Groothuis, 2012-02-02 14:55 Subject: Re: Finding all commits which modify a file Message-ID: <5456.38.96.167.131.1328194547.squirrel@mail.lo-cal.org> URL: https://gitlist.dev/e/5456.38.96.167.131.1328194547.squirrel%40mail.lo-cal.org ``` > "Neal Groothuis" writes: > >> Is there a situation where checking for TREESAMEness before >> simplification >> is desirable and checking after would not be? > > When you do not want to see a side branch that does not contribute to the end result at all, obviously ;-). Outside that situation, before or after should not make a difference, I would think. In that case, you wouldn't be using the --full-history flag at all, yeah? Right now, we can see where the file gets changed (A1), we just can't see where it gets changed back (B2). In fact, if I run git-log --full-history --simplify-merges foo.txt, it looks like A1 was the last thing to make changes to foo.txt, which seems misleading to me---history has been simplified to the point of not being true. ``` ## Junio C Hamano, 2012-02-02 19:13 Subject: Re: Finding all commits which modify a file Message-ID: <7vk445vyjn.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vk445vyjn.fsf%40alter.siamese.dyndns.org In-Reply-To: <5456.38.96.167.131.1328194547.squirrel@mail.lo-cal.org> ``` "Neal Groothuis" writes: >> "Neal Groothuis" writes: >> >>> Is there a situation where checking for TREESAMEness before >>> simplification >>> is desirable and checking after would not be? >> >> When you do not want to see a side branch that does not contribute to > the end result at all, obviously ;-). Outside that situation, before or > after should not make a difference, I would think. > > In that case, you wouldn't be using the --full-history flag at all, yeah? Yes. In case my tongue-in-cheek comment was too obscure, I was saying that I do not think the change to TREESAME-ness check you were alluding to would break any use case I would think of off the top of my head. We of course might discover undesired consequences in unexpected corners after we try your change, but I do not think we can discuss such corner cases further without seeing a patch. ```