When svn:mergeinfo contains two new parents in a specific order and
one is ancestor of the other, it is possible that git-svn discards the
wrong one. The first test case ("commit made to merged branch is
reachable from the merge") proves this.
The second test case ("merging two branches in one commit is detected
correctly") is just for completeness, since there was no test for
merging two (feature) branches to trunk in one commit.
Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
A few "svn cp" commands and commit commands were executed in incorrect
order. Therefore some of the desired commits were missing and some
were committed with wrong revision number in the commit message. This
made it hard to compare the produced git repository with the SVN
repository.
The dump file is updated too, but only the relevant parts and with
hand-edited timestamps to make history linear.
Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Requires a small change to wrap-for-bin.sh in order to work.
Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We may later add a new configuration variable in "init" section that takes
a boolean value. Erroring out at the beginning of the config parser makes
life harder for later enhancement.
The existing configuration variable is parsed by git_config_pathname()
that checks and rejects init.templatedir that is unset without this extra
check. Remove it.
Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the synopsis for git-grep(1), show that --cached and <tree>... cannot
be used together.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The convention for this particular page is to use AsciiDoc literal
strings only for options (`-x` or `--long`), but not for definition list
terms and not for <meta-vars>.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows, the equivalent of "/dev/null" is "nul". This implements
compatibility wrappers around fopen() and freopen() that check for this
particular file name.
The new tests exercise code paths where this is relevant.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is required on Windows because git-notes is now a built-in
rather than a shell script.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In gitmkdtemp, the return value of mktemp is not tested correctly.
mktemp() always returns its 'template' argument, even upon failure.
An error is signalled by making the template an empty string.
Signed-off-by: Filippo Negroni <fnegroni@flexerasoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The mode bits for entries in a tree object should be an octal number
with minimum number of digits. Do not pad it with 0 to the left.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use PARSE_OPT_NONEG to disallow --no-<option> for message, file,
reedit-message and reuse-message. for which --no-<option> does not make
sense. This also simplifies the code in the option-handling callbacks.
Also, use strbuf_addch(... '\n') instead of strbuf_addstr(... "\n") in
couple of places.
Finally, improve the short-help by dividing the options into two
OPT_GROUPs.
Suggested-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Acked-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rather than only clearing GIT_INDEX_FILE, take the list of environment
variables to clear from local_repo_env, appending the settings for
GIT_DIR and GIT_WORK_TREE.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-submodule used to take care of clearing GIT_DIR whenever it operated
on a submodule index or configuration, but forgot to unset GIT_WORK_TREE
or other repo-local variables. This would lead to failures e.g. when
GIT_WORK_TREE was set.
This only happened in very unusual contexts such as operating on the
main worktree from outside of it, but since "git-gui: set GIT_DIR and
GIT_WORK_TREE after setup" (a9fa11fe5b) such failures could also
be provoked by invoking an external tool such as "git submodule update"
from the Git Gui in a standard setup.
Solve by using the newly introduced clear_local_git_env() shell function
to ensure that all repo-local environment variables are unset.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce an auxiliary function to clear all repo-local environment
variables. This should be invoked by any shell script that switches
repository during execution, to ensure that the environment is clean
and that things such as the git dir and worktree are set up correctly.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This prints the list of repo-local environment variables.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move the list of GIT_* environment variables that are local to a
repository into a static list in environment.c, as it is also
useful elsewhere. Also add the missing GIT_CONFIG variable to the
list.
Make it easy to use the list both by NULL-termination and by size;
the latter (excluding the terminating NULL) is stored in the
local_repo_env_size define.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were written back when we always read objects from the standard
input. These days --revs and its friends can feed only the start and
end points and have the command internally enumerate the objects.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the user runs
git config --global user.name Your Name
as suggested, user.name will be set to "Your". With this patch, the
suggested command will be
git config --global user.name "Your Name"
which will set user.name to "Your Name" and hopefully help users avoid
the former mistake.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A simple "git shortlog" outside of a git repository stalls
waiting for an input. Check if that's the case by testing with
isatty() before read_from_stdin(), and warn the user like
"git commit" does in a similar case.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since "git fetch" learned "--all" and "--multiple" options, it has become
tempting for users to say "git pull --all". Even though it may fetch from
remotes that do not need to be fetched from for merging with the current
branch, it is handy.
"git fetch" however clears the list of fetched branches every time it
contacts a different remote. Unless the current branch is configured to
merge with a branch from a remote that happens to be the last in the list
of remotes that are contacted, "git pull" that fetches from multiple
remotes will not be able to find the branch it should be merging with.
Make "fetch" clear FETCH_HEAD (unless --append is given) and then append
the list of branches fetched to it (even when --append is not given). That
way, "pull" will be able to find the data for the branch being merged in
FETCH_HEAD no matter where the remote appears in the list of remotes to be
contacted by "git fetch".
Reported-by: Michael Lukashov
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you have a branch.$X.merge config option, but no branch.$X.remote, and
your configuration tries to push tracking branches, git will segfault.
The problem is that even though branch->merge_nr is 1, you don't actually
have an upstream since there is no remote. Other callsites generally
check explicitly that branch->merge is not NULL, so let's do that here,
too.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running a subfetch, the code propagated some options but not others.
Propagate --force, --update-head-ok and --keep options as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All of these tests were bogus, as they created new directory and tried to
run "git pull" without even running "git init" in there. They were mucking
with the repository in $TEST_DIRECTORY.
While fixing it, modernize the style not to chdir around outside of
subshell. Otherwise a failed test will take us to an unexpected directory
and we need to chdir back to the test directory in each test, which is
ugly and error prone.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Note that in the documentation for git-pull, documentation for the
--progress option is displayed under the "Options related to fetching"
subtitle via fetch-options.txt.
Also, update the documentation of the -q/--quiet option for git-pull to
mention its effect on progress reporting during fetching.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Set transport->progress in transport.c::transport_set_verbosity() after
checking for the appropriate conditions (eg. --progress, isatty(2)),
and thereafter use it without having to check again.
The rules used are as follows (processing aborts when a rule is
satisfied):
1. Report progress, if force_progress is 1 (ie. --progress).
2. Don't report progress, if verbosity < 0 (ie. -q/--quiet).
3. Report progress if isatty(2) is 1.
This changes progress reporting behaviour such that if both --progress
and --quiet are specified, progress is reported.
In two areas, the logic to determine whether to *not* show progress is
changed to simply use the negation of transport->progress. This changes
behaviour in some ways (see previous paragraph for details).
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove the flags TRANSPORT_PUSH_QUIET and TRANSPORT_PUSH_VERBOSE; use
transport->verbose instead to determine verbosity for pushing.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
transport_set_verbosity() is now provided to transport users.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After 3f7a9b5 (Documentation/git-pull.txt: Add subtitles above included
option files, Thu Oct 22 2009), the -q/-v options were mentioned only
for the merge options section, giving the impression that git-fetch did
not take those arguments.
Follow 90e4311 (git-pull: do not mention --quiet and --verbose twice,
Mon Sep 7 2009) and hide -q/-v for merge options, while mentioning -q/-v
before the merge- and fetch-specific options.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After 5a518ad (clone: use --progress to force progress reporting),
-v/--verbose did not affect whether progress status was reported to
stderr, and users accustomed to using -v to do so since 21188b1
(Implement git clone -v) may be confused.
Mitigate such risks by stating -v does not affect progress in the
documentation.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git am does an automatic gc it doesn't clean up the rebase-apply
directory until after this has finished. This means that if the user
aborts the gc then future am or rebase operations will report that an
existing operation is in progress, which is undesirable and confusing.
Reported by Mark Brown <broonie@debian.org> through
http://bugs.debian.org/570966
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When RUNTIME_PREFIX is enabled, the installation prefix is derived by
trying a limited set of known locations where the git executable can
reside. If none of these is found, a warning is emitted.
When git is built in a directory that matches neither of these known names,
the warning would always be emitted when the uninstalled executable is run.
This is a problem on Windows, where gitk picks the uninstalled git when
invoked from the build directory and gets confused by the warning.
Print the warning only when GIT_TRACE is set.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to relevant RFCs, in addition to alphanumerics, the following
characters are valid in URL scheme parts: '+', '-' and '.', but
currently only alphanumerics are allowed in remote helper names.
Allow those three characters in remote helper names (both 'foo://' and
'foo::' syntax).
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
23a64c9e (conflict-marker-size: new attribute, 2010-01-16) introduced the
new attribute and also pass the conflict marker size as %L to merge driver
commands. This documents the substitution.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 1b22b6c897 made duplicated versions of encode_header() into a
common version called encode_in_pack_object_header(). There is however
a better location that sha1_file.c for such a function though, as
sha1_file.c contains nothing related to the creation of packs, and
it is quite populated already.
Also the comment that was moved to the header file should really remain
near the function as it covers implementation details and provides no
information about the actual function interface.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we look at a patch for adding hunks interactively, we
first split it into a header and a list of hunks. Some of
the header lines, such as mode changes and deletion, however,
become their own selectable hunks. Later when we reassemble
the patch, we simply concatenate the header and the selected
hunks. This leads to patches like this:
diff --git a/file b/file
index d95f3ad..0000000
--- a/file
+++ /dev/null
deleted file mode 100644
@@ -1 +0,0 @@
-content
Notice how the deletion comes _after_ the ---/+++ lines,
when it should come before.
In many cases, we can get away with this as git-apply
accepts the slightly bogus input. However, in the specific
case of a deletion line that is being applied via "apply
-R", this malformed patch triggers an assert in git-apply.
This comes up when discarding a deletion via "git checkout
-p".
Rather than try to make git-apply accept our odd input,
let's just reassemble the patch in the correct order.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to unnecessarily give the read permission to group and others,
regardless of the umask, which isn't serious because the objects are
still protected by their containing directory, but isn't necessary
either.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
