It is possible to select multiple files in the "Unstaged Changes" and
the "Staged Changes" lists. But when hitting Ctrl+T, surprisingly only
one entry is handled, not all selected ones.
Let's just use the same code path as for the "Stage To Commit" and the
"Unstage From Commit" menu items.
This fixes https://github.com/git-for-windows/git/issues/1012
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If there is nothing to stage, there is nothing to stage. Let's not try
to, even if the file list contains nothing at all.
This fixes https://github.com/git-for-windows/git/issues/1075
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously unstaged files can be staged by clicking on them and then
pressing Ctrl+T. Conveniently, the next unstaged file is selected
automatically so that the unstaged files can be staged by repeatedly
pressing Ctrl+T.
When a user hits Ctrl+T one time too many, though, Git GUI used to throw
this exception:
expected number but got ""
expected number but got ""
while executing
"expr {int([lindex [$w tag ranges in_diff] 0])}"
(procedure "toggle_or_diff" line 13)
invoked from within
"toggle_or_diff toggle .vpane.files.workdir.list "
(command bound to event)
Let's just avoid that by skipping the operation when there are no more
files to stage.
This fixes https://github.com/git-for-windows/git/issues/1060
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a 1-line file is augmented by a second line, and the user tries to
stage that single line via the "Stage Line" context menu item, we do not
want to see "apply: corrupt patch at line 5".
The reason for this error was that the hunk header looks like this:
@@ -1 +1,2 @@
but the existing code expects the original range always to contain a
comma. This problem is easily fixed by cutting the string "1 +1,2"
(that Git GUI formerly mistook for the starting line) at the space.
This fixes https://github.com/git-for-windows/git/issues/515
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When merging another branch into ours, if their tree is the same as
the common ancestor's, we can declare that our tree represents the
result of three-way merge. In such a case, the recursive merge
backend incorrectly used to create a commit out of our index, even
when the index has changes.
A recent fix attempted to prevent this by adding a comparison
between "our" tree and the index, but forgot that this check must be
restricted only to the outermost merge. Inner merges performed by
the recursive backend across merge bases are by definition made from
scratch without having any local changes added to the index. The
call to index_has_changes() during an inner merge is working on the
index that has no relation to the merge being performed, preventing
legitimate merges from getting carried out.
Fix it by limiting the check to the outermost merge.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
c3a9ad3117 ("oidset: add iterator methods to oidset", 2017-11-21)
introduced a 'oidset_init()' function in oidset.h, which has void as
return type, but returns an expression.
This makes the solaris compiler fail with:
"oidset.h", line 30: void function cannot return value
As the return type is void, and even the return type of the expression
we're trying to return (oidmap_init) is void just remove the return
statement to fix the compiler error.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Code cleanup.
* js/sequencer-cleanups:
sequencer: do not invent whitespace when transforming OIDs
sequencer: report when noop has an argument
sequencer: remove superfluous conditional
sequencer: strip bogus LF at end of error messages
rebase: do not continue when the todo list generation failed
Code cleanup.
* rs/use-argv-array-in-child-process:
send-pack: use internal argv_array of struct child_process
http: use internal argv_array of struct child_process
Bytes with high-bit set were encoded incorrectly and made
credential helper fail.
* jd/fix-strbuf-add-urlencode-bytes:
strbuf: fix urlencode format string on signed char
"git merge -s recursive" did not correctly abort when the index is
dirty, if the merged tree happened to be the same as the current
HEAD, which has been fixed.
* ew/empty-merge-with-dirty-index:
merge-recursive: avoid incorporating uncommitted changes in a merge
move index_has_changes() from builtin/am.c to merge.c for reuse
t6044: recursive can silently incorporate dirty changes in a merge
When using hard reset or forced checkout with the option to recurse into
submodules, the submodules need to be reset, too.
It turns out that we need to omit the duplicate old argument to read-tree
in all forced cases to omit the 2 way merge and use the more assertive
behavior of reading the specific new tree into the index and updating
the working tree.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When there is a one way merge, each submodule needs to be one way merged
as well, if we're asked to recurse into submodules.
In case of a submodule, check if it is up-to-date, otherwise set the
flag CE_UPDATE, which will trigger an update of it in the phase updating
the tree later.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It turns out that the test replacing a submodule with a file with
the submodule containing an ignored file is incorrectly titled,
because the test put the file in place, but never ignored that file.
When having an untracked file Instead of an ignored file in the
submodule, git should refuse to remove the submodule, but that is
a bug in the implementation of recursing into submodules, such that
the test just passed, removing the untracked file.
Fix the test first; in a later patch we'll fix gits behavior,
that will make sure untracked files are not deleted.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Keep the local branch name as the upstream branch name to avoid confusion.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The GIT_PERF_REPO_NAME env variable is used in
the `aggregate.perl` script to set the 'environment'
field in the JSON Codespeed output.
Let's make it easy to set this variable by setting it
in a config file.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Let's make it possible to set in a config file the URL of
a codespeed server. And then let's make the `run` script
send the perf test results to this URL at the end of the
tests.
This should make is possible to easily automate the process
of running perf tests and having their results available in
Codespeed.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Let's make it possible to set in a config file the output
format (regular or codespeed) of the perf tests.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Let's make it possible to use `git config` type specifiers like
`--int` or `--bool`, so that config values are converted to the
canonical form and easier to use.
This additional argument is now the fourth argument of
get_var_from_env_or_config() instead of the fifth because we
want the default value argument to be unset if it is not
passed, and this is simpler if it is the last argument.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Codespeed (https://github.com/tobami/codespeed/) is an open source
project that can be used to track how some software performs over
time. It stores performance test results in a database and can show
nice graphs and charts on a web interface.
As it can be interesting to use Codespeed to see how Git performance
evolves over time and releases, let's implement a Codespeed output
in "perf/aggregate.perl".
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As we want to implement another kind of output than
the current output for the perf test results, let's
refactor the existing code that outputs the results
in its own print_default_results() function.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The way we check ENV{GIT_PERF_SUBSECTION} could trigger
comparison between undef and "" that may be flagged by
use of strict & warnings. Let's fix that.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It has been reported that strategy arguments are not passed to `git
merge` correctly when rebasing interactively, preserving merges.
The reason is that the strategy arguments are already quoted, and then
quoted again.
This fixes https://github.com/git-for-windows/git/issues/1321
Original-patch-by: Kim Gybels <kgybels@infogroep.be>
Also-reported-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In f506b8e8b5 (git log/diff: add -G<regexp> that greps in the patch text,
2010-08-23) we were hesitant to check if the user requests both -S and
-G at the same time. Now that the pickaxe family also offers --find-object,
which looks slightly more different than the former two, let's add a check
that those are not used at the same time.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sometimes users are given a hash of an object and they want to
identify it further (ex.: Use verify-pack to find the largest blobs,
but what are these? or [1])
One might be tempted to extend git-describe to also work with blobs,
such that `git describe <blob-id>` gives a description as
'<commit-ish>:<path>'. This was implemented at [2]; as seen by the sheer
number of responses (>110), it turns out this is tricky to get right.
The hard part to get right is picking the correct 'commit-ish' as that
could be the commit that (re-)introduced the blob or the blob that
removed the blob; the blob could exist in different branches.
Junio hinted at a different approach of solving this problem, which this
patch implements. Teach the diff machinery another flag for restricting
the information to what is shown. For example:
$ ./git log --oneline --find-object=v2.0.0:Makefile
b2feb64309 Revert the whole "ask curl-config" topic for now
47fbfded53 i18n: only extract comments marked with "TRANSLATORS:"
we observe that the Makefile as shipped with 2.0 was appeared in
v1.9.2-471-g47fbfded53 and in v2.0.0-rc1-5-gb2feb6430b. The
reason why these commits both occur prior to v2.0.0 are evil
merges that are not found using this new mechanism.
[1] https://stackoverflow.com/questions/223678/which-commit-has-this-blob
[2] https://public-inbox.org/git/20171028004419.10139-1-sbeller@google.com/
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently the check whether to perform pickaxing is done via checking
`diffopt->pickaxe`, which contains the command line argument that we
want to pickaxe for. Soon we'll introduce a new type of pickaxing, that
will not store anything in the `.pickaxe` field, so let's migrate the
check to be dependent on pickaxe_opts.
It is not enough to just replace the check for pickaxe by pickaxe_opts,
because flags might be set, but pickaxing was not requested ('-i').
To cope with that, introduce a mask to check only for the bits indicating
the modes of operation.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently flags for pickaxing are found in different places. Unify the
flags into the `pickaxe_opts` field, which will contain any pickaxe related
flags.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This variable is used as a bit field[1], and as we are about to add more
fields, indicate its usage as a bit field by making it unsigned.
[1] containing the bits
#define DIFF_PICKAXE_ALL 1
#define DIFF_PICKAXE_REGEX 2
#define DIFF_PICKAXE_KIND_S 4
#define DIFF_PICKAXE_KIND_G 8
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The same document for "--diff-filter" is included by many
programs in the diff family. Because it mentions all
possible types (added, removed, etc), this may imply to the
reader that all types can be generated by a particular
command. But this isn't necessarily the case; "diff-files"
cannot generally produce an "Added" entry, since the diff is
limited to what is already in the index.
Let's make it clear that the list here is the full one, and
does not imply anything about what a particular invocation
may produce.
Note that conditionally including items (e.g., omitting
"Added" in the git-diff-files manpage) isn't the right
solution here for two reasons:
- The problem isn't diff-files, but doing an index to
working tree diff. "git diff" can do the same diff, but
also has other modes where "Added" does show up.
- The direction of the diff matters. Doing "diff-files -R"
can get you Added entries (but not Deleted ones).
So it's best just to explain that the set of available types
depends on the specific diff invocation.
Reported-by: John Cheng <johnlicheng@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
