<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/git.git, branch bc/rev-parse-parseopt-fix</title>
<subtitle>github.com: git/git.git
</subtitle>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/'/>
<entry>
<title>parse-options: only insert newline in help text if needed</title>
<updated>2017-09-25T05:35:53+00:00</updated>
<author>
<name>Brandon Casey</name>
<email>drafnel@gmail.com</email>
</author>
<published>2017-09-25T04:08:05+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=a6304fa4c2f57b08ec0acea9f91c188f284f8374'/>
<id>a6304fa4c2f57b08ec0acea9f91c188f284f8374</id>
<content type='text'>
Currently, when parse_options() produces a help message it always emits
a blank line after the usage text to separate it from the options text.
If the option spec does not define any switches, or only defines hidden
switches that will not be displayed, then the help text will end up with
two trailing blank lines instead of one.  Let's defer emitting the blank
line between the usage text and the options text until it is clear that
the options section will not be empty.

Fixes t1502.5, t1502.6.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, when parse_options() produces a help message it always emits
a blank line after the usage text to separate it from the options text.
If the option spec does not define any switches, or only defines hidden
switches that will not be displayed, then the help text will end up with
two trailing blank lines instead of one.  Let's defer emitting the blank
line between the usage text and the options text until it is clear that
the options section will not be empty.

Fixes t1502.5, t1502.6.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parse-options: write blank line to correct output stream</title>
<updated>2017-09-25T05:35:52+00:00</updated>
<author>
<name>Brandon Casey</name>
<email>drafnel@gmail.com</email>
</author>
<published>2017-09-25T04:08:04+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=1a9bf1e176439d415b97fb8c5a556f69ea503877'/>
<id>1a9bf1e176439d415b97fb8c5a556f69ea503877</id>
<content type='text'>
When commit 54e6dc7 added translation support to parse-options, an
fprintf was mistakenly replaced by a call to putchar().  Let's use fputc
instead.

Fixes t0040.11, t0040.12, t0040.33, and t1502.8.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When commit 54e6dc7 added translation support to parse-options, an
fprintf was mistakenly replaced by a call to putchar().  Let's use fputc
instead.

Fixes t0040.11, t0040.12, t0040.33, and t1502.8.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>t0040,t1502: Demonstrate parse_options bugs</title>
<updated>2017-09-25T05:35:50+00:00</updated>
<author>
<name>Brandon Casey</name>
<email>drafnel@gmail.com</email>
</author>
<published>2017-09-25T04:08:03+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=c97ee171a6b5a7e41234d46341b496146fa08bf1'/>
<id>c97ee171a6b5a7e41234d46341b496146fa08bf1</id>
<content type='text'>
When the option spec contains no switches or only hidden switches,
parse_options will emit an extra blank line at the end of help output so
that the help text will end in two blank lines instead of one.

When parse_options produces internal help output after an error has
occurred it will emit blank lines within the usage string to stdout
instead of stderr.

Update t/helper/test-parse-options.c to have a description body in the
usage string to exercise this second bug and mark tests as failing in
t0040.

Add tests to t1502 to demonstrate both of these problems.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When the option spec contains no switches or only hidden switches,
parse_options will emit an extra blank line at the end of help output so
that the help text will end in two blank lines instead of one.

When parse_options produces internal help output after an error has
occurred it will emit blank lines within the usage string to stdout
instead of stderr.

Update t/helper/test-parse-options.c to have a description body in the
usage string to exercise this second bug and mark tests as failing in
t0040.

Add tests to t1502 to demonstrate both of these problems.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>git-rebase: don't ignore unexpected command line arguments</title>
<updated>2017-09-19T03:13:09+00:00</updated>
<author>
<name>Brandon Casey</name>
<email>drafnel@gmail.com</email>
</author>
<published>2017-09-17T22:28:17+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=697bc8858114ddda705be6f6eb3f997b64efa659'/>
<id>697bc8858114ddda705be6f6eb3f997b64efa659</id>
<content type='text'>
Currently, git-rebase will silently ignore any unexpected command-line
switches and arguments (the command-line produced by git rev-parse).
This allowed the rev-parse bug, fixed in the preceding commits, to go
unnoticed.  Let's make sure that doesn't happen again.  We shouldn't be
ignoring unexpected arguments.  Let's not.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, git-rebase will silently ignore any unexpected command-line
switches and arguments (the command-line produced by git rev-parse).
This allowed the rev-parse bug, fixed in the preceding commits, to go
unnoticed.  Let's make sure that doesn't happen again.  We shouldn't be
ignoring unexpected arguments.  Let's not.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rev-parse parseopt: interpret any whitespace as start of help text</title>
<updated>2017-09-19T03:13:08+00:00</updated>
<author>
<name>Brandon Casey</name>
<email>drafnel@gmail.com</email>
</author>
<published>2017-09-17T22:28:16+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=33e75122f483f887d4db7ccec01f42dea7ee79fb'/>
<id>33e75122f483f887d4db7ccec01f42dea7ee79fb</id>
<content type='text'>
Currently, rev-parse only interprets a space ' ' character as the
delimiter between the option spec and the help text.  So if a tab
character is placed between the option spec and the help text, it will
be interpreted as part of the long option name or as part of the arg
hint.  If it is interpreted as part of the long option name, then
rev-parse will produce what will be interpreted as multiple arguments
on the command line.

