git-svn: find-rev and rebase for SVN::Mirror repositories
find-rev and rebase error out on svm because git-svn doesn't trace the
original svn revision numbers back to git commits. The updated test
case, included in the patch, shows the issue and passes with the rest of
the patch applied.
This fixes Git::SVN::find_by_url to find branches based on the
svm:source URL, where useSvmProps is set. Also makes sure cmd_find_rev
and working_head_info use the information they have to correctly track
the source repository. This is enough to get find-rev and rebase
working.
Signed-off-by: João Abecasis <joao@abecasis.name> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The document says that a fetch with a configured remote stores what are
fetched in the remote tracking branches "Unlike the longhand form", but
there is no longhand form "fetch" demonstrated earlier.
This adds a missing demonstration of the longhand form, and a new
paragraph to explain why some people might want to fetch before pull.
bash completion: Resolve git show ref:path<tab> losing ref: portion
Linus reported that the bash completion for git show often dropped
the ref portion of the argument (stuff before the :) when trying
to complete a file name of a file in another branch or tag.
Björn Steinbrink tracked it down to the gvfs completion script
which comes standard on many Fedora Core based systems. That is
removing : from COMP_WORDBREAKS, making readline treat the entire
argument (including the ref) as the name that must be completed.
When the git completion routines supplied a completion of just the
filename, readline replaced everything.
Since Git users often need to use "ref:path" or "ref:ref" sort of
arguments, and expect completion support on both sides of the :
we really want the : in COMP_WORDBREAKS to provide a good user
experience. This is also the default that ships with bash as it
can be useful in other contexts, such as rcp/scp.
We now try to add : back to COMP_WORDBREAKS if it has been removed
by a script that loaded before us. However if this doesn't work
(as the : is stripped after we load) we fallback in the completion
routines to include "ref:" as part of the prefix for completions,
allowing readine to fully insert the argument the user wanted.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When detaching the HEAD to the base commit, the "git checkout" command
could fail if, for example, upstream contains a file that would overrwrite
a local, untracked file. Unconditionally discarding the standard error
stream was done to squelch the progress and notices back when checkout
did not have -q option, but there is no reason to keep doing it anymore.
Because we do not try computing merge base with itself for obvious
reasons, the code was not prepared for an arguably insane case of
the caller feeding the same commit twice to it.
Noticed and test written by Sverre Hvammen Johansen
bash completion: Append space after file names have been completed
When completing `git show origin/maint:Makef<tab>` we should add a
space after the filename has been completed, so that the user can
immediately begin the next argument.
I also added a special case for the symlink variant so we treat it
just like a normal blob, as there are no items below it in the Git
tree structure.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sp/maint-bash-completion-optim:
bash completion: Don't offer "a.." as a completion for "a."
bash completion: Improve responsiveness of git-log completion
bash completion: Don't offer "a.." as a completion for "a."
If the user is trying to complete "v1.5.3.<tab>" to see all of
the available maintenance releases for 1.5.3 we should not give
them an extra dot as the completion. Instead if the user wants
a ".." or a "..." operator they should key the two dots out on
their own. Its the same number of keystrokes either way.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
GIT 1.5.6.3
git-am: Do not exit silently if committer is unset
t0004: fix timing bug
git-mailinfo: document the -n option
Fix backwards-incompatible handling of core.sharedRepository
* ph/parseopt-step-blame:
revisions: refactor handle_revision_opt into parse_revision_opt.
git-shortlog: migrate to parse-options partially.
git-blame: fix lapsus
git-blame: migrate to incremental parse-option [2/2]
git-blame: migrate to incremental parse-option [1/2]
revisions: split handle_revision_opt() from setup_revisions()
parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
parse-opt: fake short strings for callers to believe in.
parse-opt: do not print errors on unknown options, return -2 intead.
parse-opt: create parse_options_step.
parse-opt: Export a non NORETURN usage dumper.
parse-opt: have parse_options_{start,end}.
git-blame --reverse
builtin-blame.c: allow more than 16 parents
builtin-blame.c: move prepare_final() into a separate function.
rev-list --children
revision traversal: --children option
* jc/report-tracking:
branch -r -v: do not spit out garbage
stat_tracking_info(): clear object flags used during counting
git-branch -v: show the remote tracking statistics
git-status: show the remote tracking statistics
Refactor "tracking statistics" code used by "git checkout"
git-gui: MERGE_RR lives in .git/ directly with newer Git versions
Now that MERGE_RR was moved out of .git/rr-cache/, we have to delete
it somewhere else. Just in case somebody wants to use a newer git-gui
with an older Git, the file .git/rr-cache/MERGE_RR is removed, too (if
it exists).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
help (Windows): Display HTML in default browser using Windows' shell API
The system's default browser for displaying HTML help pages is now used
directly on Windows, instead of launching git-web--browser, which
requires a Unix shell. Avoiding MSYS' bash when possible is good
because it avoids potential path translation issues. In this case it is
not too hard to avoid launching a shell, so let's avoid it.
The Windows-specific code is implemented in compat/mingw.c to avoid
platform-specific code in the main code base. On Windows, open_html is
provided as a define. If open_html is not defined, git-web--browse is
used. This approach avoids platform-specific ifdefs by using
per-function ifdefs. The "ifndef open_html" together with the
introductory comment should sufficiently warn developers, so that they
hopefully will not break this mechanism.
Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
help.c: Add support for htmldir relative to git_exec_path()
If htmldir (in the Makefile) is a relative path, this path will now be
interpreted relative to git_exec_path. This can be used to create an
installation that can be moved to a different directory without
re-compiling. The Windows installer (msysgit) is an example for such
a setup.
Note that the Makefile maps htmldir to the define GIT_HTML_PATH.
Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move code interpreting path relative to exec-dir to new function system_path()
Expanding system paths relative to git_exec_path can be used for
creating an installation that can be moved to a different directory
without re-compiling. We use this approach for template_dir and the
system wide gitconfig. The Windows installer (msysgit) is an example
for such a setup.
This commit moves common code to a new function system_path(). System
paths that are to be interpreted relative to git_exec_path are passed to
system_path() and the return value is used instead of the original path.
system_path() prefixes a relative path with git_exec_path and leaves
absolute paths unmodified. For example, we now write
Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you misuse a git command, you are shown the usage string.
But this is currently shown in the dashed form. So if you just
copy what you see, it will not work, when the dashed form
is no longer supported.
This patch makes git commands show the dash-less version.
For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
generates a dash-less usage string now.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When comparing two commit objects for equality, it is sufficient to
compare their in-core pointers because the object layer guarantees the
uniqueness. However, comparing pointers to two "struct commit_list"
instances that point at the same commit does not make any sense.
Spotted by Sverre Hvammen Johansen who wrote an additional test to expose
the problem, fixed by Miklos Vajna.
Parent commits are usually older than their children. Thus,
on each iteration of the loop in rewrite_one, add_parents_to_list
traverses all commits previously processed by the loop.
It performs very poorly in case of very long rewrite chains.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/test-lib.sh: exit with small negagive int is ok with test_must_fail
The test_must_fail function in test-lib.sh has been designed to
distinguish segmentation faults from controlled errors. But in the
current implementation this only works if a git command does not return a
small negative value, like -1, -2 or -3. But some git commands do.
Because any signal (like SIGSEGV) will result in an exit status
less than 193, this patch just adds a further check for the exit
status.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
bash completion: Improve responsiveness of git-log completion
Junio noticed the bash completion has been taking a long time lately.
Petr Baudis tracked it down to 72e5e989b ("bash: Add space after
unique command name is completed."). Tracing the code showed
we spent significant time inside of this loop within __gitcomp,
due to the string copying overhead.
Since __git_refs avoids this string copying by forking and using
echo we use the same trick here when we need to finish generating
the names for the caller.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you want to reuse the rerere cache in another repository, and set
a symbolic link to it, you do not want to have the two repositories
interfer with each other by accessing the _same_ MERGE_RR.
For example, if you use contrib/git-new-workdir to set up a second
working directory, and you have a conflict in one working directory,
but commit in the other working directory first, the wrong "resolution"
will be recorded.
The easy solution is to move MERGE_RR out of the rr-cache/ directory,
which also corresponds with the notion that rr-cache/ contains cached
resolutions, not some intermediate temporary states.
Noticed by Kalle Olavi Niemitalo.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test created an initial commit, made .git/objects unwritable and then
exercised various codepaths to create loose commit, tree and blob objects
to make sure the commands notice failures from these attempts.
However, the initial commit was not preceded with test_tick, which made
its object name depend on the timestamp. The names of all the later tree
and blob objects the test tried to create were static. If the initial
commit's object name happened to begin with the same two hexdigits as the
tree or blob objects the test later attempted to create, the fan-out
directory in which these tree or blob would be created is already created
when the initial commit was made, and the object creation succeeds, and
commands being tested should not notice any failure --- in short, the test
was bogus.
This makes the fan-out directories also unwritable, and adds test_tick
before the commit object creation to make the test repeatable.
The contents of the file to create a blob from "a" to "60" is to force the
name of the blob object to begin with "1b", which shares the fan-out
directory with the initial commit that is created with the test. This was
useful when diagnosing the breakage of this test.
Add pretty format %aN which gives the author name, respecting .mailmap
The pretty format %an does not respect .mailmap, but gives the exact
author name recorded in the commit. Sometimes it is more desirable,
however, to look if the email has another name mapped to it in .mailmap.
This commit adds %aN (and %cN for the committer name) to do exactly that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows, gpg outputs CR/LF signatures. But since the tag messages
are already stripped of the CR by stripspace(), it is arguably nicer
to do the same for the tag signature. Actually, this patch does not
look for CR/LF, but strips all CRs from the signature. It does so not
only on Windows but on all platforms to keep the code simpler.
[ spr: ported code to use strbuf ]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix backwards-incompatible handling of core.sharedRepository
06cbe85 (Make core.sharedRepository more generic, 2008-04-16) broke the
traditional setting of core.sharedRepository to true, which was to make
the repository group writable: with umask 022, it would clear the
permission bits for 'other'. (umask 002 did not exhibit this behaviour
since pre-chmod() check in adjust_shared_perm() fails in that case.)
The call to adjust_shared_perm() should only loosen the permission.
If the user has umask like 022 or 002 that allow others to read, the
resulting files should be made readable and writable by group, without
restricting the readability by others.
This patch fixes the adjust_shared_perm() mode tweak based on Junio's
suggestion and adds the appropriate tests to t/t1301-shared-repo.sh.
Cc: Heikki Orsila <heikki.orsila@iki.fi> Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch moves rerere()-related functions into a newly created
rerere.c file.
The setup_rerere() function is needed by both rerere() and cmd_rerere(),
so this function is moved to rerere.c and declared non-static (and "extern")
in newly created rerere.h file.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-rerere: more carefully find conflict markers
When a conflicting file contains a line that begin with "=======", rerere
failed to parse conflict markers. This result to a wrong preimage file and
an unexpected error for the user. The boundary between ours and theirs
not just begin with 7 equals, but is followed by either a SP or a LF.
This patch enforces parsing rules so that markers match in the right order,
and when ambiguous, the command does not autoresolve the conflicted file.
Especially because we are introducing rerere.autoupdate configuration
(which is off by default for safety) that automatically stages the
resolution made by rerere, it is necessary to make sure that we do not
autoresolve when there is any ambiguity.
Signed-off-by: Olivier Marin <dkr@freesurf.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
7ebd52a (Merge branch 'dz/apply-again', 2008-07-01) taught "git-apply" to
grok a (non-git) patch that is a concatenation of separate patches that
touch the same file number of times, by recording the postimage of patch
application of previous round and using it as the preimage for later
rounds.
This "incremental" mode of patch application fundamentally contradicts
with the way git rename/copy patches are designed. When a git patch talks
about a file A getting modified, and a new file B created out of A, like
this:
diff --git a/A b/A
--- a/A
+++ b/A
... change text here ...
diff --git a/A b/B
copy from A
copy to B
--- a/A
+++ b/B
... change text here ...
the second change to produce B does not depend on what is done to A with
the first change in any way. This is explicitly done so for reviewability
of individual patches.
With this commit, we do not look at 'fn_table' that records the postimage
of previous round when applying a patch to produce a new file out of an
existing file.
* js/apply-root:
git-apply --directory: make --root more similar to GNU diff
apply --root: thinkofix.
Teach "git apply" to prepend a prefix with "--root=<root>"
git-send-email: Fix authenticating on some servers when using TLS.
Send HELO again after a successful STARTTLS command to refresh the list of
extensions. These may be different to what is returned over a clear
connection (for example the AUTH command may be accepted over a secure
connection, but not over a clear connection).
Furthermore, this behaviour is recommended by RFC 2487
(http://www.ietf.org/rfc/rfc2487.txt).
Signed-off-by: Robert Shearman <robertshearman@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t9113-*.sh: provide user feedback when test skipped
Currently this test simply exits without providing any
feedback at all. Tell user if the test is being skipped
and provide a hint as to how the test may be enabled.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Correct pack memory leak causing git gc to try to exceed ulimit
When recursing to unpack a delta base we must unuse_pack() so that
the pack window for the current object does not remain pinned in
memory while the delta base is itself being unpacked and materialized
for our use.
On a long delta chain of 50 objects we may need to access 6 different
windows from a very large (>3G) pack file in order to obtain all
of the delta base content. If the process ulimit permits us to
map/allocate only 1.5G we must release windows during this recursion
to ensure we stay within the ulimit and transition memory from pack
cache to standard malloc, or other mmap needs.
Inserting an unuse_pack() call prior to the recursion allows us to
avoid pinning the current window, making it available for garbage
collection if memory runs low.
This has been broken since at least before 1.5.1-rc1, and very
likely earlier than that. Its fixed now. :)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git-branch --merged" is a handy way to list all the branches that have
already been merged to the current branch, but it did not allow checking
against anything but the current branch. Having to switch branches only
to list the branches that are merged with another branch made the feature
practically useless.
This updates the option parser so that "git branch --merged next" is
accepted when you are on 'master' branch.
We used to require the name of the commit to limit the branches shown to
the --contains option, but more recent --merged/--no-meregd defaults to
HEAD (and they do not allow arbitrary commit, which is a separate issue).
This teaches --contains to default to HEAD when no parameter is given.
* maint:
Start preparing release notes for 1.5.6.3
git-submodule - Fix bugs in adding an existing repo as a module
bash: offer only paths after '--'
Remove unnecessary pack-*.keep file after successful git-clone
make deleting a missing ref more quiet
Documentation: update sections on naming revisions and revision ranges
Various *_HEAD pseudo refs were not documented in any central place.
Especially since we may be teaching rebase and am to record ORIG_HEAD,
it would be a good time to do so.
While at it, reword the explanation on r1..r2 notation to reduce
confusion.
The mention of 1997 was correct when it was made, and it still is true
to some extent (http://savannah.gnu.org/forum/forum.php?forum_id=5189
says it has not been actively maintained for quite some time). However,
because its name changed not to conflict with us, it is no longer
relevant whether many users use gnuit or have moved away to graphical
file managers.
The only people possibly affected are people who have older version of
gnuit installed as "git".
git http-push doesn't handle packed-refs, and now the new builtin-clone
created packed refs, the http-push test fails.
Mark the current failure as such, and also catch third test's failure
that went unreported because git push doesn't return an error code when
it says:
No refs in common and none specified; doing nothing.
Which it does when http-push can't get a list of refs recursively from
$URL/refs/.
Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch also converts the good ole' git-remote.perl to use it.
It is otherwise used in the repo.or.cz machinery and I guess other
scripts might find it useful too.
Unfortunately,
git-ls-remote --heads .
is subtly different from
git-ls-remote . refs/heads/
(since the second matches anywhere in the string, not just at the
beginning) so we have to provide interface for both.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
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>
revisions: split handle_revision_opt() from setup_revisions()
Add two fields to struct rev_info:
- .def to store --default argument; and
- .show_merge 1-bit field.
handle_revision_opt() is able to deal with any revision option, and
consumes them, and leaves revision arguments or pseudo arguments
(like --all, --not, ...) in place.
For now setup_revisions() does a pass of handle_revision_opt() again
so that code not using it in a parse-opt parser still work the same.
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'jc/blame' (early part):
git-blame --reverse
builtin-blame.c: allow more than 16 parents
builtin-blame.c: move prepare_final() into a separate function.
rev-list --children
revision traversal: --children option
Remove unnecessary pack-*.keep file after successful git-clone
Once a clone is successful we no longer need to hold onto the
.keep file created by the transport. Delete the file so we
can later repack the complete repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: tweak use case in "git stash save --keep-index"
The documentation suggests using "git stash apply" in the
--keep-index workflow even though doing so will lead to clutter
in the stash. And given that the changes are about to be
committed anyway "git stash pop" is more sensible.
Additionally the text preceeding the example claims that it
works for "two or more commits", but the example itself is
really tailored for just two. Expanding it just a little
makes it clear how the procedure generalizes to N commits.
Finally the example is annotated with some commentary to
explain things on a line-by-line basis.
When the user specifies a ref by a reflog entry older than
one we have (e.g., "HEAD@{20 years ago"}), we issue a
warning and give them the "from" value of the oldest reflog
entry. That is, we say "we don't know what happened before
this entry, but before this we know we had some particular
SHA1".
However, the oldest reflog entry is often a creation event
such as clone or branch creation. In this case, the entry
claims that the ref went from "00000..." (the null sha1) to
the new value, and the reflog lookup returns the null sha1.
While this is technically correct (the entry tells us that
the ref didn't exist at the specified time) it is not
terribly useful to the end user. What they probably want
instead is "the oldest useful sha1 that this ref ever had".
This patch changes the behavior such that if the oldest ref
would return the null sha1, it instead returns the first
value the ref ever had.
We never discovered this problem in the test scripts because
we created "fake" reflogs that had only a specified segment
of history. This patch updates the tests with a creation
event at the beginning of history.
Signed-off-by: Jeff King <peff@peff.net> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: mention ORIG_HEAD in am, merge, and rebase
Merge has always set ORIG_HEAD but never mentioned it, while we
recently added it to am and rebase. These facts should be reflected
in the documentation.
git-reset also sets ORIG_HEAD, but that fact is already mentioned in
the very first example so no changes were needed there.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If git attempts to delete a ref, but the unlink of the ref
file fails, we print a message to stderr. This is usually a
good thing, but if the error is ENOENT, then it indicates
that the ref has _already_ been deleted. And since that's
our goal, it doesn't make sense to complain to the user.
This harmonizes the error reporting behavior for the
unpacked and packed cases; the packed case already printed
nothing on ENOENT, but the unpacked printed unconditionally.
Additionally, send-pack would, when deleting the tracking
ref corresponding to a remote delete, print "Failed to
delete" on any failure. This can be a misleading
message, since we actually _did_ delete at the remote side,
but we failed to delete locally. Rather than make the
message more precise, let's just eliminate it entirely; the
delete_ref routine already takes care of printing out a much
more specific message about what went wrong.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>