| Message ID | 20241006045847.159937-1-cdwhite3@pm.me (mailing list archive) |
|---|---|
| Headers | show |
| Series | Link worktrees with relative paths | expand |
On Sun, Oct 6, 2024 at 12:59 AM Caleb White <cdwhite3@pm.me> wrote: > This patch series modifies Git's handling of worktree linking to use > relative paths instead of absolute paths. The motivation behind this > change is to enhance the robustness of worktree links when the main > repository is moved, or when used in environments like containerized > development where absolute paths differ across systems. > [...] > Caleb White (4): > worktree: refactor infer_backlink() to use *strbuf > worktree: link worktrees with relative paths > worktree: sync worktree paths after gitdir move > worktree: prevent null pointer dereference Unfortunately, these patches are whitespace-damaged. Can you please resubmit using either `git send-email` or GitGitGadget[1]? [1]: https://gitgitgadget.github.io/
On Sunday, October 6th, 2024 at 00:04, Eric Sunshine <sunshine@sunshineco.com> wrote: > On Sun, Oct 6, 2024 at 12:59 AM Caleb White cdwhite3@pm.me wrote: > > > This patch series modifies Git's handling of worktree linking to use > > relative paths instead of absolute paths. The motivation behind this > > change is to enhance the robustness of worktree links when the main > > repository is moved, or when used in environments like containerized > > development where absolute paths differ across systems. > > [...] > > Caleb White (4): > > worktree: refactor infer_backlink() to use *strbuf > > worktree: link worktrees with relative paths > > worktree: sync worktree paths after gitdir move > > worktree: prevent null pointer dereference > > > Unfortunately, these patches are whitespace-damaged. Can you please > resubmit using either `git send-email` or GitGitGadget[1]? > > [1]: https://gitgitgadget.github.io/ I sent them with `git send-email`, let me try again and then if that doesn't work then I'll try GitGitGadget. Just out of curiosity, how could you tell that they are whitespaced-damaged (so I know what to look for)? Thanks,
On Sun, Oct 6, 2024 at 1:04 AM Eric Sunshine <sunshine@sunshineco.com> wrote: > On Sun, Oct 6, 2024 at 12:59 AM Caleb White <cdwhite3@pm.me> wrote: > > This patch series modifies Git's handling of worktree linking to use > > relative paths instead of absolute paths. The motivation behind this > > change is to enhance the robustness of worktree links when the main > > repository is moved, or when used in environments like containerized > > development where absolute paths differ across systems. > > Unfortunately, these patches are whitespace-damaged. Can you please > resubmit using either `git send-email` or GitGitGadget[1]? Also, since you're touching infer_backlink(), see [1] which makes some changes nearby. And you might be interested in [2] which may indicate that there are some holes in the tests around worktrees which might need filling. (Since your patches are whitespace-damaged, I haven't checked whether your series succeeds or fails in the way the series to which [2] is a response fails.) [1]: https://lore.kernel.org/git/20240923075416.54289-1-ericsunshine@charter.net/ [2]: https://lore.kernel.org/git/CAPig+cQXFy=xPVpoSq6Wq0pxMRCjS=WbkgdO+3LySPX=q0nPCw@mail.gmail.com/
On Sun, Oct 6, 2024 at 1:11 AM Caleb White <cdwhite3@pm.me> wrote: > On Sunday, October 6th, 2024 at 00:04, Eric Sunshine <sunshine@sunshineco.com> wrote: > > Unfortunately, these patches are whitespace-damaged. Can you please > > resubmit using either `git send-email` or GitGitGadget[1]? > > I sent them with `git send-email`, let me try again and then if that > doesn't work then I'll try GitGitGadget. Just out of curiosity, how > could you tell that they are whitespaced-damaged (so I know what to > look for)? Hmm, that's very strange; git-send-email shouldn't be damaging them like that. I noticed the whitespace-damage just by visual inspection as I quickly scanned my eyes over the patches. For instance, in patch [1/4], I see: + struct strbuf backlink = STRBUF_INIT; struct strbuf gitd ir = STRBUF_INIT; The "gitdir" variable got split.
On Sun, Oct 6, 2024 at 1:14 AM Eric Sunshine <sunshine@sunshineco.com> wrote: > I noticed the whitespace-damage just by visual inspection as I quickly > scanned my eyes over the patches. For instance, in patch [1/4], I see: > > + struct strbuf backlink = STRBUF_INIT; > struct strbuf gitd > ir = STRBUF_INIT; > > The "gitdir" variable got split. Maybe "whitespace-damaged" was the wrong terminology. They are incorrectly wrapped/line-split.
On Sunday, October 6th, 2024 at 00:32, Eric Sunshine <sunshine@sunshineco.com> wrote: > On Sun, Oct 6, 2024 at 1:21 AM Caleb White cdwhite3@pm.me wrote: > > > On Sunday, October 6th, 2024 at 00:16, Eric Sunshine sunshine@sunshineco.com wrote: > > > > > > + struct strbuf backlink = STRBUF_INIT; > > > > struct strbuf gitd > > > > ir = STRBUF_INIT; > > > > That's strange, the code came through just fine on my end: > > > It's broken in the Git mailing list archive, as well. If you search > for "mbox.gz" at [], you can download this email thread. The patches > in that mbox file have the same damage as I'm seeing. > > [] https://lore.kernel.org/git/CAPig+cTVbXVffSeyNAV3c0zuSUozY7giWtMw3GpHs+xVEpaNvA@mail.gmail.com/T/ That's interesting...what's the best way to try and resubmit? As a new thread or as a v2?
On Sun, Oct 6, 2024 at 1:41 AM Caleb White <cdwhite3@pm.me> wrote: > On Sunday, October 6th, 2024 at 00:32, Eric Sunshine <sunshine@sunshineco.com> wrote: > > It's broken in the Git mailing list archive, as well. If you search > > for "mbox.gz" at [], you can download this email thread. The patches > > in that mbox file have the same damage as I'm seeing. > > That's interesting...what's the best way to try and resubmit? As > a new thread or as a v2? For continuity in the archive, probably best to submit it as v2 as a reply to the original cover letter: git send-email -v2 --reply-to='20241006045847.159937-1-cdwhite3@pm.me' ...
On Sunday, October 6th, 2024 at 00:50, Eric Sunshine <sunshine@sunshineco.com> wrote: > On Sun, Oct 6, 2024 at 1:41 AM Caleb White cdwhite3@pm.me wrote: > > > On Sunday, October 6th, 2024 at 00:32, Eric Sunshine sunshine@sunshineco.com wrote: > > > > > It's broken in the Git mailing list archive, as well. If you search > > > for "mbox.gz" at [], you can download this email thread. The patches > > > in that mbox file have the same damage as I'm seeing. > > > > That's interesting...what's the best way to try and resubmit? As > > a new thread or as a v2? > > > For continuity in the archive, probably best to submit it as v2 as a > reply to the original cover letter: > > git send-email -v2 --reply-to='20241006045847.159937-1-cdwhite3@pm.me' ... Thanks, I regenerated v2 patches with `format-patch` and then sent with `send-email`. However, the issue seems to have persisted (at least it's consistent?). I looked through the the patches on the listserv and that seems to be the only location where this occurs.
On Sun, Oct 6, 2024 at 2:05 AM Caleb White <cdwhite3@pm.me> wrote: > On Sunday, October 6th, 2024 at 00:50, Eric Sunshine <sunshine@sunshineco.com> wrote: > > For continuity in the archive, probably best to submit it as v2 as a > > reply to the original cover letter: > > git send-email -v2 --reply-to='20241006045847.159937-1-cdwhite3@pm.me' ... > > Thanks, I regenerated v2 patches with `format-patch` and then sent with > `send-email`. However, the issue seems to have persisted (at least it's > consistent?). I looked through the the patches on the listserv and that > seems to be the only location where this occurs. Indeed, I'm seeing the same line-wrapping breakage in the mailing list archive and in my Inbox for v2. I presume that you've verified that the raw patches are not broken like that, and that the problem is happening at email time?
On 10/6/24 01:16, Eric Sunshine <sunshine@sunshineco.com> wrote: > Indeed, I'm seeing the same line-wrapping breakage in the mailing list > archive and in my Inbox for v2. > > I presume that you've verified that the raw patches are not broken > like that, and that the problem is happening at email time? Yes, I've checked the patch files and they are good. I'm also not seeing any breakages in my inbox which is strange.
On Sun, Oct 6, 2024 at 2:23 AM Caleb White <cdwhite3@pm.me> wrote: > On 10/6/24 01:16, Eric Sunshine <sunshine@sunshineco.com> wrote: > > Indeed, I'm seeing the same line-wrapping breakage in the mailing list > > archive and in my Inbox for v2. > > > > I presume that you've verified that the raw patches are not broken > > like that, and that the problem is happening at email time? > > Yes, I've checked the patch files and they are good. I'm also not seeing any breakages in my inbox which is strange. I've been trying to hand-edit v2 to fix the breakage in order to get it applied, but I'm not having much success. I did manage to get patch [1/4] applied, but patch [2/4] is base64-encoded for some reason (you can see it here[*]), so I haven't been able to edit it easily in order to fix the breakage. `git am` isn't particularly happy with it either; it complains: % git am PATCH-v2-0-4-Link-worktrees-with-relative-paths.mbox Applying: worktree: refactor infer_backlink() to use *strbuf warning: quoted CRLF detected Applying: worktree: link worktrees with relative paths .git/rebase-apply/patch:60: trailing whitespace. #!/bin/sh .git/rebase-apply/patch:61: trailing whitespace. .git/rebase-apply/patch:62: trailing whitespace. test_description='test worktrees linked with relative paths' .git/rebase-apply/patch:63: trailing whitespace. .git/rebase-apply/patch:64: trailing whitespace. TEST_PASSES_SANITIZE_LEAK=true error: patch failed: builtin/worktree.c:414 error: builtin/worktree.c: patch does not apply error: patch failed: worktree.c:110 error: worktree.c: patch does not apply Patch failed at 0002 worktree: link worktrees with relative paths Can you try GitGitGadget instead (preferable) or perhaps publish this series somewhere (less preferable). [*]: https://lore.kernel.org/git/20241006060017.171788-3-cdwhite3@pm.me/raw
On Sun, Oct 6, 2024, at 09:45, EricSunshine wrote: > Can you try GitGitGadget instead (preferable) or perhaps publish this > series somewhere (less preferable). > > [*]: https://lore.kernel.org/git/20241006060017.171788-3-cdwhite3@pm.me/raw If Caleb gives us a clone link then I could try to send.