* sp/remote:
Make "git-remote rm" delete refs acccording to fetch specs
Make "git-remote prune" delete refs according to fetch specs
Remove unused remote_prefix member in builtin-remote
When a pack gets corrupted, its SHA1 checksum will fail. However, this
is more useful to let the test go on in order to find the actual
problem location than only complain about the SHA1 mismatch and
bail out.
Also, it is more useful to compare the stored pack SHA1 with the one in
the index file instead of the computed SHA1 since the computed SHA1
from a corrupted pack won't match the one stored in the index either.
Finally a few code and message cleanups were thrown in as a bonus.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'jc/checkout':
checkout: "best effort" checkout
unpack_trees(): allow callers to differentiate worktree errors from merge errors
checkout: consolidate reset_{to_new,clean_to_new}()
checkout: make reset_clean_to_new() not die by itself
If config is called in array context, it is supposed to return all
values set for the given option key. This works for all cases except
if there is no value set at all. In that case, it wrongly returns
(undef) instead of (). This fixes the return statement so that it
returns undef in scalar context but an empty array in array context.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
They now point to more specific/appropriate targets.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch renames the following documents and at the same time converts
them to the man format:
core-tutorial.txt -> gitcore-tutorial.txt
glossary.txt -> gitglossary.txt
But as the glossary is included in the user manual and as the new
gitglossary man page cannot be included as a whole in the user manual,
the actual glossary content is now in its own "glossary-content.txt"
new file. And this file is included by both the user manual and the
gitglossary man page.
Other documents that reference the above ones are changed accordingly
and sometimes improved a little too.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation of hash_object incorrectly states that it accepts a
file handle -- in fact it doesn't, and there is even a TODO comment
for this. This fixes the documentation.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an octopus merge is printed, several lines are printed before it to
move over existing branch lines to its right. This is needed to make
room for the children of the octopus merge. For example:
| | | |
| | \ \
| | \ \
| | \ \
| M---. \ \
| |\ \ \ \ \
However, this step isn't necessary if there are no branch lines to the
right of the octopus merge. Therefore, skip this step when it is not
needed, to avoid printing extra lines that don't really serve any
purpose.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change improves the way merge commits are displayed, to eliminate a
few visual artifacts. Previously, merge commits were displayed as:
| M \
| |\ |
As pointed out by Teemu Likonen, this didn't look nice if the rightmost
branch line was displayed as '\' on the previous line, as it then
appeared to have an extra space in it:
| |\
| M \
| |\ |
This change updates the code so that branch lines to the right of merge
commits are printed slightly differently depending on how the previous
line was displayed:
| |\ | | | | | /
| M \ | M | | M |
| |\ \ | |\ \ | |\ \
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If url://repo/trunk is the current Git branch, prop_walk strips trunk
from the path name. That is useful as, for example "git svn show-ignore"
should not return results like
trunk/foo
but
foo
if svn:ignore for trunk includes foo.
The problem now is that prop_walk strips trunk from the path and then
calls itself recursively. But now trunk is missing in the path and
get_dir fails, because it is called for a non existing path.
The attached patch fixed the problem, by adding the previously stipped
$self->{path} in the recursive call. I tested it with my current
git-svn repository for the commands show-ignore and show-external.
Patch was submitted through
http://bugs.debian.org/477393
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When working with multiple branches in an svn repository, it can be
useful to verify the svn repository and local tracking branch that will
be used for the rebase operation.
Signed-off-by: Seth Falcon <seth@userprimary.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Given an SVN repo file:///tmp/svntest/repo, trying to commit changes
to a file proj/trunk/foo.txt in that repo with this command line
git svn commit-diff -r2 HEAD^ HEAD file:///tmp/svntest/repo/proj/trunk
gave the error message
Filesystem has no item: File not found: transaction '2-6', path
'/proj/trunk/proj/trunk/foo.txt'
This fixes the duplication.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A remote may be configured to fetch into tracking branches that
don't match its name. A user may have created a remote by hand
that will fetch to a different tracking branch namespace:
[remote "alt"]
url = git://repo.or.cz/alt-git.git
fetch = refs/heads/*:refs/remotes/origin/*
When deleting remote alt we should clean up the refs whose names
start with "refs/remotes/origin/", even though the remote itself
was named alt by the user.
To avoid deleting refs used by another remote we only clear refs
that are unique to this remote. This prevents `git prune rm alt`
from removing the refs used by say origin if alt was just using a
different URL for the same repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A remote may be configured to fetch into tracking branches that
do not match the remote name. For example a user may have created
extra remotes that will fetch to the same tracking branch namespace,
but from different URLs:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = refs/heads/*:refs/remotes/origin/*
[remote "alt"]
url = git://repo.or.cz/alt-git.git
fetch = refs/heads/*:refs/remotes/origin/*
When running `git remote prune alt` we expect stale branches to
be removed from "refs/remotes/origin/*" and not from the unused
namespace of "refs/remotes/alt/*".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not sure when this became unused, but no code references it,
other than to populate the strbuf with an initial value.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this, some tests will fail because they compare command output
of subprocesses (such as git) with $PWD -- but subprocesses have the
physical path as their working directory, whereas $PWD contains the
symlinked path. This fixes it.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running git-reset in a non-interactive setting, the -q switch
works for everything except the progress updates. This squelches it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch moves the am test cases in t4150-am.sh and the
am subdirectory test cases from t/t4150-am-subdir.sh into
t/4151-am.sh.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add t/t4151-am.sh that does basic testing of git-am functionality,
including:
* am applies patch correctly
* am changes committer and keeps author
* am --signoff adds Signed-off-by: line
* am stays in branch
* am --signoff does not add Signed-off-by: line if already there
* am without --keep removes Re: and [PATCH] stuff
* am --keep really keeps the subject
* am -3 falls back to 3-way merge
* am pauses on conflict
* am --skip works
* am --resolved works
* am takes patches from a Pine mailbox
* am fails on mail without patch
* am fails on empty patch
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the pack-files are now always created stably on disk, there is no
need to sync() before pruning lose objects or old stale pack-files.
[jc: with Nico's clean-up]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This means that we can depend on packs always being stable on disk,
simplifying a lot of the object serialization worries. And unlike loose
objects, serializing pack creation IO isn't going to be a performance
killer.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Alter the description of <repository> in OPTIONS section to
explicitly state that a 'remote name' is accepted.
Rewrite REMOTES section to more directly identify the
different kinds of remote-name permitted.
Signed-off-by: John J. Franey <jjfraney@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Other signals are also common, for example SIGTERM and SIGHUP.
This patch modifies the lock file mechanism to catch more signals.
It also modifies http-push.c which was missing SIGTERM.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unfortunately the list is not complete, but includes the essential ones.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Testing if gitweb handles filenames with spaces, filenames with plus
sign ('+') which encodes spaces in CGI parameters (in URLs), and
filenames with Unicode characters should be handled by gitweb tests.
Those files are remainder of the time when gitweb was project on its
own, not a part of git (with its testsuite).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a cache entry has been marked as CE_VALID, the user has
promised us that any change in the work tree does not matter.
Just mark the entry as up-to-date, and continue.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous documentation didn't make it clear that the
"assume unchanged" was on per file basis, and not a global
flag.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When unpack_trees() returned an error while switching branches, we used to
stop right there, exiting without writing the index out or switching HEAD.
This is Ok when unpack_trees() returned an error because it detected
untracked files or locally modified paths that could be overwritten by
branch switching, because that error return is done before we start to
modify the work tree. But it is undesirable if unpack_trees() already
started to update the work tree and a failure is returned because some but
not all paths are updated in the work tree, perhaps because a directory
that some files need to go in was read-only by mistake, or a file that
will be overwritten by branch switching had a mandatory lock on it and we
failed to unlink it.
This changes the behaviour upon such an error to complete the branch
switching; the files updated in the work tree will hopefully be much more
consistent with the index and HEAD derived from the switched-to branch.
We still issue error messages, and exit the command with non-zero status,
so scripted callers need to notice it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of uniformly returning -1 on any error, this teaches
unpack_trees() to return -2 when the merge itself is Ok but worktree
refuses to get updated.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is unfortunate that "git init --bare" does not work and the only reason
why "init" did not learn its own "--bare" option is because "git --bare
init" already does the job (and as an option to the git 'potty', it is
more generic solution).
This teaches "git init" its own "--bare" option, so that both "git --bare init"
and "git init --bare" works mostly the same way.
[jc: rewrote the log message and added test]
Signed-off-by: Luciano Rocha <strange@nsk.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead, have its error percolate up through the callchain and let it be
the exit status of the main command. No semantic changes yet.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git checkout -- paths..." cannot update work tree for whatever
reason, checkout_entry() correctly issued an error message for the path to
the end user, but the command ignored the error, causing the entire
command to succeed. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Geoffrey Irving noticed that git-cherry talks about comparing commits without
hinting how they are compared.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It seems simpler and safer to use the BISECT_START file everywhere
to decide if we are bisecting or not, instead of using it in some
places and BISECT_NAMES in other places.
In commit 6459c7c678 (Nov 18 2007,
Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.),
we decided to use BISECT_NAMES but code changed a lot and we now
have to check BISECT_START first in the "bisect_start" function
anyway.
This patch also makes things a little bit safer by creating
the BISECT_START file first and deleting it last, and also by
adding checks in "bisect_clean_state".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with builtin-fetch--tool.c where append_fetch_head()
honors update_local_ref() return value.
This fixes non fast forward fetch exit status,
http://bugzilla.altlinux.org/show_bug.cgi?id=15037
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An earlier commit 633f43e (Remove redundant code, eliminate one static
variable, 2008-05-24) had a thinko (perhaps an eyeno) that broke
sha1_pack_index_name() function. One symptom of this was that the http
walker is now completely broken.
This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent "git-svn optimization" series introduced Git::cat_blob() subroutine
whose interface was broken in that it returned the size of the blob but
signalled an error by returning 0. You can never use an empty blob with
such an interface.
This fixes the interface to return a negative value to signal an error.
Reported by Björn Steinbrink.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are broken filesystems that cannot have a file whose name is "nul"
anywhere on it. Rename the test file to make ourselves more portable.
Noticed by Mark Levedahl.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When adding files through git commit --interactive, and 'quit'
afterwards, the message in the editor of the commit message indicates
that many (maybe all) files are deleted from the tree. Dismissing that
and running git commit afterwards does the right thing. This commit
fixes git commit --interactive to properly update the index before
commiting.
Reported by Jiří Paleček through
http://bugs.debian.org/480429
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There was a bug in the implementation of the "next" links in
format_paging_nav (for log and shortlog), which caused the next links
to always be displayed, even if there is no next page. This fixes it.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit cfabd6eee1. I had
implemented it without understanding what --full-history does. Consider
this history:
C--M--N
/ / /
A--B /
\ /
D-/
where B and C modify a path, X, in the same way so that the result is
identical, and D does not modify it at all. With the path limiter X and
without --full-history this is simplified to
A--B
i.e. only one of the paths via B or C is chosen. I had assumed that
--full-history would keep both paths like this
C--M
/ /
A--B
removing the path via D; but in fact it keeps the entire history.
Currently, git does not have the capability to simplify to this
intermediary case. However, the other extreme to keep the entire history
is not wanted either in usual cases. I think we can expect that histories
like the above are rare, and in the usual cases we want a simplified
history. So let's remove --full-history again.
(Concerning t7003, subsequent tests depend on what the test case sets up,
so we can't just back out the entire test case.)
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
