From: Emily Shaffer <emilyshaffer@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Emily Shaffer via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 1/1] documentation: add lab for first contribution
Date: Mon, 15 Apr 2019 10:26:02 -0700 [thread overview]
Message-ID: <CAJoAoZkj_95ZWSGQ1Rpj02OAu==Wz=e4sFZnvuRr0dFQk3ZP8Q@mail.gmail.com> (raw)
In-Reply-To: <xmqq8swexy3v.fsf@gitster-ct.c.googlers.com>
> >> ... then leave it in your example, perhaps?
> >>
> >
> > Good point. :) I had wanted to avoid including my own name/email in the
> > tutorial; I used a throwaway "Git Contributor <very@smart.dev>" for the example.
> > ...
> >> Keep a sample sign-off by "A U Thor <author@example.com>" here.
>
>
> No, use "A U Thor <author@example.com>" as I suggested. That's the
> author ident the aspiring Git developer MUST become familiar with
> while working with our test suite in t/. There you will also find
> the counterpart committer ident to use, if needed.
Done.
>
> Just FYI, I rarely give a "do it exactly like this" suggestion;
> often I instead stop at giving a general direction and leave it up
> to the contributers to perfect it. The "A U Thor" is one of those
> rare cases. On the other hand, "fork" was *not*.
Sorry about that. I've found it's good practice to "show, don't tell"
when I make review
comments to avoid confusion, which isn't quite the same as "do it
exactly like this"
but looks similar on the box. So I guessed wrong this time. :) Will
push a fix with it.
>
> > Do folks on Git project usually engage in test-driven development? I
> > would be happy to move the test up towards the front of the document
> > and mention the usefulness of TDD, but not if that's not something
> > emphasized usually by the group..
>
> I have no strong opinion on this myself.
>
> I suspect that the developer would clean up with "rebase -i" by
> squashing before submitting the result of a very fine-grained TDD
> workflow, as nobody would want to read printf("hello world") in
> [PATCH 1/47] that would become a real feature in a later step. So
> if the tutorial wants to go into that tangent (which might be too
> much detail), it may be worth showing from the first few commits,
> but otherwise a sequence that pretends the reader to be a perfect
> developer who does not make any mistake in the middle may be more
> concise and more readable. I dunno.
In that case, I'd just as soon leave the order as it is. I think that
a developer,
outside of the context of a tutorial, will end up writing tests in the
order they
prefer regardless of the order of a tutorial they did one time. Maybe I can add
a note about tests being required for incoming patches to discourage readers
from glossing over that section.
>
> Thanks.
next prev parent reply other threads:[~2019-04-15 17:26 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-11 18:32 [PATCH 0/1] documentation: add lab for first contribution Emily Shaffer via GitGitGadget
2019-04-11 18:32 ` [PATCH 1/1] " Emily Shaffer via GitGitGadget
2019-04-12 3:20 ` Junio C Hamano
2019-04-12 22:03 ` Emily Shaffer
2019-04-13 5:39 ` Junio C Hamano
2019-04-15 17:26 ` Emily Shaffer [this message]
2019-04-11 21:03 ` [PATCH 0/1] " Josh Steadmon
2019-04-12 2:35 ` Junio C Hamano
2019-04-12 22:58 ` Emily Shaffer
2019-04-16 20:26 ` [PATCH v2 " Emily Shaffer via GitGitGadget
2019-04-16 20:26 ` [PATCH v2 1/1] " Emily Shaffer via GitGitGadget
2019-04-17 5:32 ` Junio C Hamano
2019-04-17 8:07 ` Eric Sunshine
2019-04-18 0:05 ` Junio C Hamano
2019-04-17 23:16 ` Emily Shaffer
2019-04-16 21:13 ` [PATCH v2 0/1] " Emily Shaffer
2019-04-19 16:57 ` [PATCH v3] " Emily Shaffer
2019-04-21 10:52 ` Junio C Hamano
2019-04-22 22:27 ` Emily Shaffer
2019-04-23 19:34 ` [PATCH v4] documentation: add tutorial " Emily Shaffer
2019-04-30 18:59 ` Josh Steadmon
2019-05-02 0:57 ` Emily Shaffer
2019-05-03 2:11 ` Phil Hord
2019-05-07 19:05 ` Emily Shaffer
2019-05-06 22:28 ` Jonathan Tan
2019-05-07 19:59 ` Emily Shaffer
2019-05-07 20:32 ` Jonathan Tan
2019-05-08 2:45 ` Junio C Hamano
2019-05-07 21:30 ` [PATCH v5 0/2] documentation: add lab " Emily Shaffer
2019-05-07 21:30 ` [PATCH v5 1/2] documentation: add tutorial " Emily Shaffer
2019-05-07 23:25 ` Emily Shaffer
2019-05-08 3:46 ` Junio C Hamano
2019-05-08 18:58 ` Emily Shaffer
2019-05-08 19:53 ` Jonathan Tan
2019-05-07 21:30 ` [PATCH v5 2/2] documentation: add anchors to MyFirstContribution Emily Shaffer
2019-05-08 3:30 ` [PATCH v5 0/2] documentation: add lab for first contribution Junio C Hamano
2019-05-17 19:03 ` [PATCH v6 0/2] documentation: add tutorial " Emily Shaffer
2019-05-17 19:07 ` [PATCH v6 1/2] " Emily Shaffer
2019-05-26 7:48 ` Christian Couder
2019-05-29 20:09 ` Emily Shaffer
2019-10-18 16:40 ` SZEDER Gábor
2019-10-18 22:54 ` Emily Shaffer
2019-05-17 19:07 ` [PATCH v6 2/2] documentation: add anchors to MyFirstContribution Emily Shaffer
2019-05-29 20:18 ` [PATCH] doc: add some nit fixes " Emily Shaffer
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJoAoZkj_95ZWSGQ1Rpj02OAu==Wz=e4sFZnvuRr0dFQk3ZP8Q@mail.gmail.com' \
--to=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).