[PATCH] Update SubmittingPatches.

- It does not matter how I read git list. What matters is that I do not necessarily read everything on it. - Talk a bit about how to use applymbox to check one's own patches. - Talk a bit about PGP signed patches. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- * Strictly speaking

Re: [PATCH 1/9] Fix git patch header processing in git-apply.

Thanks for "apply" patches. I have merged some of them and pushed out. I further wanted to apply the following to the proposed updates branch, but even with only the first one applied, it fails its own test, t4104-apply-complex.sh: * Fix processing of a patch file which modifies the same file in

Re: [PATCH 3/9] Fix processing of a patch file which modifies the same file in git-apply.

Robert Fitzsimons <[EMAIL PROTECTED]> writes: > A patch file (or stdin) which modifies the same file more then once > will fail to apply the patch correctly. In the worst case it will > apply some of the patch and leave an invalid output file(s). I am not sure if this is solving the right proble

Re: [PATCH 5/9] New option --force-delete for git-apply.

Robert Fitzsimons <[EMAIL PROTECTED]> writes: > Allow the user to force a patch that deletes a file to succeed even > though the file might still contain data. Added a test case. Why? I've seen cases where git-apply incorrectly thinks a patch leaves some data in a file to be deleted, when incom

Re: [PATCH] git-repack-script: Add option to repack all objects

Frank Sorenson <[EMAIL PROTECTED]> writes: > This patch adds an option to git-repack-script to repack all objects, > including both packed and unpacked. This allows a full repack of > a git archive (current cogito packs from 39MB to 4.5MB, and git packs > from 4.4MB to 3.8MB). > > Signed-off-by:

Re: [PATCH 6/9] New option --ignore-whitespace for git-apply.

Robert Fitzsimons <[EMAIL PROTECTED]> writes: > Allow the user to force a patch to be applied even though there might > be whitespace differences. Added a test case for the new option. It might be worth doing fuzz in general, but treating whitespace-only fuzz specially is a good idea, since they

Re: [PATCH 6/9] New option --ignore-whitespace for git-apply.

Linus Torvalds wrote: On Sun, 28 Aug 2005, Robert Fitzsimons wrote: Allow the user to force a patch to be applied even though there might be whitespace differences. Added a test case for the new option. If you ignore whitespace, then you should probably accept patches that are whitespace corr

Re: [PATCH] Spell __attribute__ correctly in cache.h.

On Sun, 28 Aug 2005, Antti-Juhani Kaijanaho wrote: > > This is not true under C99. If an array[] is the last member of a > struct (which is what we are, AFAIK, talking about), then sizeof that > struct is defined and gives the size of that struct as if the array's > size were zero (but the stru

Re: [PATCH] Spell __attribute__ correctly in cache.h.

Linus Torvalds wrote: > But using "array[]" means that "sizeof()" no longer works, and then you > have to use "offsetof()", which is a big pain. This is not true under C99. If an array[] is the last member of a struct (which is what we are, AFAIK, talking about), then sizeof that struct is defin

Re: [PATCH] Spell __attribute__ correctly in cache.h.

On Sun, 28 Aug 2005, Jason Riedy wrote: > > I'm fine with requiring a limited C99 compiler. A > pedantic compiler will reject members with a length > of zero. 6.7.5.2 para1 requires a value greater than > zero for a constant array size. So the code now (with > [0] decls) is neither C89 nor C9

Re: [PATCH] Spell __attribute__ correctly in cache.h.

And Junio C Hamano writes: - > +Replace C99 array initializers with code. - I presume this is to help older compilers? Yes, so it's relatively unimportant. I could work around it in my situation; I only included it because it's "necessary" for some Sun compilers on older Solaris installat

Re: [PATCH 6/9] New option --ignore-whitespace for git-apply.

On Sun, 28 Aug 2005, Robert Fitzsimons wrote: > > Allow the user to force a patch to be applied even though there might > be whitespace differences. Added a test case for the new option. If you ignore whitespace, then you should probably accept patches that are whitespace corrupted in another w

Re: [PATCH 2/9] Fix detection of files with only one line in git-apply.

On Sun, 28 Aug 2005, Robert Fitzsimons wrote: > > A patch which added one line to an empty file or removed the only line > from a one line file would be incorrectly detected as an invalid new > or delete patch. Added a new test case. This patch looks wrong or at least needs some more thought. T

