When matching source and destination refs, we were failing
to pull the 'force' parameter from wildcard refspecs (but
not explicit ones) and attach it to the ref struct.
This adds a test for explicit and wildcard refspecs; the
latter fails without this patch.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In 89d750bf6fa025edeb31ad258cdd09a27a5c02fa I got a little too
aggressive with changing "git diff" to "git diff-tree". This is
shown to the user, who expects to see a full diff on their console,
and will want to see the output of their custom diff drivers (if
any) as the whole point of this call site is to show the diff to
the end-user.
Noticed by Johannes Sixt <j.sixt@viscovery.net>.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-stash needs to restrict itself to plumbing when running automated
diffs as part of its operation as the user may have configured a
custom diff driver that opens an interactive UI for certain/all
files. Doing that during scripted actions is very unfriendly to
the end-user and may cause git-stash to fail to work.
Reported by Johannes Sixt
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git may segfault if gitattributes contains an invalid
entry. A test is added to t0020 that triggers the segfault.
The parsing code is fixed to avoid the crash.
Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Define NI_MAXSERV if not defined by operating system
I found I needed NI_MAXSERV as it is defined in netdb.h, which is
not included by daemon.c. Rather than including the whole header
we can define a reasonable fallback value.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Avoid scary errors about tagged trees/blobs during git-fetch
Ok, what is going on is:
- append_fetch_head() looks up the SHA1 for all heads (including tags):
if (get_sha1(head, sha1))
return error("Not a valid object name: %s", head);
- it then wants to check if it's a candidate for merging (because
fetching also does the whole "list which heads to merge" in case
it is going to be part of a "pull"):
commit = lookup_commit_reference(sha1);
if (!commit)
not_for_merge = 1;
- and that "lookup_commit_reference()" is just very vocal about the
case where it fails. It really shouldn't be, and it shouldn't
affect the actual end result, but that basically explains why
you get that scary warning.
In short, the warning is just bogus, and should be harmless, but
I agree that it's ugly. I think the appended patch should fix it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-blame shouldn't crash if run in an unmerged tree
If we are in the middle of resolving a merge conflict there may be
one or more files whose entries in the index represent an unmerged
state (index entries in the higher-order stages).
Attempting to run git-blame on any file in such a working directory
resulted in "fatal: internal error: ce_mode is 0" as we use the magic
marker for an unmerged entry is 0 (set up by things like diff-lib.c's
do_diff_cache() and builtin-read-tree.c's read_tree_unmerged())
and the ce_match_stat_basic() function gets upset about this.
I'm not entirely sure that the whole "ce_mode = 0" case is a good
idea to begin with, and maybe the right thing to do is to remove
that horrid freakish special case, but removing the internal error
seems to be the simplest fix for now.
Linus
[sp: Thanks to Björn Steinbrink for the test case]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
fixing output of non-fast-forward output of post-receive-email
post-receive-email has one place where the variable fast_forward is not
spelled correctly. At the same place the logic was reversed. The
combination of both bugs made the script work correctly for fast-forward
commits but not for non-fast-forward ones. This change fixes this to
be correct in both cases.
Signed-off-by: Robert Schiele <rschiele@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The man page for filter-branch still talked about writing the result
to the branch "newbranch". This is hopefully the last place where the
old behaviour was described.
Noticed by Bill Lear.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Fix setup_git_directory_gently() with relative GIT_DIR & GIT_WORK_TREE
There are a few programs, such as config and diff, which allow running
without a git repository. Therefore, they have to call
setup_git_directory_gently().
However, when GIT_DIR and GIT_WORK_TREE were set, and the current
directory was a subdirectory of the work tree,
setup_git_directory_gently() would return a bogus NULL prefix.
This patch fixes that.
Noticed by REPLeffect on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When diff drivers are installed, calling "git diff <tree1>..<tree2>"
calls those drivers. This borks the patch generation of rebase -i.
So use "git diff-tree -p" instead, which does not call diff drivers.
Noticed by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Before this patch the clean target has removed the
configure script that comes with Git tar file.
That made compiling Git for different architectures
inconvenient.
This patch excludes configure from the files to be
deleted by 'make clean' and adds new target 'distclean'
to preserve old functionality.
Signed-off-by: Mathias Megyei <mathias@mnet-mail.de> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-config: handle --file option with relative pathname properly
When calling git-config not from the top level directory of a repository,
it changes directory before trying to open the config file specified
through the --file option, which then fails if the config file was
specified by a relative pathname. This patch adjusts the pathname to
the config file if applicable.
The problem was noticed by Joey Hess, reported through
http://bugs.debian.org/445208
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Before this patch, clear_commit_marks() recursed for each parent. This
could be potentially very expensive in terms of stack space. Probably
the only reason that this did not lead to problems is the fact that we
typically call clear_commit_marks() after marking a relatively small set
of commits.
Use (sort of) a tail recursion instead: first recurse on the parents
other than the first one, and then continue the loop with the first
parent.
Noticed by Shawn Pearce.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git add -i: Fix parsing of abbreviated hunk headers
The unified diff format allows one-line ranges to be abbreviated
by omiting the size. The hunk header "@@ -10,1 +10,1 @@" can be
expressed as "@@ -10 +10 @@", but this wasn't properly parsed in
all cases.
Such abbreviated hunk headers are generated when a one-line change
(add, remove or modify) appears without context; for example
because the file is a one-liner itself or because GIT_DIFF_OPTS
was set to '-u0'. If the user then runs 'git add -i' and enters
the 'patch' command for that file, perl complains about undefined
variables.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-config: don't silently ignore options after --list
Error out if someone gives options after --list since that is
not a valid syntax.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
This fixes an unnecessary empty line that we add to the log message when
we generate diffs, but don't actually end up printing any due to having
DIFF_FORMAT_NO_OUTPUT set.
This can happen with pickaxe or with rename following. The reason is that
we normally add an empty line between the commit and the diff, but we do
that even for the case where we've then suppressed the actual printing of
the diff.
This also updates a couple of tests that assumed the extraneous empty
line would exist at the end of output.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It turns out that I completely broke "git log --follow" with my recent
patch to revision.c ("Fix revision log diff setup, avoid unnecessary diff
generation", commit b7bb760d5ed4881422673d32f869d140221d3564).
Why? Because --follow obviously requires the diff machinery to function,
exactly the same way pickaxe does.
So everybody is away right now, but considering that nobody even noticed
this bug, I don't think it matters. But for the record, here's the trivial
one-liner fix (well, two, since I also fixed the comment).
Because of the nature of the bug, if you ask for patches when following
(which is one of the things I normally do), the bug is hidden, because
then the request for diff output will automatically also enable the diffs
themselves.
So while "git log --follow <filename>" didn't work, adding a "-p"
magically made it work again even without this fix.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This tests basic functionality and also exercises a bug noticed
by Keith Packard, (prune_cache followed by add_index_entry can
trigger an attempt to realloc a pointer into the middle of an
allocated buffer).
Must not modify the_index.cache as it may be passed to realloc at some point.
The index cache is not static, growing as new entries are added. If
entries are added after prune_cache is called, cache will no longer
point at the base of the allocation, and realloc will not be happy.
I verified that this was the only place in the current source which
modified any index_state.cache elements aside from the alloc/realloc
calls in read-cache by changing the type of the element to 'struct
cache_entry ** const cache' and recompiling.
A more efficient patch would create a separate 'cache_base' value to
track the allocation and then fix things up when reallocation was
necessary, instead of the brute-force memmove used here.
We find rename candidates by computing a fingerprint hash of
each file, and then comparing those fingerprints. There are
inherently O(n^2) comparisons, so it pays in CPU time to
hoist the (rather expensive) computation of the fingerprint
out of that loop (or to cache it once we have computed it once).
Previously, we didn't keep the filespec information around
because then we had the potential to consume a great deal of
memory. However, instead of keeping all of the filespec
data, we can instead just keep the fingerprint.
This patch implements and uses diff_free_filespec_data_large
to accomplish that goal. We also have to change
estimate_similarity not to needlessly repopulate the
filespec data when we already have the hash.
Practical tests showed 4.5x speedup for a 10% memory usage
increase.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The string value of %(numparent) was not returned correctly.
Also %(parent) misbehaved for the root commits (returned garbage)
and merge commits (returned first parent, followed by a space).
We rely on TMP_INDEX variable to decide if we are doing a partial commit,
as it is only set in the partial commit codepath. But the variable is
never initialized. A stray environment variable from outside could
ruin the day.
post-receive-hook: Remove the From field from the generated email header so that the pusher's name is used
Using the name of the committer of the revision at the tip of the
updated ref is not sensible. That information is available in the email
itself should it be wanted, and by supplying a "From", we were
effectively hiding the person who performed the push - which is useful
information in itself.
Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase -i: squash should retain the authorship of the _first_ commit
It was determined on the mailing list, that it makes more sense for a
"squash" to keep the author of the first commit as the author for the
result of the squash.
Make it so.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-add--interactive: Improve behavior on bogus input
1) Previously, any menu would cause a perl error when entered '0',
which is never a valid option.
2) Entering a bogus choice (like 998 or 4-2) surprisingly caused
the same behavior as if the user had just hit 'enter', which
means to carry out the selected action on the selected items.
Entering such bogus input is now a no-op and the sub-menu
doesn't exit.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Hitting Ctrl-D (EOF) is a common way to exit shell-like tools.
When in a sub-menu it will still behave as if an empty line had
been entered, carrying out the action on the selected items and
returning to the previous menu.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to incorrectly start calculating diffs whenever any argument but
'-z' was recognized by the diff options parsing. That was bogus, since not
all arguments result in diffs being needed, so we just waste a lot of time
and effort on calculating diffs that don't matter.
This actually also fixes another bug in "git log". Try this:
git log -C
and notice how it prints an extra empty line in between log entries, even
though it never prints the actual diff (because we didn't ask for any diff
format, so the diff machinery never prints anything).
With this patch, that bogus empty line is gone, because "revs->diff" is
never set. So this isn't just a "wasted time and effort" issue, it's also
a slight semantic fix.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'mergetool' of git://repo.or.cz/git/mergetool into maint
* 'mergetool' of git://repo.or.cz/git/mergetool:
mergetool: Fix typo in options passed to kdiff3
mergetool: fix emerge when running in a subdirectory
Mergetool generating blank files (1.5.3)
mergetool: fix emerge when running in a subdirectory
Only pass the basename of the output filename when to emerge, since
emerge interprets non-absolute pathnames relative to the containing
directory of the output buffer.
When mergetool is run from a subdirectory, "ls-files -u" nicely
limits the output to conflicted files in that directory, but
we need to give the full path to cat-file plumbing to grab the
contents of stages.
Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
apply: get rid of --index-info in favor of --build-fake-ancestor
git-am used "git apply -z --index-info" to find the original versions
of the files touched by the diff, to be able to do an inexpensive
three-way merge.
This operation makes only sense in a repository, since the index
information in the diff refers to blobs, which have to be present in
the current repository.
Therefore, teach "git apply" a mode to write out the result as an
index file to begin with, obviating the need for scripts to do it
themselves.
The sole user for --index-info is "git am" is converted to
use --build-fake-ancestor in this patch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tinyurl is incorrect -- it attempts to go to groups.osdl.org,
which is gone. Either use the full URL (in patch) or create a new
tinyurl for this URL.
Is the web page (where I first saw this problem) generated from
this txt file?
http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html
If not, it needs to be updated also.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitattributes.txt: Be more to the point in the filter driver description.
The description was meant to emphasizes that the project should remain
usable even if the filter driver was not used. This makes it more explicit
and removes the "here is rope to hang yourself" paraphrase.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
user-manual: Explain what submodules are good for.
Rework the introduction to the Submodules section to explain why
someone would use them, and fix up submodule references from the
tree-object and todo sections.
Signed-off-by: Michael Smith <msmith@cbnco.com> Acked-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this, the value passed to sendmail would have an extra set of
single quotes. At least exim's sendmail emulation would object to that:
exim: bad -f address "'list-addr@example.org'": malformed address: ' \
may not follow 'list-addr@example.org
error: hooks/post-receive exited with error code 1
Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 'commitdiff' view, for the merge commit, there is an extra header
for the difftree table, with links to commitdiffs to individual
parents. Do not show such header when there is nothing to show, for
trivial merges.
This means that for trivial merge you have to go to 'commit' view
to get links to diffs to each parent.
gitweb: Remove parse_from_to_diffinfo code from git_patchset_body
In commit 90921740bd00029708370673fdc537522aa48e6f
"gitweb: Split git_patchset_body into separate subroutines"
a part of git_patchset_body code was separated into parse_from_to_diffinfo
subroutine. But instead of replacing the separated code by the call to
mentioned subroutine, the call to subroutine was placed before the separated
code. This patch removes parse_from_to_diffinfo code from git_patchset_body
subroutine.
git-svn: don't attempt to spawn pager if we don't want one
Even though config_pager() unset the $pager variable, we were
blindly calling exec() on it through run_pager().
Noticed-by: Chris Moore <christopher.ian.moore@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
A lot of shell scripts contained stuff starting with
while case "$#" in 0) break ;; esac
and similar. I consider breaking out of the condition instead of the
body od the loop ugly, and the implied "true" value of the
non-matching case is not really obvious to humans at first glance. It
happens not to be obvious to some BSD shells, either, but that's
because they are not POSIX-compliant. In most cases, this has been
replaced by a straight condition using "test". "case" has the
advantage of being faster than "test" on vintage shells where "test"
is not a builtin. Since none of them is likely to run the git
scripts, anyway, the added readability should be worth the change.
A few loops have had their termination condition expressed
differently.
Signed-off-by: David Kastrup <dak@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Michael Smith <msmith@cbnco.com> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
user-manual: don't assume refs are stored under .git/refs
The scripts taken from Tony Luck's howto assume all refs can be found
under .git/refs, but this is not necessarily true, especially since
git-gc runs git-pack-refs.
Also add a note warning of this in the chapter that introduces refs, and
fix the same incorrect assumption in one other spot.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Documentation/git-lost-found.txt: drop unnecessarily duplicated name.
I only did this back when I wanted to make sure git-log and gitk work
properly with non Occidental characters. There is really no reason to
keep it around.
The example provided with the update-hook-example does not work on
either bash 2.05b.0(1)-release nor 3.1.17(1)-release. The matcher did
not match the lines that it advertised to match, such as:
refs/heads/bw/ linus
refs/heads/tmp/* *
In POSIX 1003.2 regular expressions, the star (*), is not an wildcard
meaning "match everything", it matches 0 or more matches of the atom
preceding it.
So to match "refs/heads/bw/topic-branch", the matcher should be written
as "refs/heads/bw/.*" to match "refs/heads/bw/" and everything after it.
git-push: documentation and tests for pushing only branches
Commit 098e711e caused git-push to match only branches when
considering which refs to push. This patch updates the
documentation accordingly and adds a test for this behavior.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-commit: partial commit of paths only removed from the index
Because a partial commit is meant to be a way to ignore what are
staged in the index, "git rm --cached A && git commit A" should
just record what is in A on the filesystem. The previous patch
made the command sequence to barf, saying that A has not been
added yet. This fixes it.
When making a partial commit, git-commit uses git-ls-files with
the --error-unmatch option to expand and sanity check the user
supplied path patterns. When any path pattern does not match
with the paths known to the index, it errors out, in order to
catch a common mistake to say "git commit Makefiel cache.h"
and end up with a commit that touches only cache.h (notice the
misspelled "Makefile"). This detection however does not work
well when the path has already been removed from the index.
If you drop a path from the index and try to commit that
partially, i.e.
the command complains because git does not know anything about
COPYING anymore.
This introduces a new option --with-tree to git-ls-files and
uses it in git-commit when we build a temporary index to
write a tree object for the partial commit.
When --with-tree=<tree-ish> option is specified, names from the
given tree are added to the set of names the index knows about,
so we can treat COPYING file in the example as known.
Of course, there is no reason to use "git rm" and git-aware
people have long time done:
Merge branch 'maint' of git://repo.or.cz/git-gui into maint
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Disable native platform text selection in "lists"
git-gui: Paper bag fix "Commit->Revert" format arguments
git-gui: Provide 'uninstall' Makefile target to undo an installation
git-gui: Font chooser to handle a large number of font families
git-gui: Make backporting changes from i18n version easier
git-gui: Don't delete send on Windows as it doesn't exist
git-gui: Trim trailing slashes from untracked submodule names
git-gui: Assume untracked directories are Git submodules
git-gui: handle "deleted symlink" diff marker
git-gui: show unstaged symlinks in diff viewer
git-gui: Avoid use of libdir in Makefile
git-gui: Disable Tk send in all git-gui sessions
git-gui: lib/index.tcl: handle files with % in the filename properly
git-gui: Properly set the state of "Stage/Unstage Hunk" action
git-gui: Fix detaching current branch during checkout
git-gui: Correct starting of git-remote to handle -w option
send-email: make message-id generation a bit more robust
Earlier code took Unix time and appended a few random digits.
If you are firing off many messages within a second, you could
issue the same id to different messages, which is a no-no. If
you send out 31 messages within a single second, with random
integer taken out of rand(4200), you have about 10% chance of
producing the same message ID.
This fixes the problem by uses a prefix string which is
constant-per-invocation (time and pid), with a serial number for
each message generated by the process appended at the end.
git-gui: Disable native platform text selection in "lists"
Sometimes we use a Tk text widget as though it were a listbox.
This happens typically when we want to show an icon to the left
of the text label or just when a text widget is generally a better
choice then the native listbox widget.
In these cases if we want the user to have control over the selection
we implement our own "in_sel" tag that shows the selected region
and we perform our own selection management in the background
via keybindings and mouse bindings. In such uses we don't want
the user to be able to activate the native platform selection by
dragging their mouse through the text widget. Doing so creates a
very confusing display and the user is left wondering what it may
mean to have two different types of selection in the same widget.
Tk doesn't allow us to delete the "sel" tag that it uses internally
to manage the native selection but it will allow us to make it
invisible by setting the tag to have the same display properties
as unselected text. So long as we don't actually use the "sel"
tag for anything in code its effectively invisible.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>