* Fwd: [Possible GIT Bug] [not found] <CAPGJNu5RPXjeib-vayVzmFkU9cZ=h5o5VDoM1vQqv2+HgtNXLw@mail.gmail.com> @ 2018-09-09 13:30 ` Dylan Young 2018-09-09 19:04 ` Bryan Turner 0 siblings, 1 reply; 6+ messages in thread From: Dylan Young @ 2018-09-09 13:30 UTC (permalink / raw) To: git Works: git show -C --find-copies-harder 055f6c89fa4506037d1621761f13430f469b8029 git show -C --find-copies-harder 055f6c89fa4506037d1621761f13430f469b8029 --name-status Doesn’t Work: git show -C --find-copies-harder 055f6c89fa4506037d1621761f13430f469b8029 -- PATH_TO_MY_COPIED_FILE i.e. --- /dev/null +++ b/ PATH_TO_MY_COPIED_FILE Hope that’s self-explanatory!!! Best, Casey Meijer ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Possible GIT Bug] 2018-09-09 13:30 ` Fwd: [Possible GIT Bug] Dylan Young @ 2018-09-09 19:04 ` Bryan Turner 2018-09-10 13:24 ` Jeff King 0 siblings, 1 reply; 6+ messages in thread From: Bryan Turner @ 2018-09-09 19:04 UTC (permalink / raw) To: dylanyoungmeijer; +Cc: Git Users On Sun, Sep 9, 2018 at 6:31 AM Dylan Young <dylanyoungmeijer@gmail.com> wrote: > > Works: > > git show -C --find-copies-harder 055f6c89fa4506037d1621761f13430f469b8029 > > git show -C --find-copies-harder > 055f6c89fa4506037d1621761f13430f469b8029 --name-status Here, because you didn't provide _any_ paths, Git is allowed to consider all of the paths modified in the commit and, because you specified --find-copies-harder, it's allowed to consider paths that _weren't_ modified too. That means it can "see" both the source and destination for the copy, and it detects the copy as you're expecting. > > Doesn’t Work: > > git show -C --find-copies-harder > 055f6c89fa4506037d1621761f13430f469b8029 -- PATH_TO_MY_COPIED_FILE Here, though, you've _explicitly limited_ Git to only the copied file. It's not allowed to consider any others, which means it can't "see" the source path anymore. As a result, the copy is detected as a straight add. Note that --find-copies-harder means the diff machinery is allowed to consider files that weren't modified in the commit as possible sources for copies, but that's still subject to your explicit filtering. In other words, if PATH_TO_SOURCE_FILE wasn't modified, running this would _not_ see a copy: git show -C 055f6c89fa4506037d1621761f13430f469b8029 -- PATH_TO_MY_COPIED_FILE PATH_TO_SOURCE_FILE But running this would: git show -C -C 055f6c89fa4506037d1621761f13430f469b8029 -- PATH_TO_MY_COPIED_FILE PATH_TO_SOURCE_FILE No bugs here. Everything is working as intended, if not, perhaps, as you expected. Hope this helps, Bryan > > i.e. > > --- /dev/null > > +++ b/ PATH_TO_MY_COPIED_FILE > > Hope that’s self-explanatory!!! > > Best, > Casey Meijer ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Possible GIT Bug] 2018-09-09 19:04 ` Bryan Turner @ 2018-09-10 13:24 ` Jeff King 2018-09-10 16:03 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: Jeff King @ 2018-09-10 13:24 UTC (permalink / raw) To: Bryan Turner; +Cc: dylanyoungmeijer, Git Users On Sun, Sep 09, 2018 at 12:04:58PM -0700, Bryan Turner wrote: > Here, though, you've _explicitly limited_ Git to only the copied file. > It's not allowed to consider any others, which means it can't "see" > the source path anymore. As a result, the copy is detected as a > straight add. Note that --find-copies-harder means the diff machinery > is allowed to consider files that weren't modified in the commit as > possible sources for copies, but that's still subject to your explicit > filtering. In other words, if PATH_TO_SOURCE_FILE wasn't modified, > running this would _not_ see a copy: > > git show -C 055f6c89fa4506037d1621761f13430f469b8029 -- > PATH_TO_MY_COPIED_FILE PATH_TO_SOURCE_FILE > > But running this would: > > git show -C -C 055f6c89fa4506037d1621761f13430f469b8029 -- > PATH_TO_MY_COPIED_FILE PATH_TO_SOURCE_FILE > > No bugs here. Everything is working as intended, if not, perhaps, as > you expected. Your explanation is correct. To be fair, though, it seems like --find-copies-harder is made a lot less useful by the not considering the larger set of sources, since that's kind of its point. I'm not sure if this behavior actually is intentional, or simply what happens to occur based on the combination of features. You can do: git log -C C --full-diff $commit -- $path to limit a traversal to commits touching $path, but still see the full diff (including possible copy sources). But AFAIK there's no option to limit the diff, but include extra copy sources. I'd be tempted to say we should do that automatically when --find-copies-harder is in effect, but it's possible that some people actually do want the current behavior. For a single path it's silly, but if you did something like this: git show -C -C $commit -- foo/ that would find differences in the foo/ directory, and find copies only from sources in foo/. That limits the result, but also limits the effort, which can be important given the cost of copy detection. -Peff ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Possible GIT Bug] 2018-09-10 13:24 ` Jeff King @ 2018-09-10 16:03 ` Junio C Hamano 2018-09-10 17:35 ` Eckhard Maaß 0 siblings, 1 reply; 6+ messages in thread From: Junio C Hamano @ 2018-09-10 16:03 UTC (permalink / raw) To: Jeff King; +Cc: Bryan Turner, dylanyoungmeijer, Git Users Jeff King <peff@peff.net> writes: > Your explanation is correct. To be fair, though, it seems like > --find-copies-harder is made a lot less useful by the not considering > the larger set of sources, since that's kind of its point. I'm not sure > if this behavior actually is intentional, or simply what happens to > occur based on the combination of features. It is neither but if I have to pick one between the two, it is much closer to the former than the latter. The primary source of this is that we have only *one* pathspec given to the diff machinery, but in order to implement your ideal "find harder", you'd need *two*. That is, one set of paths for which you are interested in their origin, and the other set that you allow the machinery to consider as possible origins. Since we can only give one pathspec machinery, that one pathspec is used to specify both of these sets. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Possible GIT Bug] 2018-09-10 16:03 ` Junio C Hamano @ 2018-09-10 17:35 ` Eckhard Maaß 2018-09-10 18:37 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: Eckhard Maaß @ 2018-09-10 17:35 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeff King, Bryan Turner, dylanyoungmeijer, Git Users On Mon, Sep 10, 2018 at 09:03:10AM -0700, Junio C Hamano wrote: > It is neither but if I have to pick one between the two, it is much > closer to the former than the latter. The primary source of this is > that we have only *one* pathspec given to the diff machinery, but in > order to implement your ideal "find harder", you'd need *two*. That > is, one set of paths for which you are interested in their origin, > and the other set that you allow the machinery to consider as possible > origins. Since we can only give one pathspec machinery, that one > pathspec is used to specify both of these sets. How does tihs compare to `--follow`? With that knob active the machinery indeed uses the whole repository for finding renames and/or copies. Is this the only exception then? Take care, Eckhard ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Possible GIT Bug] 2018-09-10 17:35 ` Eckhard Maaß @ 2018-09-10 18:37 ` Junio C Hamano 0 siblings, 0 replies; 6+ messages in thread From: Junio C Hamano @ 2018-09-10 18:37 UTC (permalink / raw) To: Eckhard Maaß; +Cc: Jeff King, Bryan Turner, dylanyoungmeijer, Git Users "Eckhard Maaß" <eckhard.s.maass@googlemail.com> writes: > On Mon, Sep 10, 2018 at 09:03:10AM -0700, Junio C Hamano wrote: >> It is neither but if I have to pick one between the two, it is much >> closer to the former than the latter. The primary source of this is >> that we have only *one* pathspec given to the diff machinery, but in >> order to implement your ideal "find harder", you'd need *two*. That >> is, one set of paths for which you are interested in their origin, >> and the other set that you allow the machinery to consider as possible >> origins. Since we can only give one pathspec machinery, that one >> pathspec is used to specify both of these sets. > > How does tihs compare to `--follow`? With that knob active the machinery > indeed uses the whole repository for finding renames and/or copies. Is > this the only exception then? '--follow' is a checkbox hack that is not even properly integrated with the diff machinery (it only exists on the "log" side of the tool), so I do not think it is productive to find a comparison. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-09-10 18:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAPGJNu5RPXjeib-vayVzmFkU9cZ=h5o5VDoM1vQqv2+HgtNXLw@mail.gmail.com>
2018-09-09 13:30 ` Fwd: [Possible GIT Bug] Dylan Young
2018-09-09 19:04 ` Bryan Turner
2018-09-10 13:24 ` Jeff King
2018-09-10 16:03 ` Junio C Hamano
2018-09-10 17:35 ` Eckhard Maaß
2018-09-10 18:37 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).