merge hook tests: fix missing '&&' in test

Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge hook tests: use 'test_must_fail' instead of '!'

Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fsck.c:fsck_ident(): ident points at a const string

Since fsck_ident doesn't change the content of **ident, the type of
ident could be const char **.

This change is required to rewrite fsck_commit() to use skip_prefix().

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pack-objects: show progress for reused packfiles

When the "--all-progress" option is in effect, pack-objects
shows a progress report for the "writing" phase. If the
repository has bitmaps and we are reusing a packfile, the
user sees no progress update until the whole packfile is
sent.  Since this is typically the bulk of what is being
written, it can look like git hangs during this phase, even
though the transfer is proceeding.

This generally only happens with "git push" from a
repository with bitmaps. We do not use "--all-progress" for
fetch (since the result is going to index-pack on the
client, which takes care of progress reporting). And for
regular repacks to disk, we do not reuse packfiles.

We already have the progress meter setup during
write_reused_pack; we just need to call display_progress
whiel we are writing out the pack. The progress meter is
attached to our output descriptor, so it automatically
handles the throughput measurements.

However, we need to update the object count as we go, since
that is what feeds the percentage we show. We aren't
actually parsing the packfile as we send it, so we have no
idea how many objects we have sent; we only know that at the
end of N bytes, we will have sent M objects. So we cheat a
little and assume each object is M/N bytes (i.e., the mean
of the objects we are sending). While this isn't strictly
true, it actually produces a more pleasing progress meter
for the user, as it moves smoothly and predictably (and
nobody really cares about the object count; they care about
the percentage, and the object count is a proxy for that).

One alternative would be to actually show two progress
meters: one for the reused pack, and one for the rest of the
objects. That would more closely reflect the data we have
(the first would be measured in bytes, and the second
measured in objects). But it would also be more complex and
annoying to the user; rather than seeing one progress meter
counting up to 100%, they would finish one meter, then start
another one at zero.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pack-objects: show reused packfile objects in "Counting objects"

When we are sending a pack for push or fetch, we may reuse a
chunk of packfile without even parsing it. The progress
meter then looks like this:

  Reusing existing pack: 3440489, done.
  Counting objects: 3, done.

The first line shows that we are reusing a large chunk of
objects, and then we further count any objects not included
in the reused portion with an actual traversal.

These are all implementation details that the user does not
need to care about. Instead, we can show the reused objects
in the normal "counting..." progress meter (which will
simply go much faster than normal), and then continue to add
to it as we traverse.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pack-objects: turn off bitmaps when skipping objects

The pack bitmap format requires that we have a single bit
for each object in the pack, and that each object's bitmap
represents its complete set of reachable objects. Therefore
we have no way to represent the bitmap of an object which
references objects outside the pack.

We notice this problem while generating the bitmaps, as we
try to find the offset of a particular object and realize
that we do not have it. In this case we die, and neither the
bitmap nor the pack is generated. This is correct, but
perhaps a little unfriendly. If you have bitmaps turned on
in the config, many repacks will fail which would otherwise
succeed. E.g., incremental repacks, repacks with "-l" when
you have alternates, ".keep" files.

Instead, this patch notices early that we are omitting some
objects from the pack and turns off bitmaps (with a
warning). Note that this is not strictly correct, as it's
possible that the object being omitted is not reachable from
any other object in the pack. In practice, this is almost
never the case, and there are two advantages to doing it
this way:

  1. The code is much simpler, as we do not have to cleanly
     abort the bitmap-generation process midway through.

  2. We do not waste time partially generating bitmaps only
     to find out that some object deep in the history is not
     being packed.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
subtree: initialize "prefix" variable

We parse the "--prefix" command-line option into the
"$prefix" shell variable. However, if we do not see such an
option, the variable is left with whatever value it had in
the environment. We should initialize it to a known value,
like we do for other variables.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test patch hunk editing with "commit -p -m"

Add (failing) tests: with commit changing the environment to let hooks
know that no editor will be used (by setting GIT_EDITOR to ":"), the
"edit hunk" functionality does not work (no editor is launched and the
whole hunk is committed).

Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit: fix patch hunk editing with "commit -p -m"

Don't change git environment: move the GIT_EDITOR=":" override to the
hook command subprocess, like it's already done for GIT_INDEX_FILE.

Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge: fix GIT_EDITOR override for commit hook

Don't set GIT_EDITOR to ":" when calling prepare-commit-msg hook if the
editor is going to be called (e.g. with "merge -e").

Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge hook tests: fix and update tests

- update 'no editor' hook test and add 'editor' hook test
- make sure the tree is reset to a clean state after running a test
  (using test_when_finished) so later tests are not impacted

Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
run-command: mark run_hook_with_custom_index as deprecated

Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
add: use struct argv_array in run_add_interactive()

run_add_interactive() in builtin/add.c manually computes array bounds
and allocates a static args array to build the add--interactive command
line, which is error-prone. Use the argv-array helper functions instead.

Signed-off-by: Fabian Ruch <bafain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase: allow "-" short-hand for the previous branch

Teach rebase the same shorthand as checkout and merge to name the
branch to rebase the current branch on; that is, that "-" means "the
branch we were previously on".

Requested-by: Tim Chase <git@tim.thechases.com>
Signed-off-by: Brian Gesiak <modocache@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tests: use "env" to run commands with temporary env-var settings

Ordinarily, we would say "VAR=VAL command" to execute a tested
command with environment variable(s) set only for that command.
This however does not work if 'command' is a shell function (most
notably 'test_must_fail'); the result of the assignment is retained
and affects later commands.

To avoid this, we used to assign and export environment variables
and run such a test in a subshell, like so:

        (
                VAR=VAL && export VAR &&
                test_must_fail git command to be tested
        )

But with "env" utility, we should be able to say:

        test_must_fail env VAR=VAL git command to be tested

which is much shorter and easier to read.

Signed-off-by: David Tran <unsignedzero@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fsck.c:fsck_commit(): use skip_prefix() to verify and skip constant

fsck_commit() uses memcmp() to check if the buffer starts with a
certain prefix, and skips the prefix if it does.

This is exactly what skip_prefix() was designed for.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/gitk: document the location of the configulation file

User config file location complies with the XDG base directory
specification while supporting the traditional $HOME/.gitk as a
fallback.

Signed-off-by: Astril Hayato <astrilhayato@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fsck: use bitwise-or assignment operator to set flag

fsck_tree() has two different ways to set a flag variable, either by
using a if-statement that guards an assignment, or by using a
bitwise-or assignment operator.  Most are done with the former, and
only one variable is assigned with the latter.

Since all the conditions are short-and-sweet, we can afford to
uniformly use the latter style, which makes the resulting code
shorter and easier to read.

Signed-off-by: Hiroyuki Sano <sh19910711@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
doc: status, remove leftover statement about '#' prefix

This hasn't been true since 2556b996 (status: disable display of '#'
comment prefix by default, 2013-09-06).

Signed-off-by: Dirk Wallenstein <halsmit@t-online.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
config.txt: third-party tools may and do use their own variables

Signed-off-by: Chris Angelico <rosuav@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>