Testing is done by creating a simple git-merge-theirs strategy which is
the opposite of ours. Using this in real merges is not recommended but
it's perfect for our testing needs.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test assumed that we can keep the cached stat information fresh across
rename(2); many filesystems however update st_ctime (and POSIX allows them
to do so), and that assumption does not hold.
We can explicitly refresh the index for the purpose of these tests. The
only thing we are interested in is the staged contents and the mode bits
are preserved across "git mv".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a user passes "--template=", then our template parameter
is blank. Unfortunately, copy_templates() assumes it has at
least one character, and does all sorts of bad things like
reading from template[-1] and then proceeding to link all of
'/' into the .git directory.
This patch just checks for that condition in copy_templates
and aborts. As a side effect, this means that --template=
now has the meaning "don't copy any templates."
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rewrite of git-mv from a shell script to a builtin was perhaps
a little too straightforward: the git add and git rm queues were
emulated directly, which resulted in a rather complicated code and
caused an inconsistent behaviour when moving dirty index entries;
git mv would update the entry based on working tree state,
except in case of overwrites, where the new entry would still have
sha1 of the old file.
This patch introduces rename_index_entry_at() into the index toolkit,
which will rename an entry while removing any entries the new entry
might render duplicate. This is then used in git mv instead
of all the file queues, resulting in a major simplification
of the code and an inevitable change in git mv -n output format.
Also the code used to refuse renaming overwriting symlink with a regular
file and vice versa; there is no need for that.
A few new tests have been added to the testsuite to reflect this change.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Those shorthands are explained in the rev-parse documentation but were not
actually supported by rev-parse itself.
gitk internally uses rev-parse to interpret its command line arguments, and
being able to use these "limit with parents" syntax is handy there.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A wildcard refspec is internally parsed into a refspec structure with src
and dst strings. Many parts of the code assumed that these do not include
the trailing "/*" when matching the wildcard pattern with an actual ref we
see at the remote. What this meant was that we needed to make sure not
just that the prefix matched, and also that a slash followed the part that
matched.
But a codepath that scans the result from ls-remote and finds matching
refs forgot to check the "matching part must be followed by a slash" rule.
This resulted in "refs/heads/b1" from the remote side to mistakenly match
the source side of "refs/heads/b/*:refs/remotes/b/*" refspec.
Worse, the refspec crafted internally by "git-clone", and a hardcoded
preparsed refspec that is used to implement "git-fetch --tags", violated
this "parsed widcard refspec does not end with slash" rule; simply adding
the "matching part must be followed by a slash" rule then would have
broken codepaths that use these refspecs.
This commit changes the rule to require a trailing slash to parsed
wildcard refspecs. IOW, "refs/heads/b/*:refs/remotes/b/*" is parsed as
src = "refs/heads/b/" and dst = "refs/remotes/b/". This allows us to
simplify the matching logic because we only need to do a prefixcmp() to
notice "refs/heads/b/one" matches and "refs/heads/b1" does not.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero
status when asked to list nonexistent files. Unfortunately,
/bin/ls on Mac OS X 10.3 exits with exit code 0. So look at
its output instead.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Acked-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Subversion repositories often require files to have properties such as
svn:mime-type and svn:eol-style set when they are added. Users
typically set these properties automatically using the SVN auto-props
feature with 'svn add'. This commit teaches dcommit to look at the user
SVN configuration and apply matching auto-props entries for files added
by a diff as it is applied to the SVN remote.
Signed-off-by: Brad King <brad.king@kitware.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The -u option to override the remote system's path to git-upload-pack was
being ignored by "git clone"; caused by a missing call to
transport_set_option to set TRANS_OPT_UPLOADPACK. Presumably this crept in
when git-clone was converted from shell to C.
Signed-off-by: Steve Haslam <shaslam@lastminute.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile records paths to a few programs in GIT-BUILD-OPTIONS file. These
paths need to be quoted twice: once to protect specials from the shell
that runs the generated GIT-BUILD-OPTIONS file, and again to protect them
(and the first level of quoting itself) from the shell that runs the
"echo" inside the Makefile.
You can test this by trying:
$ ln -s /bin/tar "$HOME/Tes' program/tar"
$ make TAR="$HOME/Tes' program/tar" test
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The patch is twofold: it moves the option consistency checks just under
the parse_options call so that it doesn't get in the way of the tree
reference vs. pathspecs desambiguation.
The other part rewrites the way to understand arguments so that when
git-checkout fails it does with an understandable message. Compared to the
previous behavior we now have:
- a better error message when doing:
git checkout <blob reference> --
now complains about the reference not pointing to a tree, instead of
things like:
error: pathspec <blob reference> did not match any file(s) known to git.
error: pathspec '--' did not match any file(s) known to git.
- a better error message when doing:
git checkout <path> --
It now complains about <path> not being a reference instead of the
completely obscure:
error: pathspec '--' did not match any file(s) known to git.
- an error when -- wasn't used, and the first argument is ambiguous
(i.e. can be interpreted as both ref and as path).
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 46eb449c restricted git-filter-branch to non-bare repositories
unnecessarily; git-filter-branch can work on bare repositories just
fine.
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-am output can be confusing, because the subject of the applied
patch can look like the rest of a sentence starting with "Applying".
The added colon should make this clearer.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to set the TOPOSORT flag of commits during the topological
sorting, but we can just as well use the member "indegree" for it:
indegree is now incremented by 1 in the cases where the commit used
to have the TOPOSORT flag.
This is the same behavior as before, since indegree could not be
non-zero when TOPOSORT was unset.
Incidentally, this fixes the bug in show-branch where the 8th column
was not shown: show-branch sorts the commits in topological order,
assuming that all the commit flags are available for show-branch's
private matters.
But this was not true: TOPOSORT was identical to the flag corresponding
to the 8th ref. So the flags for the 8th column were unset by the
topological sorting.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some shells hang when parsing the script if the last statement is not
followed by a newline. So add one.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some shells have problems with one-shot environment variable export
and function calls. The sequence is rearranged to avoid the one-shot
and to allow the test script to be linked together with '&&'.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test only checked if the best result picking code works if there are
multiple strategies set in the config. Add a similar one that tests if
the same true if the -s option of git merge was used multiple times.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 3-way merge, "am" will let the index with unmerged path waiting
for us to resolve conflicts and continue. But if we want to --skip
instead, "am" refuses to continue because of the dirty index.
With this patch, "am" will clean the index without touching files
locally modified, before continuing.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git merge -s foobar' diagnosed invalid "foobar" strategy and errored out
with a message, but foobar in pull.twohead or pull.octopus was just
silently ignored. This makes invalid strategy both on the command line
and in the configuration file to trigger the same error.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some of our tests assumed a working "patch" command to produce expected
results when checking "git-apply", but some systems have broken "patch".
We can compare our output with expected output that is precomputed
instead to sidestep this issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
p->argc represent the number of arguments that have not been parsed yet,
_including_ the one we are currently parsing. If it is not greater than
one then there is no more argument.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Acked-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With git-am, it sounds awkward to have the patches in ".git/rebase/",
but for technical reasons, we have to keep the same directory name
for git-am and git-rebase. ".git/rebase-apply" seems to be a good
compromise.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git update-index --refresh", "git reset" and "git add --refresh" have
reported paths that have local modifications as "needs update" since the
beginning of git.
Although this is logically correct in that you need to update the index at
that path before you can commit that change, it is now becoming more and
more clear, especially with the continuous push for user friendliness
since 1.5.0 series, that the message is suboptimal. After all, the change
may be something the user might want to get rid of, and "updating" would
be absolutely a wrong thing to do if that is the case.
I prepared two alternatives to solve this. Both aim to reword the message
to more neutral "locally modified".
This patch is a more intrusive variant that changes the message for only
Porcelain commands ("add" and "reset") while keeping the plumbing
"update-index" intact.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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: Michele Ballabio <barra_cuda@katamail.com>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check that req_update shows refs, even if all refs are packed.
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5fdeacb (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: Junio C Hamano <gitster@pobox.com>
And here is a small test script that makes sure that:
- both modified and new files are included,
- removed file is noticed, and
- no ignored file is included.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After failing to apply patches in the middle of a series, "git am --abort"
lets you go back to the original commit.
[jc: doc/help update from Olivier, and fixups for "am -3" squashed in]
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio 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: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check that all branches are displayed.
Signed-off-by: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
Signed-off-by: Junio 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: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
Signed-off-by: Junio 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: Junio 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: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It used plain 'if git merge ...', which hides a segfault. The test does not pass.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio 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: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio 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: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit 8eca0b47ff, 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: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio 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: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio 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: João Abecasis <joao@abecasis.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio 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: Junio 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: Lukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Miklos Vajna