Instead of showing a warning and working as before, fail and show
the message and force immediate upgrade from their upstream
repositories when these tools are run, per request from their
primary author.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tools are now maintained out-of-tree, and they have a regression
in v2.0. It's better to start warning the users as soon as possible.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit d508e4a8e2,
reversing changes made to e42552135a.
The author of the original topic says he broke the upcoming 2.0
release with something that relates to "synchronization crash
regression" while refusing to give further specifics, so this would
unfortunately be the safest option for the upcoming release.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not all shells subject the prompt string to parameter expansion. Test
whether the shell will expand the value of PS1, and use the result to
control whether raw ref names are included directly in PS1.
This fixes a regression introduced in commit 8976500 ("git-prompt.sh:
don't put unsanitized branch names in $PS1"): zsh does not expand PS1
by default, but that commit assumed it did. The bug resulted in
prompts containing the literal string '${__git_ps1_branch_name}'
instead of the actual branch name.
Reported-by: Caleb Thompson <caleb@calebthompson.io>
Signed-off-by: Richard Hansen <rhansen@bbn.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The highlighting was pretty, but unfortunately, the failure mode
when source-highlight is not installed was that the entire code
block disappears.
See https://bugs.debian.org/745591,
https://bugs.launchpad.net/bugs/1316810.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since git 2.0.0 starting git gui in a submodule using a gitfile fails with
the following error:
No working directory ../../../<path>
couldn't change working directory
to "../../../<path>": no such file or
directory
This is because "git rev-parse --show-toplevel" is only run when git gui
sees a git version of at least 1.7.0 (which is the version in which the
--show-toplevel option was introduced). But "package vsatisfies" returns
false when the major version changes, which is not what we want here.
Fix that for both places where the git version is checked using vsatisfies
by appending a '-' to the version number. This tells vsatisfies that a
change of the major version is not considered to be a problem, as long as
the new major version is larger. This is done for both the place that
caused the reported bug and another spot where the git version is tested
for another feature.
Reported-by: Chris Packham <judge.packham@gmail.com>
Reported-by: Yann Dirson <ydirson@free.fr>
Helped-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Older versions of Git before v1.7.10 did not DWIM
$ git pull $URL for-linus
to the tag "tags/for-linus" and the users were required to say
$ git pull $URL tags/for-linus
instead. Because newer versions of Git works either way,
request-pull used to show tags/for-linus when asked
$ git request-pull origin/master $URL for-linus
The recent updates broke this and in the output we see "for-linus"
without the "tags/" prefix.
As v1.7.10 is more than 2 years old, this should matter very little
in practice, but resurrecting it is very simple.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise it might collide with a function of the same name in the
user's environment.
Suggested-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Quite a large change, most of this was whitespace changes, though there
were a few places where I removed a comma or added a few characters.
Should pass through pep8 and pass every test.
Signed-off-by: William Giokas <1007380@gmail.com>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we fetch a pack that does not contain an object we
expected to receive, we get an error like:
$ git init --bare tmp.git && cd tmp.git
$ git fetch ../parent.git
[...]
error: Could not read 964953ec7bcc0245cb1d0db4095455edd21a2f2e
fatal: Failed to traverse parents of commit b8247b40caf6704fe52736cdece6d6aae87471aa
error: ../parent.git did not send all necessary objects
This comes from the check_everything_connected rev-list. If
we try cloning the same repo (rather than a fetch), we end
up using index-pack's --check-self-contained-and-connected
option instead, which produces output like:
$ git clone --no-local --bare parent.git tmp.git
[...]
fatal: object of unexpected type
fatal: index-pack failed
Not only is the sha1 missing, but it's a misleading message.
There's no type problem, but rather a missing object
problem; we don't notice the difference because we simply
compare OBJ_BAD != OBJ_BLOB. Let's provide a different
message for this case:
$ git clone --no-local --bare parent.git tmp.git
fatal: did not receive expected object 6b00a8c61ed379d5f925a72c1987c9c52129d364
fatal: index-pack failed
While we're at it, let's also improve a true type mismatch
error to look like
fatal: object 6b00a8c61ed379d5f925a72c1987c9c52129d364: expected type blob, got tree
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The functionality of the "git diffall" script in contrib/ was
incorporated into "git difftool" when the --dir-diff option was added
in v1.7.11 (ca. June, 2012). Once difftool learned those features,
the diffall script became obsolete.
The only difference in behavior is that when comparing to the working
tree, difftool copies any files modified by the user back to the
working tree when the diff tool exits. "git diffall" required the
--copy-back option to do the same. All other diffall options have the
same meaning in difftool.
Make life easier for people choosing a tool to use by removing the old
diffall script. A pointer in the release notes should be enough to
help current users migrate.
Helped-by: Tim Henigan <tim.henigan@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git support scripts started shipping in upstream vim in version
7.2 (2008-08-09). Clean up contrib/ a little by removing the
instructions for people on older versions of vim.
RHEL 6 already has vim 7.2.something, so anyone on a reasonably modern
operating system should not be affected. Users on RHEL 5 presumably
know that means sometimes missing out on niceties like syntax
highlighting, so this should be safe.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The third maintenance release for Git 1.9; contains all the fixes
that are scheduled to appear in Git 2.0 since 1.9.2.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a file contained CRLF line endings in a repository with
core.autocrlf=input, then blame always marked lines as "Not
Committed Yet", even if they were unmodified. Don't attempt to
convert the line endings when creating the fake commit so that blame
works correctly regardless of the autocrlf setting.
Reported-by: Ephrim Khong <dr.khong@gmail.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git mv hello.txt Hello.txt" on a case insensitive filesystem
always triggers "destination already exists" error, because these
two names refer to the same path from the filesystem's point of
view, and requires the user to give "--force" when correcting the
case of the path recorded in the index and in the next commit.
Detect this case and allow it without requiring "--force".
Signed-off-by: David Turner <dturner@twitter.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change checkout.c to check if a ref exists instead of checking if a loose ref
file exists when deciding if to delete an orphaned log file. Otherwise, if a
ref only exists as a packed ref without a corresponding loose ref for the
currently checked out branch, we risk that the reflog will be deleted when we
switch to a different branch.
Update the reflog tests to check for this bug.
The following reproduces the bug:
$ git init-db
$ git config core.logallrefupdates true
$ git commit -m Initial --allow-empty
[master (root-commit) bb11abe] Initial
$ git reflog master
[8561dcb master@{0}: commit (initial): Initial]
$ find .git/{refs,logs} -type f | grep master
[.git/refs/heads/master]
[.git/logs/refs/heads/master]
$ git branch foo
$ git pack-refs --all
$ find .git/{refs,logs} -type f | grep master
[.git/logs/refs/heads/master]
$ git checkout foo
$ find .git/{refs,logs} -type f | grep master
... reflog file is missing ...
$ git reflog master
... nothing ...
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
Acked-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add two new functions, reflog_exists and delete_reflog, to hide the internal
reflog implementation (that they are files under .git/logs/...) from callers.
Update checkout.c to use these functions in update_refs_for_switch instead of
building pathnames and calling out to file access functions. Update reflog.c
to use these to check if the reflog exists. Now there are still many places
in reflog.c where we are still leaking the reflog storage implementation but
this at least reduces the number of such dependencies by one. Finally
change two places in refs.c itself to use the new function to check if a ref
exists or not isntead of build-path-and-stat(). Now, this is strictly not all
that important since these are in parts of refs that are implementing the
actual file storage backend but on the other hand it will not hurt either.
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
Acked-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit 4dce7d9b40,
which was originally done to help Windows but was almost
immediately reverted in msysGit, and the codebase kept this
unnecessary divergence for almost two years.
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-shell(1) manpage says
EXAMPLE
To disable interactive logins, displaying a greeting
instead:
+
$ chsh -s /usr/bin/git-shell
$ mkdir $HOME/git-shell-commands
[...]
The stray "+" has been there ever since the example was added in
v1.8.3-rc0~210^2 (shell: new no-interactive-login command to print a
custom message, 2013-03-09). The "+" sign between paragraphs is
needed in asciidoc to attach extra paragraphs to a list item but here
it is not needed and ends up rendered as a literal "+". Remove it.
A quick search with "grep -e '<p>+' /usr/share/doc/git/html/*.html"
doesn't find any other instances of this problem.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git p4" dealing with changes in binary files were broken by a
change in 1.9 release.
* cl/p4-use-diff-tree:
git-p4: format-patch to diff-tree change breaks binary patches
The shell prompt script (in contrib/), when using the PROMPT_COMMAND
interface, used an unsafe construct when showing the branch name in
$PS1.
* rh/prompt-pcmode-avoid-eval-on-refname:
git-prompt.sh: don't put unsanitized branch names in $PS1
"git rebase" used a POSIX shell construct FreeBSD /bin/sh does not
work well with.
* km/avoid-non-function-return-in-rebase:
Revert "rebase: fix run_specific_rebase's use of "return" on FreeBSD"
rebase: avoid non-function use of "return" on FreeBSD
Some more Unicode codepoints defined in Unicode 6.3 as having zero
width have been taught to our display column counting logic.
* tb/unicode-6.3-zero-width:
utf8.c: partially update to version 6.3
Describe one last minute one-liner fix for regression introduced in
1.9, and fix a grave mischaracterization on a recent remote-hg/bzr
change, pointed out by Felipe.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fixes a regression in 1.9.0 with an obviously correct single-liner.
* cl/p4-use-diff-tree:
git-p4: format-patch to diff-tree change breaks binary patches
Display the tag name about to be added to the user during interactive
editing.
Signed-off-by: Thorsten Glaser <tg@debian.org>
Signed-off-by: Richard Hartmann <richih@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On a case-insensitive filesystem, when merging, a file would be
wrongly deleted from the working tree if an incoming commit had
renamed it changing only its case. When merging a rename, the file
with the old name would be deleted -- but since the filesystem
considers the old name to be the same as the new name, the new
file would in fact be deleted.
We avoid this by not deleting files that have a case-clone in the
index at stage 0.
Signed-off-by: David Turner <dturner@twitter.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default, Git used to set $LESS to -FRSX if $LESS was not set by
the user. The FRX flags actually make sense for Git (F and X because
sometimes the output Git pipes to less is short, and R because Git
pipes colored output). The S flag (chop long lines), on the other
hand, is not related to Git and is a matter of user preference. Git
should not decide for the user to change LESS's default.
More specifically, the S flag harms users who review untrusted code
within a pager, since a patch looking like:
-old code;
+new good code; [... lots of tabs ...] malicious code;
would appear identical to:
-old code;
+new good code;
Users who prefer the old behavior can still set the $LESS environment
variable to -FRSX explicitly, or set core.pager to 'less -S'.
The documentation in config.txt is made a bit longer to keep both an
example setting the 'S' flag (needed to recover the old behavior)
and an example showing how to unset a flag set by Git.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
