Message ID | pull.1036.v3.git.1632760428.gitgitgadget@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Fix various issues around removal of untracked files/directories | expand |
"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes: > Changes since v2 (all due to Junio's request to consolidate > unpack_trees_options.dir handling): Heh, don't blame me. I even explicitly said it was merely an observation for longer term, not a suggestion to include the first step for such a move in this series.
On Mon, Sep 27, 2021 at 1:36 PM Junio C Hamano <gitster@pobox.com> wrote: > > "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > Changes since v2 (all due to Junio's request to consolidate > > unpack_trees_options.dir handling): > > Heh, don't blame me. I even explicitly said it was merely an > observation for longer term, not a suggestion to include the first > step for such a move in this series. Well...the repetitive code for setting up and clearing out unpack_trees_options.dir that already existed (and which my series was copying to more places) bugged me too, but I was worried that it was a bit messy to clean up (and the fact that it took five patches suggests it was). But then you also brought it up as an issue when reviewing, so I figured I might as well dive in...
On Mon, Sep 27, 2021 at 1:41 PM Elijah Newren <newren@gmail.com> wrote: > > On Mon, Sep 27, 2021 at 1:36 PM Junio C Hamano <gitster@pobox.com> wrote: > > > > "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > > > Changes since v2 (all due to Junio's request to consolidate > > > unpack_trees_options.dir handling): > > > > Heh, don't blame me. I even explicitly said it was merely an > > observation for longer term, not a suggestion to include the first > > step for such a move in this series. > > Well...the repetitive code for setting up and clearing out > unpack_trees_options.dir that already existed (and which my series was > copying to more places) bugged me too, but I was worried that it was a > bit messy to clean up (and the fact that it took five patches suggests > it was). But then you also brought it up as an issue when reviewing, > so I figured I might as well dive in... I guess I should add that some of your other review comments were related, e.g. your puzzlement/assumption that some of my changes preserved ignored files when untracked files were being overwritten (which was not what the patches actually did). Trying to make the code clearer was in some ways easier by first consolidating all those other bits.
[Resending as it did not seem to get through to the list last time] Hi Elijah On 27/09/2021 17:33, Elijah Newren via GitGitGadget wrote: > We have multiple codepaths that delete untracked files/directories but > shouldn't. There are also some codepaths where we delete untracked > files/directories intentionally (based on mailing list discussion), but > where that intent is not documented. We also have some codepaths that > preserve ignored files, which shouldn't. Fix the documentation, add several > new (mostly failing) testcases, fix some of the new testcases, and add > comments about some potential remaining problems. (I found these as a > side-effect of looking at [1], though [2] pointed out one explicitly while I > was working on it.) > > Note that I'm using Junio's declaration about checkout -f and reset --hard > (and also presuming that since read-tree --reset is porcelain that its > behavior should be left alone)[3] in this series. I've had a read through and I don't have any specific comments, I like the way you have simplified adding the standard excludes for callers and making the existing value of reset invalid when converting to an enum. I think there is a small risk someone will complain about read-tree changing how it handles ignored files, but hopefully everyone was just passing ".gitignore" to --exclude-per-directory and they wont mind 'read-tree -m -u' removing ignored files now. Best Wishes Phillip
Hi Phillip, On Thu, Sep 30, 2021 at 3:08 AM Phillip Wood <phillip.wood123@gmail.com> wrote: > > Hi Elijah > > On 27/09/2021 17:33, Elijah Newren via GitGitGadget wrote: > > We have multiple codepaths that delete untracked files/directories but > > shouldn't. There are also some codepaths where we delete untracked > > files/directories intentionally (based on mailing list discussion), but > > where that intent is not documented. We also have some codepaths that > > preserve ignored files, which shouldn't. Fix the documentation, add several > > new (mostly failing) testcases, fix some of the new testcases, and add > > comments about some potential remaining problems. (I found these as a > > side-effect of looking at [1], though [2] pointed out one explicitly while I > > was working on it.) > > > > Note that I'm using Junio's declaration about checkout -f and reset --hard > > (and also presuming that since read-tree --reset is porcelain that its > > behavior should be left alone)[3] in this series. > > > > I've had a read through and I don't have any specific comments, I like > the way you have simplified adding the standard excludes for callers and > making the existing value of reset invalid when converting to an enum. I > think there is a small risk someone will complain about read-tree > changing how it handles ignored files, but hopefully everyone was just > passing ".gitignore" to --exclude-per-directory and they wont mind > 'read-tree -m -u' removing ignored files now. Thanks for taking a look!