I've read Documentation/SubmittingPatches, followed some of the
discussion on this list, and looked over some of the recent commit
history. I'm impressed by the strong culture of review that produces
readable patches and commit messages, but I think there are some gaps
in my understanding of the prevailing process here.

Most of the code I've worked on has been closed source, and the commit
histories tend to reflect what I'd call the literal "creation
history". Reading the Git history, my impression is that it reflects a
different "storytelling" history. In some cases, that might be the
same as the creation history, but in general the emphasis is on
telling a coherent story of the changes to the other developers rather
than communicating all the messy details of how you arrived at the
order of that story. Is that right?

What are the Git project's rules of thumb for when to create a patch
series vs. putting changes to multiple files in a single commit/patch?

As a patch series evolves before landing on an upstream branch, do you
typically make corrections to the original series in new commits, or
update the respective commits from the original series in a new series
of analogous commits?

Matt McClure
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to