Re: [PATCH v2 0/2] archive: Add --recurse-submodules to git-archive command

---- 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).