Re: [PATCH 1/9] Fix git patch header processing in git-apply.
I should have mentioned before, these changes are being used in a SourcePuller dump file to git import script I've been working on. 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: The test was the problem it tried to work with empty files. * Fix processing of a patch file which modifies the same file in git-apply. * Fix the processing of multiple patch files with --check in git-apply. * New option --ignore-applied for git-apply. I've fixed up the problems with these patches and rebased them. * New option --ignore-whitespace for git-apply. This change was just wrong and could cause file corruption, I've got another version in the works which fixes the problem and adds some of the suggested features. Robert Fitzsimons [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] Fix git patch header processing in git-apply.
On Mon, 29 Aug 2005, Robert Fitzsimons wrote: I should have mentioned before, these changes are being used in a SourcePuller dump file to git import script I've been working on. Hmm. Anything that depends on --ignore-applied is fundamentally broken as an import tool. There's no way something like that can be valid, since it inhently means that somebody is trying to apply a patch that simple isn't applicable. So it seems like you're trying to work around some other serious problems in the import, and as a result the import is clearly not trustworthy. Don't do this. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] Fix git patch header processing in git-apply.
Linus Torvalds [EMAIL PROTECTED] writes: Hmm. Anything that depends on --ignore-applied is fundamentally broken as an import tool. There's no way something like that can be valid, since it inhently means that somebody is trying to apply a patch that simple isn't applicable. Don't do this. I suspect that it is exported data that is broken, if this --ignore-applied flag is needed for importing something somebody exported. I, however, am not 100% convinced --ignore-applied is too dangerous to be useful in any conceivable use cases, at least not yet. For example, you might be cherry-picking a change from a foreign branch with 'git-diff-tree -p other~45 | git apply', where the current branch may have already aquired part of the changes that foreign branch contains since 45 generations ago. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] Fix git patch header processing in git-apply.
Linus Torvalds [EMAIL PROTECTED] writes: On Mon, 29 Aug 2005, Junio C Hamano wrote: I, however, am not 100% convinced --ignore-applied is too dangerous to be useful in any conceivable use cases, at least not yet. For example, you might be cherry-picking a change from a foreign branch with 'git-diff-tree -p other~45 | git apply', where the current branch may have already aquired part of the changes that foreign branch contains since 45 generations ago. .. and that's why we use a three-way merge, and not diffs, to merge two branches. .. and that's why I recently rewrote revert, cherry-pick and rebase to use three-way merge as well ;-). The code is simple enough and I see some beauty in it, but I honor your veto, at least for now. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] Fix git patch header processing in git-apply.
On Mon, 29 Aug 2005, Junio C Hamano wrote: The code is simple enough and I see some beauty in it, but I honor your veto, at least for now. Well, I didn't actually veto it when I saw the feature the first time, because I think it's a valid thing to do when applying patches by hand. It was only when I realized that Robert was trying to use it to import from somewhere else that it became broken. An import should use the most anal patches possible. Actually, an import should preferably never use patches at all, since that never really works for binary data. This is why the CVS importer actually checks out full files and imports them that way. The patch-based ones will fundamentally always have problems. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 git-apply. * Fix the processing of multiple patch files with --check in git-apply. * New option --ignore-whitespace for git-apply. * New option --ignore-applied for git-apply. *** t4104-apply-complex.sh *** * FAIL 5: S = Nx Px1 cat Nx Px1 | git-apply - * FAIL 6: S = Nx Px1 Px2 cat Nx Px1 Px2 | git-apply - * FAIL 7: S = Nx Px1 Px2 Px3 cat Nx Px1 Px2 Px3 | git-apply - * FAIL 8: S = Nx Px1 Px2 Px3 Dx cat Nx Px1 Px2 Px3 Dx | git-apply - * FAIL 13: S = Ny Ryx Px1 Px2 Cxy Px3 Dx cat Ny Ryx Px1 Px2 Cxy Px3 Dx | git-apply - * FAIL 14: S = Ny Ryx Px1 Px2 Cxy Px3 Dx Cyx cat Ny Ryx Px1 Px2 Cxy Px3 Dx Cyx | git-apply - * FAIL 15: S = Ny Cyx Px1 Px2 Px3 Dy Cxy Dx Cyx Dy Rxy Dy cat Ny Cyx Px1 Px2 Px3 Dy Cxy Dx Cyx Dy Rxy Dy| git-apply - - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html