Re: [Possible GIT Bug]

2018-09-10 Thread Junio C Hamano
"Eckhard Maaß" 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,

Re: [Possible GIT Bug]

2018-09-10 Thread Eckhard Maaß
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

Re: [Possible GIT Bug]

2018-09-10 Thread Junio C Hamano
Jeff King 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

Re: [Possible GIT Bug]

2018-09-10 Thread Jeff King
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

Re: [Possible GIT Bug]

2018-09-09 Thread Bryan Turner
On Sun, Sep 9, 2018 at 6:31 AM Dylan Young 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

Fwd: [Possible GIT Bug]

2018-09-09 Thread Dylan Young
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

Re: Possible git bug

2013-08-14 Thread Jeff King
On Wed, Aug 14, 2013 at 07:42:11AM +0200, Daniel Knittl-Frank wrote: So would that be a bug? Or maybe a feature? I would like it that when you do a rebase and select no commits, it will rebase ontop of the commit you chose, and remove all the commits not shown in the interactive listing

Possible git bug

2013-08-13 Thread Hugh Davenport
Hey, Not sure if this is a bug or not. I commonly am finding myself wanting to remove some recent commits, either all or just a select few. So I use rebase in interactive mode for this. The problem I find is that when I do a rebase and leave no commits to pick (where I would think that this

Re: Possible git bug

2013-08-13 Thread Daniel Knittl-Frank
On Wed, Aug 14, 2013 at 6:50 AM, Hugh Davenport h...@davenport.net.nz wrote: Hey, Not sure if this is a bug or not. I commonly am finding myself wanting to remove some recent commits, either all or just a select few. So I use rebase in interactive mode for this. The problem I find is that