If a repository ever gets in a situation where there are too many
packs (more than 60 or so), perhaps because of frequent use of
git-fetch -k or incremental git-repack, then it becomes impossible to
fully repack the repository with git-repack -a. That command just
dies with the cryptic message
fatal: too many internal rev-list options
This message comes from git-pack-objects, which is passed one command
line option like --unpacked=pack-<SHA1>.pack for each pack file to be
repacked. However, the current code has a static limit of 64 command
line arguments and just aborts if more arguments are passed to it.
Fix this by dynamically allocating the array of command line
arguments, and doubling the size each time it overflows.
Signed-off-by: Roland Dreier <roland@digitalvampire.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We should always avoid rewriting a built file during `make install`
if nothing has changed since `make all`. This is to help support
the typical installation process of compiling a package as yourself,
then installing it as root.
Forcing CREDITS-FILE to be always be rebuilt in the Makefile means
that CREDITS-GEN needs to check for a change and only update
CREDITS-FILE if the file content actually differs. After all,
content is king in Git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* 'jc/status' (early part):
run_diff_{files,index}(): update calling convention.
update-index: do not die too early in a read-only repository.
git-status: do not be totally useless in a read-only repository.
This is to resolve semantic conflict (which is not textual) that
changes the calling convention of run_diff_files() early.
To name a commit, you can now say
$ git rev-parse ':/Initial revision of "git"'
and it will return the hash of the youngest commit whose
commit message (the oneline) begins with the given prefix.
For future extension, a leading exclamation mark is treated
specially: if you want to match a commit message starting with
a '!', just repeat the exclamation mark. So, to match a commit
which starts with '!Hello World', use
$ git show ':/!!Hello World'
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
diff-patch: Avoid emitting double-slashes in textual patch.
Reword git-am 3-way fallback failure message.
Limit filename for format-patch
core.legacyheaders: Use the description used in RelNotes-1.5.0
git-show-ref --verify: Fail if called without a reference
Conflicts:
builtin-show-ref.c
diff.c
When the blobs recorded on the index lines in the patch as pre-image
blobs are not found in the repository, "git-am" punted saying
that the index line does not record anything useful. This was not
clear enough -- the index line does have something useful but the
problem was that it was not useful in _that_ repository.
Reword the message as Francis Moreau suggests.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Badly formatted commits may have very long comments. This causes
git-format-patch to fail. To avoid that, truncate the filename
to a value we believe will always work.
Err out if the patch file cannot be created.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The intent of the commit 'fetch & clone: do not output progress when
not on a tty' was to make fetching and cloning less chatty when
output was not redirected (such as in a cron job).
However, there was a serious thinko in that commit. It assumed that
the client _and_ the server got this update at the same time. But
this is obviously not the case, and therefore upload-pack died on
seeing the option "--no-progress".
This patch fixes that issue by making it a protocol option. So, until
your server is updated, you still see the progress, but once the
server has this patch, it will be quiet.
A minor issue was also fixed: when cloning, the checkout did not
heed no_progress.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It explains what it does and why, and says how to use the new format.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
builtin-show-ref.c (cmd_show_ref): Fail if called with --verify option but
without a reference.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When using do_switch:
We only need to ensure the index is clean and set to that of the
parent tree) we rely on being able to reconstruct full files
with deltas transferred over the network.
When using do_update:
We may safely unlink the index if we are fetching an entire
new tree with do_update. Having an old index (from a
previously deleted/abandoned directory) around can cause
irrelevant files to be mistakenly kept.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Clearing the pool of the previous SVN::Ra connection we have
seems to to fix mysterious connection dropping errors when
reconnecting to different paths of svn:// repositories hosted by
rubyforge.org.
Note: I'm not sure *why* this fixes things things,
but it does for me.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Several bugs caused this to fail:
* GIT_DIR was set incorrectly after entering the target directory
* Avoid double chdir-ing when clone is called with an explicit path
* create target subdirectory *before* running git-init when using
the multi-init path
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Also, it turns out that SVN::Ra doesn't attempt to deal with
authentication or pass the username to ssh when doing svn+ssh://
URLs
Signed-off-by: Eric Wong <normalperson@yhbt.net>
http://foo@blah.com/path is the same as http://blah.com/path, so
remove usernames from URLs before storing them in commits, and when
reading them from commits.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
If we are run inside a subdirectory of a working tree, we'll
chdir to the top first before touching anything. This also
prevents the accidental creation of .git directories inside
subdirectories since they need metadata.
Noticed by maio on #git
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This allows the user to run git-svn show-ignore on there
current HEAD without needing to remember which branch/ref they
branched from with -i. Also, find_by_url should correctly
handle cases where the URL passed to it is not valid.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since the options that affect the way metadata is handled in
git-svn, should be consistently set/unset throughout history
imported by git-svn; it makes sense to allow the user to set
certain options from the command-line that will write to the
config file when initially creating the repository.
Also, fix some formatting issues while we're updating
documentation.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This documents the 'clone' and 'rebase' commands
of git-svn. Additionaly, examples are updated
to use them instead of the lower-level 'init' and
'fetch' commands.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
These tests are very similar as the ones I used for useSvmProps
and expect the same results because both dumps were generated
from the same original repo.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
svm:mirror is not useful at all for us. Parts of the old unit
test were broken and based on my misunderstanding of the
svm:mirror property.
When we read svm:source; make sure we correctly handle the '!'
in it: it is used to separate the path of the repository root
from the virtual path within the repository. We don't need
to make that distinction, honestly!
We also ensure that subdirectories are also mirrored with the
correct URL if we're using useSvmProps.
We have a new test that uses dumped repo that was really
created using SVN::Mirror to avoid ambiguities and
mis-understandings about the svm: properties.
Note: trailing whitespace in the svm.dump file is unfortunately
a reality and required by SVN; so please ignore it when applying
this patch.
Also, ensure that the -R/--remote/--svn-remote flag is always
in effect if explicitly passed via the command-line. This
allows us to track logically different mirrors sharing the
same URL (probably common with SVN::Mirror/SVK users).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is similar to useSvmProps, but far simpler in
implementation because svnsync retains a 1:1
between revision numbers and relative paths within
the repository
Config keys: svn.useSvnsyncProps
svn-remote.<repo>.useSvnsyncProps
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This feature allows users to create repositories from alternate
URLs. For example, an administrator could run git-svn on the
server locally (accessing via file://) but wish to distribute
the repository with a public http:// or svn:// URL in the
metadata so users of it will see the public URL.
Config key: svn-remote.<remote>.rewriteRoot
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Having it named as 'config' prevents us from tracking a
ref named 'config', which is a huge mistake.
On the non-technical side, the word 'config' implies that
a user can freely modify it; but that's not the case
here.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Fixed logic for renaming old .rev_db -> .rev_db.$uuid
* correctly handle manual migrations for those who decide to
start use globbing to handle branches/tags over individual
'fetch' keys
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This works similarly to 'svn update' or 'git pull' except that
it preserves linear history with 'git rebase' instead of 'git
merge' for ease of dcommit-ing with git-svn.
While we're at it, put the working_head_info() logic
into its own function and allow --fetch-all/--all for
dcommit and rebase (which will fetch all refs in the
current [svn-remote] instead of just the working one).
Note that the '-a' switch (short for --fetch-all/--all) has been
removed as it conflicts with the non-svn 'git fetch'
Signed-off-by: Eric Wong <normalperson@yhbt.net>
On newly-created repositories, 'refs/heads/master' does not
point to anything. This can be confusing to new users; so we
update 'master' to point to the last imported ref after fetching
is done.
Once 'master' is valid; we assume HEAD points to it; and if
the repository is not bare, then checkout the files if the
working tree is clean and unused.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Force the showing of the --minimize flag as an option in the
'migrate' help.
Also, fix the usage function to correctly filter out
the deprecated aliases.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This allows users to use SVM (SVN::Mirror) to mirror a remote
repository to use dcommit to commit to the repository that SVM
was mirroring. When dcommit is used in this manner, the automatic
fetch + rebase/reset does not happen; in which case the user will
have to manually invoke svm/svk, run 'git svn fetch', and finally
'git rebase'.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The newer default value should should lower memory usage for
large fetches and also help with fetching from less reliable
servers. Previously the value was 1000 and memory usage
got a bit high on some repositories and fetching became
less reliable in some cases.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Also, some changes to avoid creating dead dirs under
.git/svn/. We now create all directories as late as
possible.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* avoid skipping modification-only changes in fetch
* correctly fetch when we only have branches and tags
to glob from (no fetch keys defined)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
multi-init is now just an alias that requires -T/-t/-b;
all options that 'init' can now accept.
This will hopefully simplify usage and reduce typing.
Also, allow the --shared option in 'init' to take an optional
argument now that 'git-init --shared' supports an optional
argument.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
multi-fetch is deprecated, "fetch -a" is easier to type
By default, fetch will fetch everything from its default
[svn-remote]; if fetch [--all|-a] is specified, then it will
fetch from all svn remotes. Refspecs on the command-line
(like git-fetch) are not supported.
Also, enable -r/--revision arguments for fetch so
users can shoot themselves in the foot^W^W^W^W^W
skip some history and do the equivalent of a shallow
clone/fetch they're not interested in.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Some of the repo-config => config renaming missed the git-svn
tests; so I'm just renaming them to be consisten with the
rest of the modern git.
Also, some of the newer tests didn't have 'poke' in them
to workaround race conditions on fast machines. This adds
places where they can _possibly_ occur; but I don't have
fast enough hardware to trigger them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Similar in spirit to the recent dcommit change, we now
look at 'HEAD' by default to look for a GIT_SVN_ID
so the user won't have to pass -i <GIT_SVN_ID> argument.
We are also more tolerant of of people passing bare remote names
as a result (just $GIT_SVN_ID without the -i)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Roland Dreier