On Tue, Nov 7, 2017 at 12:31 PM, Max Rothman <max.r.rothman@xxxxxxxxx> 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 >> https://developercertificate.org/) > > 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 https://submitgit.herokuapp.com/ >> (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<CAFA_24L5nTUhO=PbMB9SdnCB1Lj+5rmOHmMJwkuLGWgy-ooxBA@xxxxxxxxxxxxxx> 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. https://public-inbox.org/git/CAFA_24L5nTUhO=PbMB9SdnCB1Lj+5rmOHmMJwkuLGWgy-ooxBA@xxxxxxxxxxxxxx is your email there. Thanks, Stefan
