On Sat, Mar 17, 2018 at 3:11 PM, Thomas Gummerer <t.gummerer@xxxxxxxxx> wrote: > On 03/17, Eddy Petrișor wrote: >> vin., 16 mar. 2018, 23:44 Eric Sunshine <sunshine@xxxxxxxxxxxxxx> a scris: >> > It may be a disservice to remove mention of git-blame and git-shortlog >> > since git-contacts may not be suitable for everyone. Instead, perhaps >> > advertise git-contacts as a potentially simpler alternative to the >> > already-mentioned git-blamd & git-shortlog? > > Not sure how much of a disservice it would be. I think of > SubmittingPatches as mostly a document for new git contributors, for > who I think we should make it as easy as possible to start > contributing. Interpreting the output of 'git blame' and 'git > shortlog' feels like an extra hurdle for new contributors, especially > if someone is not familiar with the mailing list workflow. I do > remember wondering exactly how I should interpret this when I sent my > first patches. Okay. Mentioning those commands (in addition to git-contacts) is an opportunity to educate newcomers to Git the tool (not just to git.git the project) about additional ways to engage in project spelunking. By "disservice", I meant that that educational opportunity is lost. Eddy's suggestion of reversing the order, thus mentioning git-contacts first is a good alternative. However, perhaps this idea of educating newcomers to Git is misplaced in this context; such spelunking advice may be better suited to a general Git tutorial than to SubmittingPatches which is indeed specific to git.git. Given that reasoning, then my "disservice" view may be wrong. >> > Also, would it make sense to mention Felipe's git-related[1] which is >> > the original (and now more configurable) script from which >> > git-contacts functionality was derived? > > The reason I chose 'git contacts' over git-related is mainly that it > comes available with git. Mentioning both again makes things harder > on new contributors who already have enough to think about when > submitting the patch. > > I guess in the end it comes down to who we think the target of the > document is. To me it was always people new to the project, which is > why I think the single command there makes sense. Fair enough.