For example, the following option spec (note: there is a &lt;tab&gt; between
"frotz" and "enable"):

    frotz	enable frotzing

will produce the following set expression when --frotz is used:

    set -- --frotz --

instead of this:

    set -- --frotz  enable --

Mark t1502.2 as fixed.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, rev-parse only interprets a space ' ' character as the
delimiter between the option spec and the help text.  So if a tab
character is placed between the option spec and the help text, it will
be interpreted as part of the long option name or as part of the arg
hint.  If it is interpreted as part of the long option name, then
rev-parse will produce what will be interpreted as multiple arguments
on the command line.

For example, the following option spec (note: there is a &lt;tab&gt; between
"frotz" and "enable"):

    frotz	enable frotzing

will produce the following set expression when --frotz is used:

    set -- --frotz --

instead of this:

    set -- --frotz  enable --

Mark t1502.2 as fixed.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rev-parse parseopt: do not search help text for flag chars</title>
<updated>2017-09-19T03:13:07+00:00</updated>
<author>
<name>Brandon Casey</name>
<email>drafnel@gmail.com</email>
</author>
<published>2017-09-17T22:28:15+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=28a8d0f77a27646dcbd87f0718b79501113cb82c'/>
<id>28a8d0f77a27646dcbd87f0718b79501113cb82c</id>
<content type='text'>
When searching for flag characters in the option spec, we should ensure
the search stays within the bounds of the option spec and does not enter
the help text portion of the spec.  So when we find the boundary white
space marking the start of the help text, let's mark it with a nul
character.  Then when we search for flag characters starting from the
beginning of the string we'll stop at the nul and won't enter the help
text.

Now, the following option spec:

    exclame this does something!

will produce this 'set' expression when --exclame is specified:

    set -- --exclame --

instead of this one:

    set -- --exclame this does something --

Mark t1502.4 and t1502.5 as fixed.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When searching for flag characters in the option spec, we should ensure
the search stays within the bounds of the option spec and does not enter
the help text portion of the spec.  So when we find the boundary white
space marking the start of the help text, let's mark it with a nul
character.  Then when we search for flag characters starting from the
beginning of the string we'll stop at the nul and won't enter the help
text.

Now, the following option spec:

    exclame this does something!

will produce this 'set' expression when --exclame is specified:

    set -- --exclame --

instead of this one:

    set -- --exclame this does something --

Mark t1502.4 and t1502.5 as fixed.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>t1502: demonstrate rev-parse --parseopt option mis-parsing</title>
<updated>2017-09-19T03:13:05+00:00</updated>
<author>
<name>Brandon Casey</name>
<email>drafnel@gmail.com</email>
</author>
<published>2017-09-17T22:28:14+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=f221861e490d2c57b960cf86c5bc37279a3ebc2b'/>
<id>f221861e490d2c57b960cf86c5bc37279a3ebc2b</id>
<content type='text'>
Since commit 2d893df rev-parse will scan forward from the beginning of
the option string looking for a flag character.  If there are no flag
characters then the scan will spill over into the help text and will
interpret the characters preceding the "flag" as part of the option-spec
i.e. the long option name.

For example, the following option spec:

    exclame this does something!

will produce this 'set' expression when --exclame is specified:

    set -- --exclame this does something --

which will be interpreted as four separate parameters by the shell.  And
will produce a help string that looks like:

    --exclame this does something
                          this does something!

git-rebase.sh has such an option (--autosquash), and so will add extra
parameters to the 'set' expression when --autosquash is used.
git-rebase continues to work correctly though because when it parses the
arguments, it ignores ones that it does not recognize.

