All of lore.kernel.org
 help / color / mirror / Atom feed
From: "René Scharfe" <l.s.r@web.de>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] branch: use $curr_branch_short more
Date: Sun, 08 Sep 2013 17:21:23 +0200	[thread overview]
Message-ID: <522C95F3.5030308@web.de> (raw)
In-Reply-To: <CAMP44s39X2SsZC7f6=j=CX+9wky7YpiJUz3itCiqeLScD0TbNA@mail.gmail.com>

Am 31.08.2013 19:20, schrieb Felipe Contreras:
> A summary should contain as much information that would allow me to
> skip the commit message as possible.
>
> If I can't tell from the summary if I can safely skip the commit
> message, the summary is not doing a good job.
>
> "trivial simplification" explains the "what", and the "why" at the
> same time, and allows most people to skip the commit message, thus is
> a good summary.

No patch should be skipped on the mailing list.  As you wrote, trivial 
patches can still be wrong.

When going through the history I can see that quickly recognizing 
insubstantial changes is useful, but if I see a summary twice then in my 
mind forms a big question mark -- why did the same thing had to be done 
yet again?

As an example, both 0d12e59f (pull: replace unnecessary sed invocation) 
and bc2bbc45 (pull, rebase: simplify to use die()) could arguably have 
had the summary "trivial simplification", but I'm glad the author went 
with something a bit more specific.

I agree that some kind of tagging with keywords like "trivial", "typo" 
and so on can be helpful, though.

> Again, triviality and correctness are two separate different things.
> The patch is trivial even if you can't judge it's correctness.

Well, in terms of impact I agree.

> To me, what you are describing is an obvious patch, not a trivial one.
> An obvious patch is so obvious that you can judge it's correctness
> easily by looking at the diff, a trivial one is of little importance.

That's one definition; I think I had the mathematical notion in mind 
that calls proofs trivial which are immediately evident.

René

  reply	other threads:[~2013-09-08 15:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-30 21:56 [PATCH 0/6] Trivial cleanups and fixes Felipe Contreras
2013-08-30 21:56 ` [PATCH 1/6] reset: trivial refactoring Felipe Contreras
2013-08-31  3:36   ` Junio C Hamano
2013-08-30 21:56 ` [PATCH 2/6] branch: trivial style fix Felipe Contreras
2013-08-31  3:36   ` Junio C Hamano
2013-08-30 21:56 ` [PATCH 3/6] rebase: trivial style fixes Felipe Contreras
2013-08-31  3:49   ` Junio C Hamano
2013-08-30 21:56 ` [PATCH 4/6] reset: trivial style cleanup Felipe Contreras
2013-08-31  3:49   ` Junio C Hamano
2013-08-30 21:56 ` [PATCH 5/6] add: " Felipe Contreras
2013-08-31  3:37   ` Junio C Hamano
2013-08-30 21:56 ` [PATCH 6/6] pull: trivial cleanup Felipe Contreras
2013-08-31  3:58   ` Junio C Hamano
2013-08-31  7:56     ` Felipe Contreras
2013-08-31  8:10     ` [PATCH] branch: use $curr_branch_short more René Scharfe
2013-08-31  8:22       ` Felipe Contreras
2013-08-31  9:11         ` René Scharfe
2013-08-31  9:22           ` Felipe Contreras
2013-08-31 10:28             ` René Scharfe
2013-08-31 17:20               ` Felipe Contreras
2013-09-08 15:21                 ` René Scharfe [this message]
2013-09-08 23:13                   ` Felipe Contreras
2013-09-15 11:42                     ` René Scharfe
2013-09-15 13:02                       ` Felipe Contreras
2013-09-03 16:56         ` Junio C Hamano
2013-09-08 15:21       ` [PATCH] pull: " René Scharfe

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=522C95F3.5030308@web.de \
    --to=l.s.r@web.de \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.