* js/mingw-fallouts:
fetch-pack: Prepare for a side-band demultiplexer in a thread.
rehabilitate some t5302 tests on 32-bit off_t machines
Allow ETC_GITCONFIG to be a relative path.
Introduce git_etc_gitconfig() that encapsulates access of ETC_GITCONFIG.
Allow a relative builtin template directory.
Close files opened by lock_file() before unlinking.
builtin run_command: do not exit with -1.
Move #include <sys/select.h> and <sys/ioctl.h> to git-compat-util.h.
Use is_absolute_path() in sha1_file.c.
Skip t3902-quoted.sh if the file system does not support funny names.
t5302-pack-index: Skip tests of 64-bit offsets if necessary.
t7501-commit.sh: Not all seds understand option -i
t5300-pack-object.sh: Split the big verify-pack test into smaller parts.
* bs/maint-commit-options:
git-commit: Add tests for invalid usage of -a/--interactive with paths
git-commit.sh: Fix usage checks regarding paths given when they do not make sense
git-commit was/is broken in that it accepts paths together with -a or
--interactive, which it shouldn't. There tests check those usage errors.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because a partial commit is meant to be a way to ignore what are
staged in the index, "git rm --cached A && git commit A" should
just record what is in A on the filesystem. The previous patch
made the command sequence to barf, saying that A has not been
added yet. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When making a partial commit, git-commit uses git-ls-files with
the --error-unmatch option to expand and sanity check the user
supplied path patterns. When any path pattern does not match
with the paths known to the index, it errors out, in order to
catch a common mistake to say "git commit Makefiel cache.h"
and end up with a commit that touches only cache.h (notice the
misspelled "Makefile"). This detection however does not work
well when the path has already been removed from the index.
If you drop a path from the index and try to commit that
partially, i.e.
$ git rm COPYING
$ git commit -m 'Remove COPYING' COPYING
the command complains because git does not know anything about
COPYING anymore.
This introduces a new option --with-tree to git-ls-files and
uses it in git-commit when we build a temporary index to
write a tree object for the partial commit.
When --with-tree=<tree-ish> option is specified, names from the
given tree are added to the set of names the index knows about,
so we can treat COPYING file in the example as known.
Of course, there is no reason to use "git rm" and git-aware
people have long time done:
$ rm COPYING
$ git commit -m 'Remove COPYING' COPYING
which works just fine. But this caused a constant confusion.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because a partial commit is meant to be a way to ignore what are
staged in the index, "git rm --cached A && git commit A" should
just record what is in A on the filesystem. The previous patch
made the command sequence to barf, saying that A has not been
added yet. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When making a partial commit, git-commit uses git-ls-files with
the --error-unmatch option to expand and sanity check the user
supplied path patterns. When any path pattern does not match
with the paths known to the index, it errors out, in order to
catch a common mistake to say "git commit Makefiel cache.h"
and end up with a commit that touches only cache.h (notice the
misspelled "Makefile"). This detection however does not work
well when the path has already been removed from the index.
If you drop a path from the index and try to commit that
partially, i.e.
$ git rm COPYING
$ git commit -m 'Remove COPYING' COPYING
the command complains because git does not know anything about
COPYING anymore.
This introduces a new option --with-tree to git-ls-files and
uses it in git-commit when we build a temporary index to
write a tree object for the partial commit.
When --with-tree=<tree-ish> option is specified, names from the
given tree are added to the set of names the index knows about,
so we can treat COPYING file in the example as known.
Of course, there is no reason to use "git rm" and git-aware
people have long time done:
$ rm COPYING
$ git commit -m 'Remove COPYING' COPYING
which works just fine. But this caused a constant confusion.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
[jc: adjusted t/t7501 as this makes -F and --amend compatible]
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
