list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <>
To: Max Rothman <>
Cc: "" <>
Subject: Re: No log --no-decorate completion?
Date: Tue, 7 Nov 2017 12:48:13 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Nov 7, 2017 at 12:31 PM, Max Rothman <> wrote:
> Thanks for the feedback!
>>> * Add bash completion for the missing --no-* options on git log
>>> * Add bash completion for --textconv and --indent-heuristic families to
>>>   git diff and all commands that use diff's options
>>> * Add bash completion for --no-abbrev-commit, --expand-tabs, and
>>>   --no-expand-tabs to git show
>> This describes what happens in this patch, but not why, which helps
>> future readers of commit message more than the "what".
> How about:
>> Teach git-log tab completion about the --no-* options for ease of use
>> at the command line.
>> Similarly, teach git-show tab completion about the --no-abbrev-commit,
>> --expand-tabs, and --no-expand-tabs options.
>> Also, teach git-diff (and all commands that use its options) tab
>> completion about the --textconv and --indent-heuristic families of
>> options. --indent-heuristic is no longer experimental, so there's no
>> reason it should be left out of tab completion any more, and textconv
>> seems to have simply been missed.

Sounds good to me.

>> At the end of a commit message, the Git project requires a sign off.
>> (See section (5) in Documentation/SubmittingPatches;
>> tl;dr: add Signed-off-by: NAME <EMAIL> if you can agree to
> So the sign-off should include my name and email? I thought it was
> supposed to be the person who approved the patch, but I must've gotten
> confused.

Anyone touching the patch needs to sign off on it. So when you write it,
you sign off (thereby certifying that you are legally allowed to write
the patch.
For example you may be employed and the work contract requires you to
not work on side projects, or the intellectual property belongs to the employer
or such).

Hypothetically you could send it to Git-for-Windows which happens to
be a fork of git. The maintainer of GfW would gladly accept your patch,
(and also sign it off, thereby certifying he can touch it legally).
Thereafter someone such as a regular contributor from the git project
could spot the difference in GfW and git, and they would want to bring it
to "the real git", so they would make a patch out of the commit in GfW.
Additionally to the 2 sign offs, this contributor would also need to sign
off on the patch, saying it is legal what they do. And then that patch could
be picked up by the maintainer for the regular git. After that journey the
patch would have 4 sign offs, indicating the way of travel, i.e. how
it reached git finally.

An example of a longer sign off chain is  89dd32aedc
(check-ref-format doc: --branch validates and expands <branch>, 2017-10-17)
and apparently Jeff helped Junio to author a patch; Jonathan took that
patch and changed a thing, only to send it back to Junio, who then applied
it to git.

>> The patch looks good, but doesn't apply because the email contains
>> white spaces instead of tabs. Maybe try
>> (or fix/change your email client to send a patch; the gmail web interface
>> doesn't work. I personally got 'git send-email' up and running;
>> The Documentation/SubmittingPatches has a section on email clients, too)
> Yeah, I was using the gmail interface. I'll give the heroku app a go.
> It has an option for sending a message in reply to another, and I
> assume I should send it in reply to this thread. Do you know how to
> tell what the appropriate ID to use is? Looking through the raw email,
> I see several, so it's not obvious to me which to use.

In gmail, there is a "show original" in the menu near reply, which will
show Message ID<>
for the email that I am responding to.

Another way to explore the message ids is public-inbox, as that uses
the message ids as keys, i.e.

is your email there.


  reply	other threads:[~2017-11-07 20:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-11 14:47 Max Rothman
2017-10-11 18:09 ` Stefan Beller
2017-10-12 17:41   ` Max Rothman
2017-10-24 15:32     ` Max Rothman
     [not found]     ` <>
2017-10-24 15:32       ` Stefan Beller
2017-11-02 20:25         ` Max Rothman
2017-11-02 21:19           ` Stefan Beller
2017-11-07 20:31             ` Max Rothman
2017-11-07 20:48               ` Stefan Beller [this message]
2017-11-07 21:22                 ` [PATCH] completion: add missing completions for log, diff, show Max Rothman
2017-11-08  2:33                   ` Junio C Hamano
2017-11-08  3:30                     ` Max Rothman
2017-11-08  4:06                       ` Junio C Hamano
2019-07-02  1:56                   ` Max Rothman
2019-08-02  0:54                     ` Max Rothman
2019-09-11 18:15                       ` Max Rothman
2019-09-12  8:54                         ` Johannes Schindelin
2019-09-12 19:47                           ` Junio C Hamano
     [not found]                           ` <>
2019-09-13 21:03                             ` Johannes Schindelin

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: No log --no-decorate completion?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

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).