aboutsummaryrefslogtreecommitdiff
path: root/builtin/stripspace.c
Commit message (Collapse)AuthorAge
* stripspace: respect repository configJohannes Schindelin2016-11-21
| | | | | | | | | | | | | | | | | | | | | | | | | The way "git stripspace" reads the configuration was not quite kosher, in that the code forgot to probe for a possibly existing repository (note: stripspace is designed to be usable outside the repository as well). It read .git/config only when it was run from the top-level of the working tree by accident. A recent change b9605bc4f2 ("config: only read .git/config from configured repos", 2016-09-12) stopped reading the repository-local configuration file ".git/config" unless the repository discovery process is done, so that .git/config is never read even when run from the top-level, exposing the old bug more. When rebasing interactively with a commentChar defined in the current repository's config, the help text at the bottom of the edit script potentially used an incorrect comment character. This was not only funny-looking, but also resulted in tons of warnings like this one: Warning: the command isn't recognized in the following line - # Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* stripspace: call U+0020 a "space" instead of a "blank"Alex Henrie2016-01-29
| | | | | | | | I couldn't find any other examples of people referring to this character as a "blank". Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'tk/stripspace'Junio C Hamano2015-10-26
|\ | | | | | | | | | | | | | | | | | | The internal stripspace() function has been moved to where it logically belongs to, i.e. strbuf API, and the command line parser of "git stripspace" has been updated to use the parse_options API. * tk/stripspace: stripspace: use parse-options for command-line parsing strbuf: make stripspace() part of strbuf
| * stripspace: use parse-options for command-line parsingTobias Klauser2015-10-16
| | | | | | | | | | | | | | | | | | Use parse-options to parse command-line options instead of a hand-crafted implementation. The users can now use a unique prefix of the long option to say e.g. "git stripspace --strip". Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * strbuf: make stripspace() part of strbufTobias Klauser2015-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function is also used in other builtins than stripspace, so it makes sense to have it in a more generic place. Since it operates on an strbuf and the function is declared in strbuf.h, move it to strbuf.c and add the corresponding prefix to its name, just like other API functions in the strbuf_* family. Also switch all current users of stripspace() to the new function name and keep a temporary wrapper inline function for any topic branches still using stripspace(). Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | usage: do not insist that standard input must come from a fileJunio C Hamano2015-10-16
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The synopsys text and the usage string of subcommands that read list of things from the standard input are often shown like this: git gostak [--distim] < <list-of-doshes> This is problematic in a number of ways: * The way to use these commands is more often to feed them the output from another command, not feed them from a file. * Manual pages outside Git, commands that operate on the data read from the standard input, e.g "sort", "grep", "sed", etc., are not described with such a "< redirection-from-file" in their synopsys text. Our doing so introduces inconsistency. * We do not insist on where the output should go, by saying git gostak [--distim] < <list-of-doshes> > <output> * As it is our convention to enclose placeholders inside <braket>, the redirection operator followed by a placeholder filename becomes very hard to read, both in the documentation and in the help text. Let's clean them all up, after making sure that the documentation clearly describes the modes that take information from the standard input and what kind of things are expected on the input. [jc: stole example for fmt-merge-msg from Jonathan] Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin/stripspace.c: fix broken indentationMatthieu Moy2013-09-06
| | | | | Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Allow custom "comment char"Junio C Hamano2013-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Some users do want to write a line that begin with a pound sign, #, in their commit log message. Many tracking system recognise a token of #<bugid> form, for example. The support we offer these use cases is not very friendly to the end users. They have a choice between - Don't do it. Avoid such a line by rewrapping or indenting; and - Use --cleanup=whitespace but remove all the hint lines we add. Give them a way to set a custom comment char, e.g. $ git -c core.commentchar="%" commit so that they do not have to do either of the two workarounds. [jc: although I started the topic, all the tests and documentation updates, many of the call sites of the new strbuf_add_commented_*() functions, and the change to git-submodule.sh scripted Porcelain are from Ralf.] Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Update documentation for stripspaceConrad Irwin2011-12-12
| | | | | | | | Tell the user what this command is intended for, and expand the description of what it does. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* stripspace: fix outdated commentJeff King2011-12-05
| | | | | | | | | The comment on top of stripspace() claims that the buffer will no longer be NUL-terminated. However, this has not been the case at least since the move to using strbuf in 2007. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Move 'builtin-*' into a 'builtin/' subdirectoryLinus Torvalds2010-02-22
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>