Now "git merge -m" needs a message, and errors out with the usage
text if none is given.
This way, t7600-merge.sh is fixed.
Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com>
Acked-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Check that req_update shows refs, even if all refs are packed.
Signed-off-by: NLars Noschinski <lars@public.noschinski.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

5fdeacb0 (Teach update-index about --ignore-submodules, 2008-05-14) added a
new refresh option flag but did not assign a unique bit for it correctly,
and broke "update-index --ignore-missing".

This fixes it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently fast-import/export cannot be used for
repositories with submodules. This patch extends
the relevant programs to make them correctly
process gitlinks.

Links can be represented by two forms of the
Modify command:

M 160000 SHA1 some/path

which sets the link target explicitly, or

M 160000 :mark some/path

where the mark refers to a commit. The latter
form can be used by importing tools to build
all submodules simultaneously in one physical
repository, and then simply fetch them apart.
Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Check that all branches are displayed.
Signed-off-by: NFabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: NLars Noschinski <lars@public.noschinski.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The CVS_SERVER environment variable can cause some of the cvsimport tests
to fail. So unset this variable at the beginning of the test script.
Signed-off-by: NFabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: NLars Noschinski <lars@public.noschinski.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Scriptlets used form inside this test began with hardcoded "#!/bin/sh".
By setting SHELL_PATH the user is already telling us that what the vendor
has in /bin/sh isn't POSIX enough, and we really should try to honor that
request.

Originally noticed by SungHyun Nam who later tested this patch and
verified that it fixes the issue on Solaris 9.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When hold_locked_index() is called with a relative git_dir and you are
outside the work tree, the lock file become relative to the current
directory. So when later setup_work_tree() change the current directory
it breaks lock file path and commit_locked_index() fails.

This patch move index locking code after setup_work_tree() call to make
lock file relative to the working tree as it should be and add a test
case.

Noticed by Nick Andrew.
Signed-off-by: NOlivier Marin <dkr@freesurf.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It used plain 'if git merge ...', which hides a segfault. The test does not pass.
Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NSungHyun Nam <goweol@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since the files generated and used during a rebase are never to be
tracked, they should live in $GIT_DIR.  While at it, avoid the rather
meaningless term "dotest" to "rebase", and unhide ".dotest-merge".

This was wished for on the mailing list, but so far unimplemented.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We've supported cvsps 2.1 so far.  Newer 2.2b1 (beta) seems to work with
us, too.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since commit 8eca0b47, it is possible
for read_sha1_file() to return NULL even with existing objects when they
are corrupted.  Previously a corrupted object would have terminated the
program immediately, effectively making read_sha1_file() return NULL
only when specified object is not found.

Let's restore this behavior for all users of read_sha1_file() and
provide a separate function with the ability to not terminate when
bad objects are encountered.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This change makes "submodule add" much more strict in the arguments it
takes, and is intended to address confusion as recently noted on the
git-list. With this change, the required syntax is:

	$ git submodule add URL path

Specifically, this eliminates the form

	$ git submodule add URL

which was confused by more than one person as

	$ git submodule add path

With this patch, the URL locating the submodule's origin repository can be
either an absolute URL, or (if it begins with ./ or ../) can express the
submodule's repository location relative to the superproject's origin.

This patch also eliminates a third form of URL, which was relative to the
superproject's top-level directory (not its repository).  Any URL that was
neither absolute nor matched ./*|../* was assumed to point to a
subdirectory of the superproject as the location of the submodule's origin
repository.  This URL form was confusing and does not seem to correspond
to an important use-case.  Specifically, no-one has identified the need to
clone from a repository already in the superproject's tree, but if this is
needed it is easily done using an absolute URL: $(pwd)/relative-path.  So,
no functionality is lost with this patch. (t6008-rev-list-submodule.sh did
rely upon this relative URL, fixed by using $(pwd).)

Following this change, there are exactly four variants of
submodule-add, as both arguments have two flavors:

URL can be absolute, or can begin with ./|../ and thus names the
submodule's origin relative to the superproject's origin.

Note: With this patch, "submodule add" discerns an absolute URL as
matching /*|*:*: e.g., URL begins with /, or it contains a :.  This works
for all valid URLs, an absolute path in POSIX, as well as an absolute path
on Windows).

path can either already exist as a valid git repo, or will be cloned from
the given URL.  The first form here eases creation of a new submodule in
an existing superproject as the submodule can be added and tested in-tree
before pushing to the public repository.  However, the more usual form is
the second, where the repo is cloned from the given URL.

This specifically addresses the issue of

	$ git submodule add a/b/c

attempting to clone from a repository at "a/b/c" to create a new module
in "c". This also simplifies description of "relative URL" as there is now
exactly *one* form: a URL relative to the parent's origin repo.
Signed-off-by: NMark Levedahl <mlevedahl@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NJoão Abecasis <joao@abecasis.name>
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

"Subject: " isn't in the static array "header", and thus
memcmp("Subject:", header[i], 7) will never match.

Even if it did so, hdr_data[] may not have been allocated if there weren't
a "Subject: " in-body when we process "[PATCH]" in the affected codepath.
Signed-off-by: NLukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There are two cases for preserving merges:

  1. The merge base is outside the trunk that is to be rebased.
     Then commits of those other parents must not be picked.

  2. The merge base is inside the trunk that is to be rebased.
     Then all the commits related to that merge must be picked
     and the merge must be redone.

The "preserve merges with -p" test case tested for case 1 only.
This patch adds case 2.
Signed-off-by: NStephan Beyer <s-beyer@gmx.net>
Signed-off-by: NJunio 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.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Actually this is a simple test, just to ensure merge-resolve properly
calls read-tree. read-tree itself already has more complex tests.
Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It should fail properly if there are multiple merge bases, but there
were no test for this till now.
Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This patch changes every occurrence of "! git" -- with the meaning
that a git call has to gracefully fail -- into "test_must_fail git".

This is useful to

 - make sure the test does not fail because of a signal,
   e.g. SIGSEGV, and

 - advertise the use of "test_must_fail" for new tests.
Signed-off-by: NStephan Beyer <s-beyer@gmx.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NStephan Beyer <s-beyer@gmx.net>
Signed-off-by: NJunio 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: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio 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.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

using git-init as directory name confused 'make remove-dashes', so just
drop the 'git-' prefix.
Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

06cbe855 (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: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The command forgot the configuration variable when rewritten in C.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NOlivier Marin <dkr@freesurf.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

7ebd52aa (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.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When setting the GIT_SVN_LC_ALL variable, default to the $LANG
environment variable, when the $LC_ALL override is not set.
Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

On some setups, apache will say:
apache2: Could not reliably determine the server's fully qualified
domain name, using $(IP_address) for ServerName

Avoid this message polluting tests output by setting a ServerName in
apache configuration.
Signed-off-by: NMike Hommey <mh@glandium.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When USE_CURL_MULTI is undefined, git http-push doesn't work, so it's
useless to test it.
Signed-off-by: NMike Hommey <mh@glandium.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

http-push test has been broken by 4a7aaccd adding a space character
in the place where the test is being run.
Signed-off-by: NMike Hommey <mh@glandium.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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: NMike Hommey <mh@glandium.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Unpacked objects should receive the timestamp of the pack they were
unpacked from. Check.
Signed-off-by: NBrandon Casey <drafnel@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>