[PATCH 9/9] New git-apply test cases for scanning forwards and backwards.

Added a new test case for the scanning forwards and backwards for the correct location to apply a patch fragment. Signed-off-by: Robert Fitzsimons <[EMAIL PROTECTED]> --- t/t4110-apply-scan.sh | 101 + 1 files changed, 101 insertions(+), 0 deleti

[PATCH 8/9] New git-apply test cases for patches with mulitple fragments.

Added a test case for patches with multiple fragments. Signed-off-by: Robert Fitzsimons <[EMAIL PROTECTED]> --- t/t4109-apply-multifrag.sh | 176 1 files changed, 176 insertions(+), 0 deletions(-) create mode 100644 t/t4109-apply-multifrag.sh 28b4

[PATCH 7/9] New option --ignore-applied for git-apply.

Allow the user to allow a patch which has some hunks (fragments) already applied to succeed. Added test case and documentation. Signed-off-by: Robert Fitzsimons <[EMAIL PROTECTED]> --- Documentation/git-apply.txt |6 ++ apply.c | 12 + t/t4108-apply-ignore

[PATCH 6/9] New option --ignore-whitespace for git-apply.

Allow the user to force a patch to be applied even though there might be whitespace differences. Added a test case for the new option. Signed-off-by: Robert Fitzsimons <[EMAIL PROTECTED]> --- Documentation/git-apply.txt|7 +++- apply.c| 38

[PATCH 5/9] New option --force-delete for git-apply.

Allow the user to force a patch that deletes a file to succeed even though the file might still contain data. Added a test case. Signed-off-by: Robert Fitzsimons <[EMAIL PROTECTED]> --- Documentation/git-apply.txt |8 +- apply.c | 12 - t/t4106-apply-for

[PATCH 4/9] Fix the procssing of multiple patch files with --check in git-apply.

When the --check option was used with multiple patch files which modify the same files, the patch can fail because the previously modified contents aren't written to the disk. So save the in memory patch contents across the processing of multiple patch files. Added a new test case for --check wit

[PATCH 3/9] Fix processing of a patch file which modifies the same file in git-apply.

A patch file (or stdin) which modifies the same file more then once will fail to apply the patch correctly. In the worst case it will apply some of the patch and leave an invalid output file(s). apply.c has been changed to search for previously processed files and use the in memory copy of the da

[PATCH 2/9] Fix detection of files with only one line in git-apply.

A patch which added one line to an empty file or removed the only line from a one line file would be incorrectly detected as an invalid new or delete patch. Added a new test case. Signed-off-by: Robert Fitzsimons <[EMAIL PROTECTED]> --- apply.c |4 ++-- t/t4103-apply-oneli

[PATCH 1/9] Fix git patch header processing in git-apply.

Stop processing and return NULL if we encounter a '\n' character before we have two matching names in the git header. Signed-off-by: Robert Fitzsimons <[EMAIL PROTECTED]> --- apply.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) 289e53f770e37dfe25c740788256d24c19c2e16d diff --git

git-apply patches

Here is a series of patches which fix some bugs in and add some new command line options to git-apply. [PATCH 1/9] Fix git patch header processing in git-apply. [PATCH 2/9] Fix detection of files with only one line in git-apply. [PATCH 3/9] Fix processing of a patch file which modifies the same fi

Re: [PATCH] Spell __attribute__ correctly in cache.h.

Jason Riedy <[EMAIL PROTECTED]> writes: > If you're interested, I have a few patches in > http://www.cs.berkeley.edu/~ejr/gits/git.git#portable > that let git compile with xlc on AIX and Sun's non-c99 > cc on Solaris. I've taken a look at them. Thanks. > Changes: > +Replace C99 array in

Re: [PATCH] A new merge algorithm, take 2

Fredrik Kuivinen <[EMAIL PROTECTED]> writes: > I didn't know you could do things like that with git-ls-files :) But > yeah, it's certainly less intrusive to do it that way. It will > probably simplify things a great deal too. Wouldn't '--unmerged' be > the appropriate flag to use for git-ls-files

Re: [PATCH] A new merge algorithm, take 2

On Sat, Aug 27, 2005 at 10:23:23PM -0700, Junio C Hamano wrote: > Fredrik Kuivinen <[EMAIL PROTECTED]> writes: > > > The main changes compared to the previous version are: > > > > * Lots of clean up. > > * Some of the scripts have been renamed to better match the naming > > convention used in Gi