Unfortunately, I introduced a bug in commit 7f705dc36 (git-p4: Fix bug in
p4Where method). This happens because sometimes the result from
"p4 where <somepath>" doesn't contain a "depotFile" key, but instead a
"data" key that needs further parsing. This commit should ensure that both
of these cases are checked.
Signed-off-by: Tor Arvid Lund <torarvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Starting with asciidoc 8.3.0 linkgit macro is no longer recognized by
asciidoc and user guide suggests
(http://www.methods.co.nz/asciidoc/userguide.html#_macro_definitions)
that macros are supposed to be defined in [macros] section. I'm not
sure whether undefined linkgit macro was working by pure chance or it
is a regression in asciidoc 8.3.0, but this patch adds proper
definition for the linkgit macro, allowing it to work on 8.3.0.
Signed-off-by: Alexey Borzenkov <snaury@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In insert_file() subroutine (which is used to insert HTML fragments as
custom header, footer, hometext (for projects list view), and per
project README.html (for summary view)) we used:
map(to_utf8, <$fd>);
This doesn't work, and other form has to be used:
map { to_utf8($_) } <$fd>;
Now with test for t9600 added, for $GIT_DIR/README.html.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff: allow turning on textconv explicitly for plumbing
Some history viewers use the diff plumbing to generate diffs
rather than going through the "git diff" porcelain.
Currently, there is no way for them to specify that they
would like to see the text-converted version of the diff.
This patch adds a "--textconv" option to allow such a
plumbing user to allow text conversion. The user can then
tell the viewer whether or not they would like text
conversion enabled.
While it may be tempting add a configuration option rather
than requiring each plumbing user to be configured to pass
--textconv, that is somewhat dangerous. Text-converted diffs
generally cannot be applied directly, so each plumbing user
should "opt in" to generating such a diff, either by
explicit request of the user or by confirming that their
output will not be fed to patch.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We'll go ahead and move the callsite in wt-status, also;
even though the user can't pass any options here, it is a
cleanup that will help avoid any surprise later if the
setup_revisions line is changed.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
GIT 1.6.0.5
"git diff <tree>{3,}": do not reverse order of arguments
tag: delete TAG_EDITMSG only on successful tag
gitweb: Make project specific override for 'grep' feature work
http.c: use 'git_config_string' to get 'curl_http_proxy'
fetch-pack: Avoid memcpy() with src==dst
"git diff <tree>{3,}": do not reverse order of arguments
According to the message of commit 0fe7c1de16f71312e6adac4b85bddf0d62a47168,
"git diff" with three or more trees expects the merged tree first followed by
the parents, in order. However, this command reversed the order of its
arguments, resulting in confusing diffs. A comment /* Again, the revs are all
reverse */ suggested there was a reason for this, but I can't figure out the
reason, so I removed the reversal of the arguments. Test case included.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The user may put some effort into writing an annotated tag
message. When the tagging process later fails (which can
happen fairly easily, since it may be dependent on gpg being
correctly configured and used), there is no record left on
disk of the tag message.
Instead, let's keep the TAG_EDITMSG file around until we are
sure the tag has been created successfully. If we die
because of an error, the user can recover their text from
that file. Leaving the file in place causes no conflicts;
it will be silently overwritten by the next annotated tag
creation.
This matches the behavior of COMMIT_EDITMSG, which stays
around in case of error.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
memcpy() may only be used for disjoint memory areas, but when invoked
from cmd_fetch_pack(), we have my_args == &args. (The argument cannot
be removed entirely because transport.c invokes with its own
variable.)
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/am-options:
git-am: rename apply_opt_extra file to apply-opt
Test that git-am does not lose -C/-p/--whitespace options
git-am: propagate --3way options as well
git-am: propagate -C<n>, -p<n> options as well
git-am --whitespace: do not lose the command line option
Test that git-am does not lose -C/-p/--whitespace options
These tests make sure that "git am" does not lose command line options
specified when it was started, after it is interrupted by a patch that
does not apply earlier in the series.
These options are meant to deal with patches that do not apply cleanly
due to the differences between the version the patch was based on and
the version "git am" is working on.
Because a series of patches applied in the same "git am" run tends to
come from the same source, it is more useful to propagate these options
after the application stops.
git-am --whitespace: do not lose the command line option
When you start "git am --whitespace=fix" and the patch application process
is interrupted by an unapplicable patch early in the series, after
fixing the offending patch, the remainder of the patch should be processed
still with --whitespace=fix when restarted with "git am --resolved" (or
dropping the offending patch with "git am --skip").
The breakage was introduced by the commit 67dad68 (add -C[NUM] to git-am,
2007-02-08); this should fix it.
This depends on the users Client view. The current p4Where method will now
return /home/user/p4root/SomePath/UndesiredSubdir/... which is not what we
want. This patch loops through the results from "p4 where", and picks the one
where the depotFile exactly matches the given depotPath (//depot/SomePath/...
in this example).
Signed-off-by: Tor Arvid Lund <torarvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'branch' subcommand incorrectly had the svn-remote to use hardcoded
as 'svn', the default remote name. This meant that branches derived
from other svn-remotes would try to use the branch and tag configuration
for the 'svn' remote, potentially copying would-be branches to the wrong
place in SVN, into the branch namespace for another project.
Fix this by using the remote name extracted from the svn info for the
specified git ref. Add a testcase for this behaviour.
[jc: squashed in a fix to test from Michael J Gruber for older svn (1.4)]
Signed-off-by: Deskin Miller <deskinm@umich.edu> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/rm-i-t-a:
git add --intent-to-add: do not let an empty blob be committed by accident
git add --intent-to-add: fix removal of cached emptiness
builtin-rm.c: explain and clarify the "local change" logic
Extend index to save more flags
Earlier the plan was to eventually eradicate git-foo executables from the
filesystem for all the built-in commands, but when we released 1.6.0 we
decided not to do so. Instead, it has been promised that by prepending
the output from $(git --exec-path) to your $PATH, you can keep using the
dashed form of commands.
This also allows "git stage" to appear in the autogenerated command list,
which is used to offer man pages by "git help" command.
In a corner case of large files whose lines do not match uniquely, the
loop to eliminate a line that matches multiple locations adjacent to a run
of lines that do not uniquely match wasted too much cycles. Fix this by
giving up early after scanning 100 lines in both direction.
* bc/maint-keep-pack:
repack: only unpack-unreachable if we are deleting redundant packs
t7700: test that 'repack -a' packs alternate packed objects
pack-objects: extend --local to mean ignore non-local loose objects too
sha1_file.c: split has_loose_object() into local and non-local counterparts
t7700: demonstrate mishandling of loose objects in an alternate ODB
builtin-gc.c: use new pack_keep bitfield to detect .keep file existence
repack: do not fall back to incremental repacking with [-a|-A]
repack: don't repack local objects in packs with .keep file
pack-objects: new option --honor-pack-keep
packed_git: convert pack_local flag into a bitfield and add pack_keep
t7700: demonstrate mishandling of objects in packs with a .keep file
gitweb: Fix handling of non-ASCII characters in inserted HTML files
Use new insert_file() subroutine to insert HTML chunks from external
files: $site_header, $home_text (by default indextext.html),
$site_footer, and $projectroot/$project/REAME.html.
All non-ASCII chars of those files will be broken by Perl IO layer
without decoding to utf8, so insert_file() does to_utf8() on each
printed line; alternate solution would be to open those files with
"binmode $fh, ':utf8'", or even all files with "use open qw(:std :utf8)".
Note that inserting README.html lost one of checks for simplicity.
Noticed-by: Tatsuki Sugiura <sugi@nemui.org> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a built-in alias for 'stage' to the 'add' command
This comes from conversation at the GitTogether where we thought it would
be helpful to be able to teach people to 'stage' files because it tends
to cause confusion when told that they have to keep 'add'ing them.
This continues the movement to start referring to the index as a
staging area (eg: the --staged alias to 'git diff'). Also adds a
doc file for 'git stage' that basically points to the docs for
'git add'.
Signed-off-by: Scott Chacon <schacon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add backslash to list of 'crud' characters in real name
We remove crud characters at the beginning and end of real-names so that
when we see email addresses like
From: "David S. Miller" <davem@davemloft.net>
we drop the quotes around the name when we parse that and split it up into
name and email.
However, the list of crud characters was basically just a random list of
common things that are found around names, and it didn't contain the
backslash character that some insane scripts seem to use when quoting
things. So now the kernel has a number of authors listed like
Author: \"Rafael J. Wysocki\ <rjw@sisk.pl>
because the author name had started out as
From: \"Rafael J. Wysocki\" <rjw@sisk.pl>
and the only "crud" character we noticed and removed was the final
double-quote at the end.
We should probably do better quote removal from names anyway, but this is
the minimal obvious patch.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This introduces make variable NO_PTHREADS for platforms that lack the
support for pthreads library or people who do not want to use it for
whatever reason. When defined, it makes the multi-threaded index
preloading into a no-op, and also disables threaded delta searching by
pack-objects.
Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Mike Ralphson <mike@abacus.co.uk> Tested-by: Johannes Sixt <j6t@kdbg.org> (AIX 4.3.x) Signed-off-by: Junio C Hamano <gitster@pobox.com>
bisect: fix "git bisect skip <commit>" and add tests cases
The patch that allows "git bisect skip" to be passed a range of
commits using the "<commit1>..<commit2>" notation is flawed because
it introduces a regression when it was passed a simple rev or commit.
"git bisect skip <commit>" doesn't work any more, because <commit>
is quoted but not properly unquoted.
This patch fixes that and add tests cases to better check when it is
passed commits and range of commits.
While at it, this patch also properly quotes the non range arguments
using the "sq" function.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
This is taken from a patch from Giuseppe but unfortunately it came
too late to replace the series that was already on "next". The comment
he updated here is better than the version we had previously, so I am
cherry-picking this bit not to lose it.
* gb/gitweb-feature:
gitweb: make gitweb_check_feature a boolean wrapper
gitweb: rename gitweb_check_feature to gitweb_get_feature
gitweb: fix 'ctags' feature check and others
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Add a menu option to start git gui
gitk: Make line origin search update the busy status
gitk: Update German translation
gitk: Fix bug in accessing undefined "notflag" variable
gitk: Highlight only when search type is "containing:".
gitk: Fix context menu items for generating diffs when in tree mode
git-gui: Teach start_push_anywhere_action{} to notice when remote is a mirror.
When the destination repository is a mirror, this function goofed by still
passing a refspec to git-push. Now it notices that the remote is a mirror
and holds the refspec.
Signed-off-by: Mark Burton <markb@ordern.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
gitk: Make line origin search update the busy status
Currently the 'show origin of this line' feature does not update the
status field of the gitk window, so it is not evident that any
processing is going on. It may seem at first that clicking the item
had no effect.
This commit adds calls to set and clear the busy status with an
appropriate title, similar to other search commands.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Fix bug in accessing undefined "notflag" variable
As pointed out by Johannes Sixt and Alexander Gavrilov, commit 2958228430b63f2e38c55519d1f98d8d6d9e23f3 ("gitk: Fix switch statement
in parseviewargs") exposed a latent bug in that $notflag was never
initialized. Since it isn't used either, this removes it entirely.
gitk: Highlight only when search type is "containing:".
When the search type is "touching paths" or "adding/removing string",
it's not very useful to highlight instances of the search string in
the commit message, headline or author name, so this disables the
highlighting in those cases.
This was suggested by Mark Burton <markb@ordern.com>, but the
implementation is different to his patch, which tested $gdttype at
each place where $markingmatches was tested.
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Avoid handling the Return key twice in Add Branch
gitk: Show local changes properly when we have a path limit
gitk: Fix switch statement in parseviewargs
gitk: Index line[hnd]tag arrays by id rather than row number
send-email: do not reverse the command line arguments
The loop picks elements from @ARGV one by one, sifts them into arguments
meant for format-patch and the script itself, and pushes them to @files
and @rev_list_opts arrays. Pick elements from @ARGV starting at the
beginning using shift, instead of at the end using pop, as push appends
them to the end of the array.
generate-cmdlist.sh: avoid selecting synopsis at wrong place
In "common" man pages there is luckily no "NAME" anywhere except at
beginning of documents. If there is another "NAME", sed could
mis-select it and lead to common-cmds.h corruption. So better nail it
at beginning of line, which would reduce corruption chance.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: make gitweb_check_feature a boolean wrapper
The gitweb_get_feature() function retrieves the configuration parameters
for the feature (such as the list of snapshot formats or the list of
additional actions), but it is very often used to see if feature is
enabled (which is returned as the first element in the list).
Because accepting the returned list in the scalar context by mistake
yields the number of elements in the array, which is non-zero in all
cases, such a mistake would result in a bug for the latter use, with
disabled features appearing enabled. All existing callers that call the
function for this purpose assign the return value in the list context to
retrieve the first element, but that is only because we fixed careless
callers recently.
This adds gitweb_check_feature() as a wrapper to gitweb_get_feature() that
can be called safely in the scalar context to see if a feature is enabled
to reduce the risk of future bugs. Callers of "get" that use the call
only to see if the feature is enabled are updated to call this wrapper.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: rename gitweb_check_feature to gitweb_get_feature
The function is about retrieving the configuration parameter list for the
feature. A more robust way to check if a feature is enabled will be
introduced in the next patch, and the function will be called
gitweb_check_feature.
gitweb_check_feature() function is to retrieve the configuration parameter
list and calling it in the scalar context does not give its first element
that tells if the feature is enabled. This fixes all the existing callers
to call the function correctly in the list context.
git add --intent-to-add: do not let an empty blob be committed by accident
Writing a tree out of an index with an "intent to add" entry is blocked.
This implies that you cannot "git commit" from such a state; however you
can still do "git commit -a" or "git commit $that_path".
git add --intent-to-add: fix removal of cached emptiness
This uses the extended index flag mechanism introduced earlier to mark
the entries added to the index via "git add -N" with CE_INTENT_TO_ADD.
The logic to detect an "intent to add" entry for the purpose of allowing
"git rm --cached $path" is tightened to check not just for a staged empty
blob, but with the CE_INTENT_TO_ADD bit. This protects an empty blob that
was explicitly added and then modified in the work tree from being dropped
with this sequence:
builtin-rm.c: explain and clarify the "local change" logic
Explain the logic to check local modification a bit more in the comment,
especially because the existing comment that talks about "git rm --cached"
was placed in a part that was not about "--cached" at all.
* rs/strbuf-expand:
remove the unused files interpolate.c and interpolate.h
daemon: deglobalize variable 'directory'
daemon: inline fill_in_extra_table_entries()
daemon: use strbuf_expand() instead of interpolate()
merge-recursive: use strbuf_expand() instead of interpolate()
add strbuf_expand_dict_cb(), a helper for simple cases
* mv/clone-strbuf:
builtin_clone: use strbuf in cmd_clone()
builtin-clone: use strbuf in clone_local() and copy_or_link_directory()
builtin-clone: use strbuf in guess_dir_name()
* ph/send-email:
git send-email: ask less questions when --compose is used.
git send-email: add --annotate option
git send-email: interpret unknown files as revision lists
git send-email: make the message file name more specific.
* maint:
sha1_file.c: resolve confusion EACCES vs EPERM
sha1_file: avoid bogus "file exists" error message
git checkout: don't warn about unborn branch if -f is already passed
bash: offer refs instead of filenames for 'git revert'
bash: remove dashed command leftovers
git-p4: fix keyword-expansion regex
fast-export: use an unsorted string list for extra_refs
Add new testcase to show fast-export does not always exports all tags
An earlier commit 916d081 (Nicer error messages in case saving an object
to db goes wrong, 2006-11-09) confused EACCES with EPERM, the latter of
which is an unlikely error from mkstemp().
This avoids the following misleading error message:
error: unable to create temporary sha1 filename ./objects/15: File exists
mkstemp can fail for many reasons, one of which, ENOENT, can occur if
the directory for the temp file doesn't exist. create_tmpfile tried to
handle this case by always trying to mkdir the directory, even if it
already existed. This caused errno to be clobbered, so one cannot tell
why mkstemp really failed, and it truncated the buffer to just the
directory name, resulting in the strange error message shown above.
Note that in both occasions that I've seen this failure, it has not been
due to a missing directory, or bad permissions, but some other, unknown
mkstemp failure mode that did not occur when I ran git again. This code
could perhaps be made more robust by retrying mkstemp, in case it was a
transient failure.
Signed-off-by: Joey Hess <joey@kitenet.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git checkout: don't warn about unborn branch if -f is already passed
I think it's unnecessary to warn that the checkout has been forced due to an
unborn current branch if -f has been explicitly passed. For one project, I am
using git-new-workdir to create workdirs from a bare repository whose HEAD is
set to an unborn branch, and this warning started to irritate me.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
bash: offer refs instead of filenames for 'git revert'
The completion script for 'git revert' currently offers options and
filenames. However, 'git revert' doesn't take any filenames from the
command line, but a single commit. Therefore, it's more sane to offer
refs instead.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sometimes it's handy to complete full refs, e.g. the user has some
refs outside of refs/{heads,remotes,tags} or the user wants to
complete some git command's special refs (like 'git show
refs/bisect/bad').
To do that, we check whether the ref to be completed starts with
'refs/' or is 'refs' (to reduce the risk of matching 'refs-'). If it
does, then we offer full refs for completion; otherwise everything
works as usual.
This way the impact on the common case is fairly small (hopefully not
many users have branches or tags starting with 'refs'), and in the
special case the cost of typing out 'refs' is bearable.
While at it, also remove the unused 'cmd' variable from '__git_refs'.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 5a625b07 (bash: remove fetch, push, pull dashed form leftovers,
2008-10-03) did that already, but there were still some git-cmd left
here and there.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>