---- On Thu, 13 Oct 2022 10:53:44 -0700 René Scharfe wrote --- > > I am open to feedback since this is all quite new to me :) > > > > TODO: > > This list confuses me: I apologize. I'm new to this repo and workflow. I had been using checkboxes in github, which look like `- [x]` for ones that I have completed. They all got converted into items that look like they needed doing via GitGitGadget. The only remaining one was to update documentation. > > > > > Alphadelta14 (2): > > archive: add --recurse-submodules to git-archive command > > archive: fix a case of submodule in submodule traversal > > We prefer to keep known bugs out of the repo. It helps when bisecting, > for example. So it would be better to squash the fix into the patch > that adds the feature. But... Absolutely can do. > > > archive-tar.c | 14 +++-- > > archive-zip.c | 14 ++--- > > archive.c | 99 ++++++++++++++++++++++++----------- > > archive.h | 8 +-- > > builtin/checkout.c | 2 +- > > builtin/log.c | 2 +- > > builtin/ls-files.c | 10 ++-- > > builtin/ls-tree.c | 16 +++--- > > list-objects.c | 2 +- > > merge-recursive.c | 2 +- > > revision.c | 4 +- > > sparse-index.c | 2 +- > > t/t5005-archive-submodules.sh | 84 +++++++++++++++++++++++++++++ > > tree.c | 93 ++++++++++++++++++++++---------- > > tree.h | 11 ++-- > > wt-status.c | 2 +- > > 16 files changed, 269 insertions(+), 96 deletions(-) > > create mode 100755 t/t5005-archive-submodules.sh > > ... this is all a bit much for a single patch, I feel. Giving > parse_tree_gently() a repo parameter, adding repo_parse_tree(), using > it in read_tree_at(), adding a repo parameter to read_tree_fn_t, > letting read_tree_at() recurse into submodules and adding the new > option to git archive all seem like topics worth their own patch and > rationale. > You probably have all of that in your head right now, but at least my > attention span and working memory capacity requires smaller morsels. Does this mean I should create multiple PRs? Or should they just be split up into individual commits. I will work off assuming the latter. I am comfortable rewriting history as long as I understand the direction to go in. Should each individual patch be completely standalone? (To the point where each set, with the previous patches should produce a working application? Or is having the patch broken up by groups of changes, with some level of expecting the final functionality good?) But thanks so far. I will get working on this (and review your next set of messages).