Also, rev-parse --parseopt does not currently interpret a tab character
as a delimiter between the option spec and the help text.  If a tab is
used at the end of the option spec, before the help text, and before a
space has been specified, then rev-parse will interpret the tab as part
of the preceding component (either the long name or the arg hint).

For example, the following option spec (note: there is a &lt;tab&gt; between
"frotz" and "enable"):

    frotz	enable frotzing

will produce this 'set' expression when --frotz is specified:

    set -- --frotz  enable --

which will be interpreted as 2 separate arguments by the shell.

git-rebase.sh has one of these too (--keep-empty).  In this case the tab
is immediately followed by spaces so there are no additional parameters
produced on the command line.  The only side-effect is misalignment in
the help text.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since commit 2d893df rev-parse will scan forward from the beginning of
the option string looking for a flag character.  If there are no flag
characters then the scan will spill over into the help text and will
interpret the characters preceding the "flag" as part of the option-spec
i.e. the long option name.

For example, the following option spec:

    exclame this does something!

will produce this 'set' expression when --exclame is specified:

    set -- --exclame this does something --

which will be interpreted as four separate parameters by the shell.  And
will produce a help string that looks like:

    --exclame this does something
                          this does something!

git-rebase.sh has such an option (--autosquash), and so will add extra
parameters to the 'set' expression when --autosquash is used.
git-rebase continues to work correctly though because when it parses the
arguments, it ignores ones that it does not recognize.

Also, rev-parse --parseopt does not currently interpret a tab character
as a delimiter between the option spec and the help text.  If a tab is
used at the end of the option spec, before the help text, and before a
space has been specified, then rev-parse will interpret the tab as part
of the preceding component (either the long name or the arg hint).

For example, the following option spec (note: there is a &lt;tab&gt; between
"frotz" and "enable"):

    frotz	enable frotzing

will produce this 'set' expression when --frotz is specified:

    set -- --frotz  enable --

which will be interpreted as 2 separate arguments by the shell.

git-rebase.sh has one of these too (--keep-empty).  In this case the tab
is immediately followed by spaces so there are no additional parameters
produced on the command line.  The only side-effect is misalignment in
the help text.

Signed-off-by: Brandon Casey &lt;drafnel@gmail.com&gt;
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>RelNotes: further fixes for 2.14.2 from the master front</title>
<updated>2017-09-10T08:06:09+00:00</updated>
<author>
<name>Junio C Hamano</name>
<email>gitster@pobox.com</email>
</author>
<published>2017-09-10T08:06:09+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=94c9fd268d4287f6fbfef84793288479905a7e48'/>
<id>94c9fd268d4287f6fbfef84793288479905a7e48</id>
<content type='text'>
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Junio C Hamano &lt;gitster@pobox.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'jt/doc-pack-objects-fix' into maint</title>
<updated>2017-09-10T08:03:10+00:00</updated>
<author>
<name>Junio C Hamano</name>
<email>gitster@pobox.com</email>
</author>
<published>2017-09-10T08:03:10+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=60f4851bb26b64970f2204fbd227273e68dc314d'/>
<id>60f4851bb26b64970f2204fbd227273e68dc314d</id>
<content type='text'>
Doc updates.

* jt/doc-pack-objects-fix:
  Doc: clarify that pack-objects makes packs, plural
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Doc updates.

* jt/doc-pack-objects-fix:
  Doc: clarify that pack-objects makes packs, plural
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'jn/vcs-svn-cleanup' into maint</title>
<updated>2017-09-10T08:03:09+00:00</updated>
<author>
<name>Junio C Hamano</name>
<email>gitster@pobox.com</email>
</author>
<published>2017-09-10T08:03:09+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/git.git/commit/?id=8134746d1d33fffc3a94030c2af576e3738a037c'/>
<id>8134746d1d33fffc3a94030c2af576e3738a037c</id>
<content type='text'>
Code clean-up.

* jn/vcs-svn-cleanup:
  vcs-svn: move remaining repo_tree functions to fast_export.h
  vcs-svn: remove repo_delete wrapper function
  vcs-svn: remove custom mode constants
  vcs-svn: remove more unused prototypes and declarations
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Code clean-up.

* jn/vcs-svn-cleanup:
  vcs-svn: move remaining repo_tree functions to fast_export.h
  vcs-svn: remove repo_delete wrapper function
  vcs-svn: remove custom mode constants
  vcs-svn: remove more unused prototypes and declarations
</pre>
</div>
</content>
</entry>
</feed>
