There were two problems:
1. We only look at the config variable if there is no module
given on the command line. We checked this by comparing
@ARGV == 0. However, at the time of the comparison, we
have not yet parsed the dashed options, meaning that
"git cvsimport" would read the variable but "git
cvsimport -a" would not. This is fixed by simply moving
the check after the call to getopt.
2. If the config variable did not exist, we were adding an
empty string to @ARGV. The rest of the script, rather
than barfing for insufficient input, would then try to
import the module '', leading to rather confusing error
messages. Based on patch from Emanuele Giaquinta.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Occasionally, in some setups (*cough* forks on repo.or.cz *cough*) some
refs go stale, e.g. when the forkee rebased and lost some objects needed
by the fork. The quick & dirty way to deal with those refs is to delete
them and push them again.
However, git-push first would first fetch the current commit name for the
ref, would receive a null sha1 since the ref does not point to a valid
object, then tell receive-pack that it should delete the ref with this
commit name. delete_ref() would be subsequently be called, and check that
resolve_ref() (which does _not_ check for validity of the object) returns
the same commit name. Which would fail.
The proper fix is to avoid corrupting repositories, but in the meantime
this is a good fix in any case.
Incidentally, some instances of "cd .." in the test cases were fixed, so
that subsequent test cases run in t/trash/ irrespective of the outcome of
the previous test cases.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test passed for the wrong reason: If the script given to --msg-filter
fails, it is expected that git-filter-branch aborts. But the test forgot
to tell the branch name to rewrite, and so git-filter-branch failed due to
incorrect usage.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Especially when using git-cherry-pick, removing files that are unmerged can be
a logical action. This patch merely changes the informative text to be less
confusing.
Signed-off-by: David Symonds <dsymonds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A Porcelain command that uses cherry-pick or revert may make a commit
out of resolved index itself, in which case telling the user to commit
the result is not appropriate at all. This allows GIT_CHERRY_PICK_HELP
environment variable to be set by the calling Porcelain in order to
override the built-in help text.
[jc: this is heavily modified from the original but should be equivalent
in spirit]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Integer variables can have optional 'k', 'm' or 'g' suffix.
config_int() method will return simple decimal number, taking
care of those suffixes.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The user interface provided by the command loop in git-add--interactive
gives the impression that subcommands can only be launched by entering
an integer identifier from 1 through 8.
A "hidden" feature is that any string can be entered, and a regex search
anchored at the beginning of the string is used to find the uniquely
matching option.
This patch makes this feature a little more obvious by highlighting the
first character of each subcommand (for example "patch" is displayed as
"[p]atch").
A new function is added to detect the shortest unique prefix and this
is used to decide what to highlight. Highlighting is also applied when
choosing files.
In the case where the common prefix may be unreasonably large
highlighting is omitted; in this patch the soft limit (above which the
highlighting will be omitted for a particular item) is 0 (in other words,
there is no soft limit) and the hard limit (above which highlighting will
be omitted for all items) is 3, but this can be tweaked.
The actual highlighting is done by the highlight_prefix function, which
will enable us to implement ANSI color code-based highlighting (most
likely using underline or boldface) in the future.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Operations that walk directories or trees, which potentially need to
consult the .gitignore files, used to always try to open the .gitignore
file every time they entered a new directory, even when they ended up
not needing to call excluded() function to see if a path in the
directory is ignored. This was done by push/pop exclude_per_directory()
functions that managed the data in a stack.
This changes the directory walking API to remove the need to call these
two functions. Instead, the directory walk data structure caches the
data used by excluded() function the last time, and lazily reuses it as
much as possible. Among the data the last check used, the ones from
deeper directories that the path we are checking is outside are
discarded, data from the common leading directories are reused, and then
the directories between the common directory and the directory the path
being checked is in are checked for .gitignore file. This is very
similar to the way gitattributes are handled.
This API change also fixes "ls-files -c -i", which called excluded()
without setting up the gitignore data via the old push/pop functions.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Like non-interactive rebase, interactive mode now calls rerere when
appropriate.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new option allows scripts to grab color setting from the user
configuration, translated to ANSI color escape sequence.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Too many people got burned by setting color.diff and color.status to
true when they really should have set it to "auto".
This makes only "always" to do the unconditional colorization, and
change the meaning of "true" to the same as "auto": colorize only when
we are talking to a terminal.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calling 'git pull' with the '--rebase' option, it performs a
fetch + rebase instead of a fetch + merge.
This behavior is more desirable than fetch + pull when a topic branch
is ready to be submitted and needs to be update.
fetch + rebase might also be considered a better workflow with shared
repositories in any case, or for contributors to a centrally managed
repository, such as WINE's.
As a convenience, you can set the default behavior for a branch by
defining the config variable branch.<name>.rebase, which is
interpreted as a bool. This setting can be overridden on the command
line by --rebase and --no-rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It might be POSIX, but there are shells that do not like the
expression 'export VAR=VAL'. To be on the safe side, rewrite them
into 'VAR=VAL' and 'export VAR'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have a file called HEAD in your work tree, many commands that
our scripts feed "HEAD" to would complain about the rev vs path
ambiguity. A solution is to form command line more carefully by
appending -- to them, which makes it clear that we mean HEAD rev not
HEAD file.
This patch would apply to maint.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I use "git diff" (the porcelain) really often, and am almost as often
annoyed that the completions do not know how to complete something simple
as --cached. Now they do.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When checking out another ref, the reflogs already record from which
branch you switched. Do that also when switching to a detached HEAD.
While at it, record also when coming _from_ a detached HEAD.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old way of fixing warnings did not succeed on MinGW. MinGW
does not support C99 printf format strings for size_t [1]. But
gcc on MinGW issues warnings if C99 printf format is not used.
Hence, the old stragegy to avoid warnings fails.
[1] http://www.mingw.org/MinGWiki/index.php/C99
This commits passes arguments of type size_t through a tiny
helper functions that casts to the type expected by the format
string.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit 09fba7a59d.
These tests are superseded by the ones in t5404 (added in
6fa92bf3 and 8736a848), which are more extensive and better
organized.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some users expect that deleting a remote-tracking branch would prevent
fetch from creating it again, so be explcit about that it's not the case.
Also be a little more explicit about what fully merged means.
Signed-off-by: Jan Hudec <bulb@ucw.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The helper functions 'map' and 'skip_commit' were provided to commit
filters by sourcing filter-branch itself. This was done with a certain
environment variable set to indicate that only the functions should be
defined, and the script should return then.
This was really hacky, and it did not work all that well, since the
full path to git-filter-branch was not known at all times.
Avoid that by putting the functions into a variable, and eval'ing
that variable. The commit filter gets these functions by prepending
the variable to the specified commands.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were found with a grep for '$git_dir'; they all
replace a direct access of "$git_dir/refs/..." with a call
to git-rev-parse or git-update-ref.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, if refs were packed, git-cvsimport would assume
that particular refs did not exist. This could lead to, for
example, overwriting previous 'origin' commits that were
packed.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We weren't even testing basic things before, so let's at
least try importing and updating a trivial repository, which
will catch total breakage.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Like when it is already specified through -C, -F or -m to git-commit.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When colors are set to "true" on the repository, the git log output
will contain control characters to set/reset the colors, even when
the output is to a pipe. This makes list_stash() fail as the
downstream sed does not see what it is expecting.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that git-status is builtin on Cygwin this compiles as
git-status.exe. We cannot continue to include git-status
as a Makefile target as it will never be built.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using the helper function to test for absolute paths makes porting easier.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The editor program to let the user edit the log message used to
get GIT_INDEX_FILE environment variable pointing at the right
file, but this was lost when git-commit was rewritten in C.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Acked-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This detects a regression introduced while moving git-tag to a C
builtin.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
user-manual: recovering from corruption
user-manual: clarify language about "modifying" old commits
user-manual: failed push to public repository
user-manual: define "branch" and "working tree" at start
git-checkout: describe detached head correctly
* 'maint' of git://linux-nfs.org/~bfields/git:
user-manual: recovering from corruption
user-manual: clarify language about "modifying" old commits
user-manual: failed push to public repository
user-manual: define "branch" and "working tree" at start
Some instructions on dealing with corruption of the object database.
Most of this text is from an example by Linus, identified by Nicolas
Pitre <nico@cam.org> with a little further editing by me.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
When we fail to open a temporary file to be renamed to something else,
we reported the final filename, not the temporary file we failed to
open.
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's important to remember that git doesn't really allowing "editing" or
"modifying" commits, only replacing them by new commits. Redo some of
the language to make this clearer.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
When you cherry-pick or revert a commit, naming it with an annotated
tag, we added a comment, attempting to repeat what we got from the end
user, to the message.
But this was inconsistent. When we got "cherry-pick branch", we
recorded the object name (40-letter SHA-1) without saying anything like
"original was 'branch'". There was no need to. Also recent rewrite to
use parse-options made it impossible to parrot the original command line
without "unparsing".
This removes the code that implements the misguided "we dereferenced the
tag so record that in the commit message" behaviour.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the "--patch" option is supplied, the patch_update_cmd() function is
called bypassing the main_loop() and exits.
Seeing as builtin-add is the only caller of git-add--interactive we can
impose a strict requirement on the format of the arguments to avoid
possible ambiguity: an "--" argument must be used whenever any pathspecs
are passed, both with the "--patch" option and without it.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
When you have a file called HEAD in the work tree, the code to report
where the HEAD is at when "git checkout $commit^0" is done triggered
unnecessary ambiguity checking.
Explicitly mark the command line with "--" and make it clear that we are
talking about a revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes the pathspec interactive_add() passes to the underlying
git-add--interactive helper. When the command was run from a
subdirectory, cmd_add() already has gone up to the toplevel of the work
tree, and the helper will be spawned from there. The pathspec given on
the command line from the user needs to be adjusted for this.
This adds "validate_pathspec()" function in the callchain, but it does
not validate yet. The function can be changed to barf if there are
unmatching pathspec given by the user, but that is not strictly
necessary.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
