"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,
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 yo
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 t
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 -
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 to
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
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 li
On Wed, Aug 14, 2013 at 6:50 AM, Hugh Davenport 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 when I do a rebase
>
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 wo
9 matches
Mail list logo
