format-patch problem when using relative

format-patch problem when using relative

[Nikola Knežević]

Hi,

I have a subdirectory in my top-level directory, which I merged using  
subtree strategy. I want to send my patches upstream, so I did  
something like:
git format-patch -o patches -n --relative=click click/master myclick

This produced a bunch of files in patches directory, most of which are  
empty. When I tried this --stdout, I had something like this:
[PATCH 8725/8846]
[PATCH 8726/8846]
[PATCH 8750/8846]
..
[PATCH 8845/8846]

So, it seems that format-patch was counting all patches, but only  
printing the interesting ones.

I'm running git 1.6.0.1 on FreeBSD7/amd64.

PS. Please CC me, since I'm not on the list.

Cheers,
Nikola

Re: format-patch problem when using relative

[Jeff King]

On Wed, Nov 26, 2008 at 05:12:02PM +0100, Nikola Knežević wrote:

> git format-patch -o patches -n --relative=click click/master myclick
>
> This produced a bunch of files in patches directory, most of which are  
> empty. When I tried this --stdout, I had something like this:

Hmm. It seems that there is no history pruning done with --relative, so
you will still end up with commits that make no changes. However, this
is intentional. See cd676a51:

    diff --relative: output paths as relative to the current subdirectory
    [...]
     - This works not just with diff but also works with the log
       family of commands, but the history pruning is not affected.

       In other words, if you go to a subdirectory, you can say:

            $ git log --relative -p

       but it will show the log message even for commits that do not
       touch the current directory.  You can limit it by giving
       pathspec yourself:

            $ git log --relative -p .

       This originally was not a conscious design choice, but we
       have a way to affect diff pathspec and pruning pathspec
       independently.  IOW "git log --full-diff -p ." tells it to
       prune history to commits that affect the current subdirectory
       but show the changes with full context.  I think it makes
       more sense to leave pruning independent from --relative than
       the obvious alternative of always pruning with the current
       subdirectory, which would break the symmetry.

So I think what you really want is:

  git format-patch --relative=click click/master myclick -- click

to limit the path pruning to the 'click' directory.

-Peff

Re: format-patch problem when using relative

[Nikola Knežević]

On 26 Nov 2008, at 19:01 , Jeff King wrote:

> So I think what you really want is:
>
>  git format-patch --relative=click click/master myclick -- click
>
> to limit the path pruning to the 'click' directory.

Yes, that did the trick. Also, when I think about it, it makes sense -  
do checks relative to a path, but prune using path.

Thanks,
Nikola

Re: format-patch problem when using relative

[Björn Steinbrink]

On 2008.11.26 19:58:34 +0100, Nikola Knežević wrote:
> On 26 Nov 2008, at 19:01 , Jeff King wrote:
>
>> So I think what you really want is:
>>
>>  git format-patch --relative=click click/master myclick -- click
>>
>> to limit the path pruning to the 'click' directory.
>
> Yes, that did the trick. Also, when I think about it, it makes sense -  
> do checks relative to a path, but prune using path.

Ah, now that makes sense to me, too. You just didn't use the actual
command I told you on IRC ;-)

<doener> git format-patch --relative=click/ click/master click

That already had the path limiting "click" in it, I really meant "click"
there, not "myclick" ;-) I guess the confusion was caused by how
format-patch takes the range it's supposed to work on. If you only give
it a single committish, that is interpreted as "since". So the above is
equal to

git format-patch --relative=click/ click/master..HEAD click

Björn