One "svn log" (or its equivalent) per revision adds delay and server load.
Instead, open two SVN connections -- one for the log, and one for the files.
Positive side effect: Only those log entries which actually contain data
are committed => no more empty commits.
Also, change the "-l" option to set the maximum revision to be pulled,
not the number of revisions.
The malloc patch from Jan Andres fixed the problem that was causing a
segfault when freeing the lock token, and Johannes Schindelin found
and fixed a problem when no URL is specified on the command line.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
The "--shared" option to git-clone is silently ignored if "--local" is
not specified. The manual doesn't mention such dependency. Make
"--shared" imply "--local".
Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation: Describe merge operation a bit better.
In git-merge documentation, add a section to describe what happens to
the index and working tree during merge, and what their cleanliness
requirements are before the merge.
rebase: one safety net, one bugfix and one optimization.
When a .dotest from a previously failed rebase or patch
application exists, rebase got confused and tried to apply
mixture of what was already there and what is being rebased.
Check the existence of the directory and barf.
It failed with an mysterious "fatal: cannot read mbox" message
if the branch being rebased is fully in sync with the base.
Also if the branch is a proper descendant of the base, there is
no need to run rebase logic. Prevent these from happening by
checking where the merge-base is.
gitk: Fix diff this->selected and selected->this functions
The change in 8b7e5d76e836396a097bb6f61cf930ea872a7bd3, which makes
a couple of git-diff-tree calls supply only one id rather than two,
fixes the display when showing what a single commit did with dense
revlists, but broke the diff this->selected and diff selected->this
right-click menu functions.
Yann Dirson pointed this out and had a patch that fixed the diff
menu functions by passing a "singlecommit" flag around. This fixes
it a bit differently, by making the ids and diffids variables be
either a single id, in the case of showing what a commit did, or
{oldid newid}, in the case of the diff menu functions. That way
we can just pass $ids to git-diff-tree as is. Most of the changes
in fact are just reversing the order of ids in $ids and $diffids,
because they used to be {child parent}, but git-diff-tree requires
old id before new id.
mailinfo: Do not use -u=<encoding>; say --encoding=<encoding>
Specifying the value for a single letter, single dash option
parameter with equal sign looked funny, and more importantly
calling the flag to override encoding from utf-8 to something
else "-u" (obviously abbreviated from "utf-8") did not make any
sense. So spell it out.
This uses i18n.commitencoding configuration item to pick up the
default commit encoding for the repository when converting form
e-mail encoding to commit encoding (the default is utf8).
mailinfo: allow -u to fall back on latin1 to utf8 conversion.
When the message body does not identify what encoding it is in,
-u assumes it is in latin-1 and converts it to utf8, which is
the recommended encoding for git commit log messages.
With -u=<encoding>, the conversion is made into the specified
one, instead of utf8, to allow project-local policies.
The change made in 8b7e5d76e836396a097bb6f61cf930ea872a7bd3 to
accomodate dense revlists in single-commit diffs has broken computing
of diffs between arbitrary trees, which does need to consider two
commit ids.
This patch changes the two git-diff-tree calls to get the necessary
two ids in this case. It does so by propagating a "singlecommit" flag
through all functions involved via an additional argument.
Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-mv: fully detect 'directory moved into itself'
This gives a better error message when trying to move a directory
into some subdirectory of itself; ie. no real bug fix: renaming
already failed before, but with a strange "invalid argument".
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-mv: keep git index consistent with file system on failed rename
When doing multiple renames, and a rename in the middle fails,
git-mv did not store the successful renames in the git index;
this is fixed by delaying the error message on a failed rename
to after the git updating.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
It checks if an existing config file says the repository being
reinitialized is of a wrong version and aborts before doing
further harm.
When copying the templates, it makes sure the they are of the
right repository format version. Otherwise the templates are
ignored with an warning message.
It copies the templates before creating the HEAD, and if the
config file is copied from the template directory, reads it,
primarily to pick up the value of core.symrefsonly.
It changes the way the result of the filemode reliability test
is written to the configuration file using git_config_set().
The test is done even if the config file was copied from the
templates.
And finally, our own repository format version is written to the
config file.
After daemon, upload-pack and receive-pack find out where the
git directory is and chdir() there, make sure that repository is
in a format we understand, after putenv("GIT_DIR=.") so that it
knows to pick up the configuration file from there.
git-sh-setup: move the repository check to a core program.
Any core commands that use setup_git_directory() now check if
given GIT_DIR is really a valid repository, so the same check in
git-sh-setup can use it without reimplementing it in shell.
This commit changes git-sh-setup to use git-var command for
that, although any other commands would do.
Note that we export GIT_DIR explicitly when calling git-var;
without it, the caller of this script would use GIT_DIR that we
return (which is to assume ./.git unless the caller has it
elsewhere) while git-var would go up to find a .git directory in
our parent directories, which would be checking a different
directory from what our callers will be using.
setup_git_directory: make sure GIT_DIR is a valid repository.
setup_git_directory() always trusted what the user told where
GIT_DIR was, and assumed that is a valid .git/ directory. This
commit changes it to at least do the same level validation as
is_toplevel_directory() does -- has refs/, has objects/ unless
GIT_OBJECT_DIRECTORY is set, and has valid HEAD symlink or
symref.
Now all the users of this script detect its exit status and die,
complaining that it is outside git repository. So move the code
that dies from all callers to git-sh-setup script.
There is no reason to use git-sh-setup from git-ls-remote.
git-parse-remote can help the caller to use .git/remotes
shortcut if it is run inside a git repository, but can still be
useful outside a git repositoryas long as the caller does not
use any shortcut. Use "git-rev-parse --git-dir" to figure out
where the GIT_DIR is, instead of using git-sh-setup.
This also makes "git-ls-remote origin" to work from inside a
subdirectory of a git managed repository as a side effect.
git-update-index --index-info can almost be usable to read from ls-tree
output to update the index (and not the working tree file) to HEAD commit,
but not quite. It was designed to read from git-apply --index-info
output, and does not want " blob " in ls-tree output. Accept that as well.
This lets us update "git-checkout <ent> <path>" that used to filter the
extra " blob " string out. Noted by Luben.
Revert always should explain why, so make --edit the default,
unless stdin is not a terminal. If you really don't want to say
anything, you can say "git-revert --no-edit $commit", or if you
are really sick, you could also say "git-revert $commit </dev/null".
But please don't.
You can also say "git-cherry-pick --edit $commit". Not editting
the commit log message is the default for cherry-pick.
I think all commit operations should allow editing of the message (ie we
should do this for merges too), but that's _particularly_ true of doing a
"git revert".
We should always explain why we needed to revert something.
This patch adds a "-e" or "--edit" flag to "git revert", although I
actually suspect it should be on by default (and we should have a
"--no-edit" flag to disable it, probably together with an automatic
disable if stdin isn't a terminal).
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
This is fixed by putting the file into @changedfiles/@addedfiles,
and not the directory this file is in.
Additionally, this fixes the behavior for attempting to overwrite
a file with a directory, and gives a message for all cases where
overwriting is not possible (file->dir,dir->file,dir->dir).
Thanks for Alexander Litvinov for noting this problem.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-pull invoked merge with recursive as the default strategy
for some time now; match it in the git-merge itself. Also avoid
listing more than one strategy on default because we have only
one strategy that can resolve an octopus and we are already
counting heads here. This reduces the need to stash away local
modifications.
Binary representation of object names are unsigned char[20], not
signed. Also verbose output had %lu format printing size_t
without (unsigned long) cast other places already had, so match
that. Using format %zu was suggested but might not be supported
as widely.
Noted by Morten Welinder, fixed with input from H. Peter Anvin
and Hideaki Yoshifuji.
Fixed git:// IPv4 address problem when compiled with -DNO_IPV6.
Failure to dereference a pointer caused incorrect initialization of
the IPv4 address when calling connect() when compiled with -DNO_IPV6.
With this patch and yesterday's patch for git-daemon, it should now be
possible to use the native git protocol for both the client and server
on Cygwin.
Signed-off-by: Paul Serice <paul@serice.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git-pack-redundant take a list of unimportant objs on stdin
This lets us do "git-fsck-objects --full --unreachable | cut -d ' ' -f3 |
git-pack-redundant --all", which will keep git-pack-redundant from keeping
packs just because they contain unreachable objects.
Also add some more --verbose output.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
When a path designation is given, max-count counts the number
of commits therein (intersection), not globally.
This avoids the case where in case path has been inactive
for the last N commits, --max-count=N and path designation
at git-rev-list is given, would give no commits.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Better variant, which handles stuff like "4.5%" and rejects
"192.168.0.1". Additionally, make sure numbers are unsigned (I'm making
them unsigned long just for the hell of it), to make sure that
artificial wraparound scenarios don't cause harm.
-hpa
[jc: with this, -M100 changes its meaning back to 10%. People
wanting to say "pure renames only" should now say -M100% or
-M1.0; sounds a bit like an earthquake, but arguably things are
more consistent this way ;-)]
In a corrupt repository, git-repack produces a pack that does not
contain needed objects without complaining, and the result of this
combined with -d flag can be very painful -- e.g. a lossage of one
tree object can lead to lossage of blobs reachable only through that
tree.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
This builds on top of the git-proxy mechanism Paul Collins did,
and updates its configuration mechanism.
* GIT_PROXY_COMMAND environment variable is used as the
catch-all fallback, as in the original. This has not
changed.
* Renames proxy configuration variables to core.gitproxy; this
has become a multi-value variable per list discussion, most
notably from suggestion by Linus.
[core]
;# matches www.kernel.org as well
gitproxy = netcatter for kernel.org
gitproxy = netscatter for sample.xz
gitproxy = none for mydomain.xz
gitproxy = netcatter-default
The values are command names, followed by an optional " for "
and domainname; the first tail-match of the domainname
determines which proxy command is used. An entry without "
for " matches any domain and can be used as the default.
The command name "none" is special -- it tells the mechanism
not to use any proxy command and use the native git://
connection.
Here is an updated patch that first looks for GIT_PROXY_COMMAND
in the environment and then git.proxycommand in the repository's
configuration file. I have left the calling convention the same
argv[1] is the host and argv[2] is the port.
I've taken the hostname parsing verbatim from git_tcp_connect(),
so it should now support an explicit port number and whatever
that business with the square brackets is. (Should I move this
to a helper function?)
Regarding internal vs. external hosts, the proxy command can
simply run netcat locally to internal hosts, so perhaps that is
sufficient.
tutorial: setting up a tree for subsystem maintainers
The "copying over packs" step is to prevent the objects
available in upstream repository to get expanted in the
subsystem maintainer tree, and is still valid if the upstream
repository do not live on the same machine. But if they are on
the same machine using objects/info/alternates is cleaner.
rename detection with -M100 means "exact renames only".
When the user is interested in pure renames, there is no point
doing the similarity scores. This changes the score argument
parsing to special case -M100 (otherwise, it is a precision
scaled value 0 <= v < 1 and would mean 0.1, not 1.0 --- if you
do mean 0.1, you can say -M1), and optimizes the diffcore_rename
transformation to only look at pure renames in that case.
format-patch: fix two-argument special case, and make it easier to pick single commits
Luben Tuikov noticed that sometimes being able to say
'git-format-patch <commit>' to format the change a single commit
introduces relative to its parent is handy.
This patch does not support that directly, but it makes sense to
interpret a single argument "rev" to mean "rev^1..rev".
With this, the backward compatibility syntaxes still apply:
- "format-patch master" means "format-patch master..HEAD"
- "format-patch origin master" means "format-patch origin..master"
- "format-patch origin.." means "format-patch origin..HEAD"
But "format-patch a b c d e" formats the changes these five
commits introduce relative to their respective parents. Earlier
it rejected these arguments not in "one..two" form.
Make sure heads/foo and tags/foo do not confuse things.
When both heads/foo and tags/foo exist, get_sha1_basic("foo")
picked up the tag without complaining, which is quite confusing.
Make sure we require unambiguous form, "heads/foo" or "tags/foo"
in such cases.
We wanted --strict to mean "do not DWIM", but the code required to
see absolute path. daemon does its own path verification and chdirs
to the verified repository, so enter_repo() called from upload-pack
will always enter ".". Requiring absolute path does not make any sense.
This basically translates the man-page from 'git-developerish' to plain
english, adding some almost-sample output from git-status so users can
recognize what will happen.
Also mention explicitly that --mixed updates the index, while --soft
doesn't. I understood the old text to mean "--mixed is exactly like
--soft, but verbose".
Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
Make some functions static and convert func() function prototypes to to
func(void). Fix declaration after statement, missing declaration and
redundant declaration warnings.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
It has a fatal flaw in that it only handles timezones that are a
multiple of an hour. It's really only needed with Tk8.5, where
the clock format command has been reimplemented in Tcl and is much
slower than in Tk8.4.
Commits that weren't read from git-rev-list, i.e. the ones displayed
with an open circle, were displayed incorrectly: the headline was
null if there was only one line, and the commit comment was put all
on one line. Also, the terminal commits weren't displayed when -r
was used.
--replace-all, to replace any amount of matching lines, not just 0 or 1,
--get, to get the value of one key,
--get-all, the multivar version of --get, and
--unset-all, which deletes all matching lines from .git/config
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not DWIM in userpath library under strict mode.
This should force git-daemon administrator's job a bit harder
because the exact paths need to be given in the whitelist, but
at the same time makes the auditing easier.
This moves validate_symref() from refs.c to path.c, because we
need to link path.c with git-daemon for its "enter_repo()", but
we do not want to link the daemon with the rest of git libraries
and its requirements.
This patch provides the work-horse of the user-relative paths feature,
using Linus' idea of a blind chdir() and getcwd() which makes it
remarkably simple.
Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
Add functions git_config_set() and git_config_set_multivar()
The function git_config_set() does exactly what you think it does.
Given a key (in the form "core.filemode") and a value, it sets the
key to the value. Example:
git_config_set("core.filemode", "true");
The function git_config_set_multivar() is meant for setting variables which
can have several values for the same key. Example:
The third argument of the function is a POSIX extended regex which has to
match the value. If there is no key/value pair with a matching value, a new
key/value pair is added.
These commands are also capable of unsetting (deleting) entries:
The decision about whether to build http-push or not belongs in the
Makefile. This follows Junio's suggestion to determine whether curl
is new enough to support http-push.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>