Conrad Irwin <conrad.ir...@gmail.com> writes:
> - Before making a commit out of staged contents so far,
> - stage the contents of paths given on the command line
> - as well. This is usually not what you want unless you
> - are concluding a conflicted merge.
> + In addition to the paths specified on the command line,
> + include the current contents of the index in the commit.
"commit" is about committing what is in the index. include has
always meant "in addition, include the contents of listed paths
in the resulting commit".
The updated text looks totally the other way around.
> - Make a commit only from the paths specified on the
> - command line, disregarding any contents that have been
> - staged so far. This is the default mode of operation of
> - 'git commit' if any paths are given on the command line,
> - in which case this option can be omitted.
> - If this option is specified together with '--amend', then
> - no paths need to be specified, which can be used to amend
> - the last commit without committing changes that have
> - already been staged.
> + Only commit changes to the paths specified on the command line,
> + do not include the current contents of the index. This is
> + the default mode of operation when paths are specified.
> + If this option is specified with --amend it can be used
> + to reword the last commit without changing its contents.
> + This mode cannot be used with --patch or --interactive.
The new text on this one does look cleaner and easier to read, at
least to me, but "do not include the current contents" sounds as if
you are recording a tree that only has Makefile and losing all the
other files when you say "git commit Makefile".
Disregard what has been added to the index since HEAD, and only
commit changes to the given paths.
might be an improvement, but I dunno.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html