perf-lib: split starting the test from the execution

Separate the execution part to make future changes to the tests simpler.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
perf-lib: add test_perf_cleanup target

Currently there is no way to clean up the changes that have been made
with test_perf for the next run.  Add a way to reset the repository to
the state before the test for testing commands that modify the git
repository, e.g. for perf testing git add.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
graph: stuff the current commit into graph->columns[]

When advancing to the next commit, graph_update_columns() prepares
graph->new_columns[] to hold the graph lines leading to ancestor
commits we know about but yet to be emitted, using graph->columns[]
that was prepared during the previous round.  The function and
graph_next_line() function assume that the current commit they are
handling may not exist in graph->columns[] (which can happen when we
haven't seen nor shown any of its descendant commit) and append at
the end after showing what are in graph->columns[].

We should be able to instead stuff the current commit, if it is not
yet in graph->columns[], inside graph_update_columns(), which may
help in later steps to lose these special cases.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
graph: remove unused code a bit

Thanks to the previous step, now we know our current commit always
appear somewhere in graph->columns[] array.  It is no longer
necessary to loop one more iteration just in case we didn't find it
in graph->columns[] and pretend to add it at the end.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
WIP: document what we want at the end
t7505: add missing &&

Signed-off-by: Ryan Biesemeyer <ryan@yaauie.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t7505: ensure cleanup after hook blocks merge

Signed-off-by: Ryan Biesemeyer <ryan@yaauie.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge: make prepare_to_commit responsible for write_merge_state

When merging, make the prepare-commit-msg hook have access to the merge
state in order to make decisions about the commit message it is preparing.

Since `abort_commit` is *only* called after `write_merge_state`, and a
successful commit *always* calls `drop_save` to clear the saved state, this
change effectively ensures that the merge state is also available to the
prepare-commit-msg hook and while the message is being edited.

Signed-off-by: Ryan Biesemeyer <ryan@yaauie.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge: drop unused arg from abort_commit method signature

Since abort_commit is no longer responsible for writing merge state, remove
the unused argument that was originally needed solely for writing merge state.

Signed-off-by: Ryan Biesemeyer <ryan@yaauie.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
show-branch.c: update comment style

Signed-off-by: Junio C Hamano <gitster@pobox.com>
show-branch.c: lift all_mask/all_revs to a global static

Also make them and other flags unsigned.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
show-branch.c: abstract out "flags" operation

The current code knows how "flags" are used to record reachability
from each "rev" too much.  Move as much knowledge as possible out of
the main traversal logic about commit->object.flags by introducing
wrapper functions.  We still use the higher bits of flags word for
reachability from revs, but eventually we would want to only use the
UNINTERESTING bit to mark common ancestors we do not need to dig
further, and move per-rev bits into commit slabs.
show-branch.c: remove "all_mask"

It is only used at one place, to mask flags that is further masked
with all_revs, which is a proper subset of all_mask, so the use is a
no-op.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
show-branch: use commit slab to represent bitflags of arbitrary width

We still haven't lifted the total number of revs limit that is
hardcoded, but the underlying data structure can now represent
arbitrary number of refs.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-rebase: print name of rev when using shorthand

The output from a successful invocation of the shorthand command
"git rebase -" is something like "Fast-forwarded HEAD to @{-1}",
which includes a relative reference to a revision. Other commands
that use the shorthand "-", such as "git checkout -", typically
display the symbolic name of the revision.

Change rebase to output the symbolic name of the revision when using
the shorthand. For the example above, the new output is
"Fast-forwarded HEAD to master", assuming "@{-1}" is a reference to
"master".

Requested-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Brian Gesiak <modocache@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-add--interactive: Preserve diff heading when splitting hunks

Change the display of hunks in hunk splitting mode to preserve the diff
heading, which hasn't been done ever since the hunk splitting was
initially added in v1.4.4.2-270-g835b2ae.

Splitting the first hunk of this patch will now result in:

    Stage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s
    Split into 2 hunks.
    @@ -792,7 +792,7 @@ sub hunk_splittable {
    [...]

Instead of:

    Stage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]? s
    Split into 2 hunks.
    @@ -792,7 +792,7 @@
    [...]

This makes it easier to use the tool when you're splitting some giant
hunk and can't remember in which function you are anymore.

The diff is somewhat larger than I initially expected because in order
to display the headings in the same color scheme as the output from
git-diff(1) itself I had to split up the code that would previously
color diff output that previously consisted entirely of the fraginfo,
but now consists of the fraginfo and the diff heading (the latter of
which isn't colored).

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SQUASH??? git-add--interactive: Preserve diff heading when splitting hunks

This makes a lot of sense to me. I did notice two interesting quirks,
one of which might be worth addressing.

One, there is a slightly funny artifact in that the hunk header comes
from the top of the context line, and that top is a different position
for each of the split hunks. So in a file like:

  header_A
      content
  header_B
      one
      two
      three
      four

you might have a diff like:

  @@ ... @@ header_A
   header_B
       one
       two
  +    new line 1
       three
  +    new line 2
       four

The hunk header for "new line 1" is "A", because "B" itself is part of
the context. But the hunk header for "new line 2", if it were an
independent hunk, would be "B". We print "A" because we copy it from the
original hunk.

It probably won't matter much in practice (and I can even see an
argument that "A" is the "right" answer). And figuring out "B" here
would be prohibitively difficult, I would think, as it would require
applying the funcname rules internal to git-diff to a hunk that git-diff
itself never actually sees.

Since the output from your patch is strictly better than what we saw
before, I think there is no reason we cannot leave such an improvement
to later (or never).

> The diff is somewhat larger than I initially expected because in order
> to display the headings in the same color scheme as the output from
> git-diff(1) itself I had to split up the code that would previously
> color diff output that previously consisted entirely of the fraginfo,
> but now consists of the fraginfo and the diff heading (the latter of
> which isn't colored).

The func heading is not colored by default, but you can configure it to
be so with color.diff.func. I double-checked the behavior with your
patch: you end up with the uncolored header in the split hunks, because
it is parsed from the uncolored line. Which is not bad, but I think we
can trivially do better, just by adding back in the color as we do with
the fraginfo.
gitweb: Harden UTF-8 handling in generated links

esc_html() ensures that its input is properly UTF-8 encoded and marked
as UTF-8 with to_utf8().  Make esc_param() (used for query parameters
in generated URLs), esc_path_info() (for escaping path_info
components) and esc_url() use it too.

This hardens gitweb against errors in UTF-8 handling; because
to_utf8() is idempotent it won't change correct output.

Reported-by: Michael Wagner <accounts@mwagner.org>
Signed-off-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
userdiff: support C# async methods and correct C# keywords

 - async is in C# 5.0
 - foreach is in C# 1.0
 - instanceof is not a C# keyword (it is in Java). Similar keywords
   are typeof, is, as in C# 1.0
 - default, try are in C# 1.0

Signed-off-by: Sup Yut Sum <ch3cooli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
userdiff: support Java try keyword

try keyword is enhanced in Java 7, see try-with-resources Statement
try (XX yy = new XX()) {
} catch (Exception e){
}

Signed-off-by: Sup Yut Sum <ch3cooli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>