Re: format-patch and submodules
Well, now it gets more complicated. I want git-p4 to ignore submodules completely. But it fails only *only* the submodules changed. (At least, my version fails. I'll try to diff against latest.) But to debug this, I had to add a dry-run mode to git-p4. And I am using a version of git-p4 which uses 'git-notes' rather than re-writing history. If you want, you can try my version: https://github.com/pb-cdunn/git-p4 On Wed, Jun 10, 2015 at 4:14 PM, Luke Diamand wrote: > On 10/06/15 18:04, Christopher Dunn wrote: >> >> Sorry. I thought empty patches were made to work in other cases. >> >> 'git-p4' needs to skip these. Wrong mailing list then. > > > Possibly the right mailing list - can you explain what you mean here w.r.t > git-p4 please? > > Thanks! > Luke > > > > >> >> On Tue, Jun 9, 2015 at 1:52 PM, Jens Lehmann wrote: >>> >>> Am 05.06.2015 um 01:20 schrieb Christopher Dunn: (Seen in git versions: 2.1.0 and 1.9.3 et al.) $ git format-patch --stdout X^..X | git apply check - fatal: unrecognized input This fails when the commit consists of nothing but a submodule change (as in 'git add submodule foo'), but it passes when a file change is added to the same commit. There used to be a similar problem for empty commits, but that was fixed around git-1.8: http://stackoverflow.com/questions/20775132/cannot-apply-git-patch-replacing-a-file-with-a-link Now, 'git format-patch' outputs nothing for an empty commit. I suppose that needs to be the behavior also when only submodules are changed, since in that case there is no 'diff' section from 'format-patch'. Use-case: git-p4 Of course, we do not plan to add the submodule into Perforce, but we would like this particular command to behave the same whether there are other diffs or not. >>> >>> >>> >>> Hmm, I'm not sure that this is a bug. It looks to me like doing a >>> >>> $ git format-patch --stdout X^..X | git apply check - >>> >>> when nothing is changed except submodules and expecting it to work >>> is the cause of the problem. >>> >>> I get the same error when I do: >>> >>> $git format-patch --stdout master..master | git apply --check - >>> fatal: unrecognized input >>> >>> No submodules involved, just an empty patch. >>> >>> I assume you want to ignore all submodule changes, so you should >>> check if e.g. "git diff --ignore-submodules X^..X" returns anything >>> before applying that? (From the command you ran I assume you might >>> be able to drop the --ignore-submodules because you already did set >>> "diff.ignoreSubmodules" to "all"?) >> >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: format-patch and submodules
On 10/06/15 18:04, Christopher Dunn wrote: Sorry. I thought empty patches were made to work in other cases. 'git-p4' needs to skip these. Wrong mailing list then. Possibly the right mailing list - can you explain what you mean here w.r.t git-p4 please? Thanks! Luke On Tue, Jun 9, 2015 at 1:52 PM, Jens Lehmann wrote: Am 05.06.2015 um 01:20 schrieb Christopher Dunn: (Seen in git versions: 2.1.0 and 1.9.3 et al.) $ git format-patch --stdout X^..X | git apply check - fatal: unrecognized input This fails when the commit consists of nothing but a submodule change (as in 'git add submodule foo'), but it passes when a file change is added to the same commit. There used to be a similar problem for empty commits, but that was fixed around git-1.8: http://stackoverflow.com/questions/20775132/cannot-apply-git-patch-replacing-a-file-with-a-link Now, 'git format-patch' outputs nothing for an empty commit. I suppose that needs to be the behavior also when only submodules are changed, since in that case there is no 'diff' section from 'format-patch'. Use-case: git-p4 Of course, we do not plan to add the submodule into Perforce, but we would like this particular command to behave the same whether there are other diffs or not. Hmm, I'm not sure that this is a bug. It looks to me like doing a $ git format-patch --stdout X^..X | git apply check - when nothing is changed except submodules and expecting it to work is the cause of the problem. I get the same error when I do: $git format-patch --stdout master..master | git apply --check - fatal: unrecognized input No submodules involved, just an empty patch. I assume you want to ignore all submodule changes, so you should check if e.g. "git diff --ignore-submodules X^..X" returns anything before applying that? (From the command you ran I assume you might be able to drop the --ignore-submodules because you already did set "diff.ignoreSubmodules" to "all"?) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: format-patch and submodules
Sorry. I thought empty patches were made to work in other cases. 'git-p4' needs to skip these. Wrong mailing list then. On Tue, Jun 9, 2015 at 1:52 PM, Jens Lehmann wrote: > Am 05.06.2015 um 01:20 schrieb Christopher Dunn: >> >> (Seen in git versions: 2.1.0 and 1.9.3 et al.) >> >> $ git format-patch --stdout X^..X | git apply check - >> fatal: unrecognized input >> >> This fails when the commit consists of nothing but a submodule change >> (as in 'git add submodule foo'), but it passes when a file change is >> added to the same commit. >> >> There used to be a similar problem for empty commits, but that was >> fixed around git-1.8: >> >> >> http://stackoverflow.com/questions/20775132/cannot-apply-git-patch-replacing-a-file-with-a-link >> >> Now, 'git format-patch' outputs nothing for an empty commit. I suppose >> that needs to be the behavior also when only submodules are changed, >> since in that case there is no 'diff' section from 'format-patch'. >> >> Use-case: git-p4 >> >> Of course, we do not plan to add the submodule into Perforce, but we >> would like this particular command to behave the same whether there >> are other diffs or not. > > > Hmm, I'm not sure that this is a bug. It looks to me like doing a > > $ git format-patch --stdout X^..X | git apply check - > > when nothing is changed except submodules and expecting it to work > is the cause of the problem. > > I get the same error when I do: > > $git format-patch --stdout master..master | git apply --check - > fatal: unrecognized input > > No submodules involved, just an empty patch. > > I assume you want to ignore all submodule changes, so you should > check if e.g. "git diff --ignore-submodules X^..X" returns anything > before applying that? (From the command you ran I assume you might > be able to drop the --ignore-submodules because you already did set > "diff.ignoreSubmodules" to "all"?) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: format-patch and submodules
Am 05.06.2015 um 01:20 schrieb Christopher Dunn: (Seen in git versions: 2.1.0 and 1.9.3 et al.) $ git format-patch --stdout X^..X | git apply check - fatal: unrecognized input This fails when the commit consists of nothing but a submodule change (as in 'git add submodule foo'), but it passes when a file change is added to the same commit. There used to be a similar problem for empty commits, but that was fixed around git-1.8: http://stackoverflow.com/questions/20775132/cannot-apply-git-patch-replacing-a-file-with-a-link Now, 'git format-patch' outputs nothing for an empty commit. I suppose that needs to be the behavior also when only submodules are changed, since in that case there is no 'diff' section from 'format-patch'. Use-case: git-p4 Of course, we do not plan to add the submodule into Perforce, but we would like this particular command to behave the same whether there are other diffs or not. Hmm, I'm not sure that this is a bug. It looks to me like doing a $ git format-patch --stdout X^..X | git apply check - when nothing is changed except submodules and expecting it to work is the cause of the problem. I get the same error when I do: $git format-patch --stdout master..master | git apply --check - fatal: unrecognized input No submodules involved, just an empty patch. I assume you want to ignore all submodule changes, so you should check if e.g. "git diff --ignore-submodules X^..X" returns anything before applying that? (From the command you ran I assume you might be able to drop the --ignore-submodules because you already did set "diff.ignoreSubmodules" to "all"?) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
format-patch and submodules
(Seen in git versions: 2.1.0 and 1.9.3 et al.) $ git format-patch --stdout X^..X | git apply check - fatal: unrecognized input This fails when the commit consists of nothing but a submodule change (as in 'git add submodule foo'), but it passes when a file change is added to the same commit. There used to be a similar problem for empty commits, but that was fixed around git-1.8: http://stackoverflow.com/questions/20775132/cannot-apply-git-patch-replacing-a-file-with-a-link Now, 'git format-patch' outputs nothing for an empty commit. I suppose that needs to be the behavior also when only submodules are changed, since in that case there is no 'diff' section from 'format-patch'. Use-case: git-p4 Of course, we do not plan to add the submodule into Perforce, but we would like this particular command to behave the same whether there are other diffs or not. ~Christopher Dunn (cdunn2001) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
