From: Junio C Hamano <gitster@pobox.com>
To: Matt McClure <matthewlmcclure@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: patch series vs. multiple files changed in a commit; storytelling history vs. literal creation history
Date: Tue, 26 Mar 2013 15:03:29 -0700 [thread overview]
Message-ID: <7vli99stse.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAJELnLE0FLrSYGHgS-cZmyQWO122-MuN7AeczUUVVposUg+qjw@mail.gmail.com> (Matt McClure's message of "Tue, 26 Mar 2013 17:21:43 -0400")
Matt McClure <matthewlmcclure@gmail.com> writes:
> 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?
We do not try to keep records of "oops, the previous was wrong" when
we can easily tell the previous was wrong. Usually such a shallow
mistake that can be spotted during the review is not worth keeping.
For example, the 4 patch series I posted today had three iterations
of botched attempts that were never even published. I am sure other
people do the same for their initial round for their patches, and
any message on this list whose subject begins with "[PATCH vN X/Y]"
for N > 2 are rewritten betterment based on list feedback.
Our history tends to become a coherent story because of this.
It is a different story for more involved changes that cook in
'next' for a while and then later turns out to have flaws. We update
them with follow-up fixes and at that point, we do have records of
mistakes. They often are tricky cases that are worth recording, as
people can later make similar kinds of mistakes in other parts of
the codebase.
The early part of the history back when Linus was running the show
is somewhat different; you see more reverts and rewrites. But even
back then, there were more experimental changes that were rewritten
than the changes that were finally committed to the history.
prev parent reply other threads:[~2013-03-26 22:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 21:21 patch series vs. multiple files changed in a commit; storytelling history vs. literal creation history Matt McClure
2013-03-26 22:03 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vli99stse.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=matthewlmcclure@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).