On Thu, Jan 05, 2012 at 09:03:38AM -0600, David A. Greene wrote:
> > Please read and follow the guidelines listed in
> > Documentation/SubmittingPatches. The TL;DR version is: break it up
> > into logical reviewable commits based on the current `master` and use
> > git format-patch/ git send-email to send those commits to this mailing
> > list.
>
> I've read that document. The issue is that I didn't develop the code,
> Avery did. This is a completely new tool for git and I don't have the
> first idea of what "logical" chunks would look like. I assume, for
> example, that we'd want the first "chunk" to actually work and do
> something interesting. I can go spend a bunch of time to see if I can
> grok enough to create these chunks but I wanted to check first and make
> sure that would be absolutely necessary. It's a lot of time to learn a
> completely new codebase. I was hoping to submit something soon and then
> learn the codebase gradually during maintenance/further development.
I think this is also somewhat different in that git-subtree has a
multi-year history in git that we may want to keep. So it is more
analogous to something like gitweb or git-gui, which we have brought in
(using subtree merges, no less).
The biggest decision is whether or not to import the existing history.
If we do, then we have to decide whether it becomes a sub-component like
gitweb (e.g., it gets pulled into a "subtree" directory, and we have
make recurse into it), or whether it gets overlaid into the main
directory (i.e., we clean and munge the subtree repo a bit, then just
"git merge" the history in).
If we want to throw away the existing history, then I think you end up
doing the same munging as the latter option above, and then just make a
single patch out of it instead of a merge.
I don't use git-subtree, but just glancing over the repo, it looks like
that munging is mostly:
1. git-subtree.sh stays, and gets added to git.git's top-level Makefile
2. the test.sh script gets adapted into t/tXXXX-subtree.sh
3. git-subtree.txt goes into Documentation/
4. The rest of the files are infrastructure that can go away, as they
are a subset of what git.git already contains.
I'd favor keeping the history and doing the munge-overlay thing.
Although part of me wants to join the histories in a subtree so that we
can use "git subtree" to do it (which would just be cool), I think the
resulting code layout doesn't make much sense unless git-subtree is
going to be maintained separately.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html