* maint:
Update draft release notes for 1.6.0.1
Add hints to revert documentation about other ways to undo changes
Install templates with the user and group of the installing personality
"git-merge": allow fast-forwarding in a stat-dirty tree
completion: find out supported merge strategies correctly
decorate: allow const objects to be decorated
for-each-ref: cope with tags with incomplete lines
diff --check: do not get confused by new blank lines in the middle
remote.c: remove useless if-before-free test
mailinfo: avoid violating strbuf assertion
git format-patch: avoid underrun when format.headers is empty or all NLs
We used to refresh the index to clear stat-dirtyness before a fast-forward
merge. Recent C rewrite forgot to do this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you have a tag with a single, incomplete line as its payload, asking
git-for-each-ref for its %(body) element accessed a NULL pointer.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code remembered that the last diff output it saw was an empty line,
and tried to reset that state whenever it sees a context line, a non-blank
new line, or a new hunk. However, this codepath asks the underlying diff
engine to feed diff without any context, and the "just saw an empty line"
state was not reset if you added a new blank line in the last hunk of your
patch, even if it is not the last line of the file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* dp/hash-literally:
add --no-filters option to git hash-object
add --path option to git hash-object
use parse_options() in git hash-object
correct usage help string for git-hash-object
correct argument checking test for git hash-object
teach index_fd to work with pipes
In handle_from, we calculate the end boundary of a section
to remove from a strbuf using strcspn like this:
el = strcspn(buf, set_of_end_boundaries);
strbuf_remove(&sb, start, el + 1);
This works fine if "el" is the offset of the boundary
character, meaning we remove up to and including that
character. But if the end boundary didn't match (that is, we
hit the end of the string as the boundary instead) then we
want just "el". Asking for "el+1" caught an out-of-bounds
assertion in the strbuf library.
This manifested itself when we got a 'From' header that had
just an email address with nothing else in it (the end of
the string was the end of the address, rather than, e.g., a
trailing '>' character), causing git-mailinfo to barf.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
GNU diff's --suppress-blank-empty option makes it so that diff no
longer outputs trailing white space unless the input data has it.
With this option, empty context lines are now empty also in diff -u output.
Before, they would have a single trailing space.
* diff.c (diff_suppress_blank_empty): New global.
(git_diff_basic_config): Set it.
(fn_out_consume): Honor it.
* t/t4029-diff-trailing-space.sh: New file.
* Documentation/config.txt: Document it.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some old platforms have an old diff which doesn't have the -U option.
'git diff' can be used in its place. Adjust the comparison function to
strip git's additional header lines to make this possible.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current .gitignore only ignores the old "trash directory" and
not the new "trash directory.[test]". This ignores both forms.
Signed-off-by: Marcus Griep <marcus@griep.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent changes to is_multipart_boundary() caused git-mailinfo to segfault.
The reason was after handling the end of the boundary the code tried to look
for another boundary. Because the boundary list was empty, dereferencing
the pointer to the top of the boundary caused the program to go boom.
The fix is to check to see if the list is empty and if so go on its merry
way instead of looking for another boundary.
I also fixed a couple of increments and decrements that didn't look correct
relating to content_top.
The boundary test case was updated to catch future problems like this again.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adds the total pack size (including indexes) the verbose count-objects
output, floored to the nearest kilobyte.
Updates documentation to match this addition.
Signed-off-by: Marcus Griep <marcus@griep.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many test scripts assumed that they will start in a 'trash' subdirectory
that is a single level down from the t/ directory, and referred to their
test vector files by asking for files like "../t9999/expect". This will
break if we move the 'trash' subdirectory elsewhere.
To solve this, we earlier introduced "$TEST_DIRECTORY" so that they can
refer to t/ directory reliably. This finally makes all the tests use
it to refer to the outside environment.
With this patch, and a one-liner not included here (because it would
contradict with what Dscho really wants to do):
| diff --git a/t/test-lib.sh b/t/test-lib.sh
| index 70ea7e0..60e69e4 100644
| --- a/t/test-lib.sh
| +++ b/t/test-lib.sh
| @@ -485,7 +485,7 @@ fi
| . ../GIT-BUILD-OPTIONS
|
| # Test repository
| -test="trash directory"
| +test="trash directory/another level/yet another"
| rm -fr "$test" || {
| trap - exit
| echo >&5 "FATAL: Cannot prepare test area"
all the tests still pass, but we would want extra sets of eyeballs on this
type of change to really make sure.
[jc: with help from Stephan Beyer on http-push tests I do not run myself;
credits for locating silly quoting errors go to Olivier Marin.]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-apply documentation says that --binary is a historical option.
This patch lets git-am ignore --binary and removes advertisements of this
option.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use square brackets instead.
And the prominent example of the deficiency are, as usual, the filesystems
of Microsoft house.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-chmtime can adjust the mtime of a file based on the file's mtime, or
based on the system time. For files accessed over NFS, the file's mtime is
set by the NFS server, and as such may vary a great deal from the NFS
client's system time if the clocks of the client and server are out of
sync. Since these tests are testing the expire feature of git-prune, an
incorrect mtime could cause a file to be expired or not expired incorrectly
and produce a test failure.
Avoid this NFS pitfall by modifying the calls to test-chmtime so that the
mtime is adjusted based on the system time, rather than the file's mtime.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
match_one implements an optimized pathspec match where it only uses
fnmatch if it detects glob special characters in the pattern. Unfortunately
it didn't treat \ as a special character, so attempts to escape a glob
special character would fail even though fnmatch() supports it.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing parent rewriting did not handle the case where a previous
commit was amended (via edit or squash). Fix by always putting the
new sha1 of the last commit into the $REWRITTEN map.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
'git rebase -i -p' forgot to update the index and working directory
during fast forwards. Fix this. Makes 'GIT_EDITOR=true rebase -i -p
<ancestor>' a no-op again.
Also, it attempted to do a fast forward even if it was instructed not
to commit (via -n). Fall back to the cherry-pick code path and let
that handle the issue for us.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
The previous ancestor discovery code failed on any refs that are
(pre-rewrite) ancestors of commits marked for rewriting. This means
that in a situation
A -- B(topic) -- C(master)
where B is dropped by --subdirectory-filter pruning, the 'topic' was
not moved up to A as intended, but left unrewritten because we asked
about 'git rev-list ^master topic', which does not return anything.
Instead, we use the straightforward
git rev-list -1 $ref -- $filter_subdir
to find the right ancestor. To justify this, note that the nearest
ancestor is unique: We use the output of
git rev-list --parents -- $filter_subdir
to rewrite commits in the first pass, before any ref rewriting. If B
is a non-merge commit, the only candidate is its parent. If it is a
merge, there are two cases:
- All sides of the merge bring the same subdirectory contents. Then
rev-list already pruned away the merge in favour for just one of its
parents, so there is only one candidate.
- Some merge sides, or the merge outcome, differ. Then the merge is
not pruned and can be rewritten directly.
So it is always safe to use rev-list -1.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This extends the --subdirectory-filter test in t7003 to demonstrate a
rewriting bug: when rewriting two refs A and B such that B is an
ancestor of A, it fails to rewrite B.
The underlying issue is that the rev-list invocation at
git-filter-branch.sh:332 more or less boils down to
git rev-list B --boundary ^A
which outputs nothing because B is an ancestor of A.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we are building a thin pack and one of the base objects we would
consider for deltification is missing its OK, the other side already
has that base object. We may be able to get a delta from another
object, or we can simply send the new object whole (no delta).
This change allows a shallow clone to store only the objects which
are unique to it, as well as the boundary commit and its trees, but
avoids storing the boundary blobs. This special form of a shallow
clone is able to represent just the difference between two trees.
Pack objects change suggested by Nicolas Pitre.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recently "git diff --check" learned to detect new trailing blank lines
just like "git apply --whitespace" does. However this check should not
trigger unconditionally. This patch makes it honor the whitespace
settings from core.whitespace and gitattributes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The post-update hook, which is required to be enabled in order for
the repository to be accessible over HTTP, is not enabled by
chmod a+x anymore, but instead by dropping the .sample suffix.
This patch emphasizes this change in the release notes (since
I believe this is rather noticeable backwards-incompatible change).
It also adjusts the documentation which still described the old way
and fixes t/t5540-http-push.sh, which was broken for 1.5 month
but apparently noone ever runs this test.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cherry-picking can be helped by reusing previous confliction
resolution by invoking rerere automatically.
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
What does the user most likely want with this command?
$ git checkout --track origin/next
Exactly. A branch called 'next', that tracks origin's branch 'next'.
Make it so.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Documentation: fix invalid reference to 'mybranch' in user manual
Fix deleting reflog entries from HEAD reflog
reflog test: add more tests for 'reflog delete'
Documentation: rev-list-options: Fix -g paragraph formatting
Conflicts:
Documentation/user-manual.txt
dwim_ref() used to resolve HEAD symbolic ref to its target (i.e. current
branch). This incorrectly removed the reflog entry from the current
branch when 'git reflog delete HEAD@{1}' was asked for.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds more tests for 'reflog delete' and marks it as
broken, as currently a call to 'git reflog delete HEAD@{1}'
deletes entries in the currently checked out branch's log,
not the HEAD log.
Noticed by John Wiegley
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After finding a MIME multi-part message boundary line, the handle_body()
function is supposed to first flush any accumulated contents from the
previous part to the output stream. However, the code mistakenly output
the boundary line it found.
The old code that used one global, fixed-length buffer line[] used an
alternate static buffer newline[] for keeping track of this accumulated
contents and flushed newline[] upon seeing the boundary; when 3b6121f
(git-mailinfo: use strbuf's instead of fixed buffers, 2008-07-13)
converted a fixed-length buffer in this program to use strbuf,these two
buffers were converted to "line" and "prev" (the latter of which now has a
much more sensible name) strbufs, but the code mistakenly flushed "line"
(which contains the boundary we have just found), instead of "prev".
This resulted in the first boundary to be output in front of the first
line of the message.
The rewritten implementation of handle_boundary() lost the terminating
newline; this would then result in the second line of the message to be
stuck with the first line.
The is_multipart_boundary() was designed to catch both the internal
boundary and the terminating one (the one with trailing "--"); this also
was broken with the rewrite, and the code in the handle_boundary() to
handle the terminating boundary was never triggered.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On multiprocessor machines, or with I/O heavy tests (that leave the
CPU waiting a lot), it makes sense to parallelize the tests.
However, care has to be taken that the different jobs use different
trash directories.
This commit does so, by creating the trash directories with a suffix
that is unique with regard to the test, as it is the test's base name.
Further, the trash directory is removed in the test itself if
everything went fine, so that the trash directories do not
pile up only to be removed at the very end.
If a test failed, the trash directory is not removed. Chances are
that the exact error message is lost in the clutter, but you can still
see what test failed from the name of the trash directory, and repeat
the test (without -j).
If all was good, you will see the aggregated results.
Suggestions to simplify this commit came from Junio and René.
There still is an issue with tests that want to run a server process and
listen to a fixed port (http and svn) --- they cannot run in parallel but
this patch does not address this issue.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The Makefile targets 'aggregate-results' and 'clean' pretended to be
independent. This is not true, of course, since aggregate-results
needs the results _before_ they are removed.
Likewise, the tests should have been run already when the results are
to be aggregated.
However, as it is legitimate to run only a few tests, and then aggregate
just those results, so another target is introduced, that depends on all
tests, then aggregates the results, and only then removes the results.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t9700 used to check if the basename of the current directory is
'trash directory', the expensive way.
However, there is absolutely no good reason why this test should not
run in, say 'life is good' or 'i love tests'. So remove the check
altogether.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some repositories use a deep branching strategy, such as:
branches/1.0/1.0.rc1
branches/1.0/1.0.rc2
branches/1.0/1.0.rtm
branches/1.0/1.0.gold
Only allowing a single glob stiffles this.
This change allows for a single glob 'set' to accept this deep
branching strategy.
The ref glob depth must match the branch glob depth. When using
the -b or -t options for init or clone, this is automatically
done.
For example, using the above branches:
svn-remote.svn.branches = branches/*/*:refs/remote/*/*
gives the following branch names:
1.0/1.0.rc1
1.0/1.0.rc2
1.0/1.0.rtm
1.0/1.0.gold
[ew:
* removed unrelated line-wrapping changes
* fixed line-wrapping in a few more places
* removed trailing whitespace
* fixed bashism in test
* removed unnecessary httpd startup in test
* changed copyright on tests to 2008 Marcus Griep
* added executable permissions to new tests
]
Signed-off-by: Marcus Griep <marcus@griep.us>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fixes bad regex match check for multiple globs (would always return
one glob regardless of actual number).
[ew: fixed a bashism in the test and some minor line-wrapping]
Signed-off-by: Marcus Griep <marcus@griep.us>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With --mirror, clone asks for refs/* already, so it does not need to
ask for ref/tags/*, too.
Noticed by Cesar Eduardo Barros.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running "git commit -F file" and "git tag -F file" from a
subdirectory, we should take it as relative to the directory we started
from, not relative to the top-level directory.
This adds a helper function "parse_options_fix_filename()" to make it more
convenient to fix this class of issues. Ideally, parse_options() should
support a new type of option, "OPT_FILENAME", to do this uniformly, but
this patch is meant to go to 'maint' to fix it minimally.
One thing to note is that value for "commit template file" that comes from
the command line is taken as relative to $cwd just like other parameters,
but when it comes from the configuration varilable 'commit.template', it
is taken as relative to the working tree root as before. I think this
difference actually is sensible (not that I particularly think
commit.template itself is sensible).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I've tested this with svn 1.4.4
This also adds quoting to make it work odd characters
in the trash path.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Changed the ptouch bash function to use the "Text Last Updated"
date reported by 'svn info' when changing the modified time
(mtime) of the file/symlink/directory in the git working
directory. Previously it used the mtime of the item in the
svn working directory, which caused the race condition.
[ew: swapped argument order of ptouch() to minimize diff]
From: David D. Kilzer <ddkilzer@kilzer.net>
Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is the same fix for the issue of adding "sym/path" when "sym" is a
symblic link that points at a directory "dir" with "path" in it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "sym" is a symbolic link that is inside the working tree, and it
points at a directory "dir" that has "path" in it, "update-index --add
sym/path" used to mistakenly add "sym/path" as if "sym" were a normal
directory.
"git apply", "git diff" and "git merge" have been taught about this issue
some time ago, but "update-index" and "add" have been left ignorant for
too long.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tests requires anonymous write access. Therefore, "anon-access =
write" is added to conf/svnserve.conf. But because it was added to
the end of the file, it is impossible to guarantee in what section
it will be located. It turned out that on SVN 1.5, it was placed in
the wrong section and as result the test failed.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Tested-by: Brad King <brad.king@kitware.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This prevents double output in case stdout is redirected.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes the algorithm more honest about what it is doing.
We start from an already limited, topo-sorted list, and postprocess
it by simplifying the irrelevant merges away.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have a tradition that bare repositories live in directories ending
in ".git". To make this more a convention than just a tradition, teach
"git clone --bare" to add a ".git" suffix to the directory name.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new option allows the contents to be hashed as is, ignoring any input
filter that would have been chosen by the attributes mechanism.
This option is incompatible with --path and --stdin-paths options.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --path option allows us to pretend as if the contents being hashed
came from the specified path, and affects which input filter is used via
the attributes mechanism. This is useful for hashing a temporary file
whose name is different from the path that is meant to have the hashed
contents.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because the file name given to stdin did not exist, git hash-object
fails to open it and exits with non-zero error code.
Thus the test may pass even if there is an error in argument checking.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command line
$ git clone --mirror $URL
is now a short-hand for
$ git clone --bare $URL
$ (cd $(basename $URL) && git remote add --mirror origin $URL)
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>
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>
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>
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>
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>
We recently let the user know explicitly that an empty
commit message will abort the commit. However, this adds yet
another line to the template; let's rephrase and re-wrap so
that this fits back on two lines.
This patch also makes the "fatal: empty commit message?"
warning a bit less scary, since this is now a "feature"
instead of an error. However, we retain the non-zero exit
status to indicate to callers that nothing was committed.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
OPT_INTEGER() works on an integer, not on an unsigned long. On a big
endian architecture with long larger than int, integer test gives bogus
results because of this bug.
Reported by H.Merijn Brand in HP-UX 64-bit environment.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This treats aborting a commit more like a feature.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although it does not matter for Git itself, tools that
export to systems that explicitly track copies and
renames can benefit from such information.
This patch makes fast-export output correct action
logs when -M or -C are enabled.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This one tests '-s index' which is interesting because git-merge-index
is an existing git command but it is not a valid strategy.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
This patch makes two small changes to improve the output of --inline
and --attach.
The first is to write a newline preceding the boundary. This is needed because
MIME defines the encapsulation boundary as including the preceding CRLF (or in
this case, just LF), so we should be writing one. Without this, the last
newline in the pre-diff content is consumed instead.
The second change is to always write the line termination character
(default: newline) even when using --inline or --attach. This is simply to
improve the aesthetics of the resulting message. When using --inline an email
client should render the resulting message identically to the non-inline
version. And when using --attach this adds a blank line preceding the
attachment in the email, which is visually attractive.
Signed-off-by: Kevin Ballard <kevin@sb.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>
* maint:
GIT 1.5.6.4
builtin-rm: fix index lock file path
http-fetch: do not SEGV after fetching a bad pack idx file
rev-list: honor --quiet option
api-run-command.txt: typofix
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>
* mv/dashless:
make remove-dashes: apply to scripts and programs as well, not just to builtins
git-bisect: use dash-less form on git bisect log
t1007-hash-object.sh: use quotes for the test description
t0001-init.sh: change confusing directory name
* sb/dashless:
Make usage strings dash-less
t/: Use "test_must_fail git" instead of "! git"
t/test-lib.sh: exit with small negagive int is ok with test_must_fail
Conflicts:
builtin-blame.c
builtin-mailinfo.c
builtin-mailsplit.c
builtin-shortlog.c
git-am.sh
t/t4150-am.sh
t/t4200-rerere.sh
* maint:
Start preparing 1.5.6.4 release notes
git fetch-pack: do not complain about "no common commits" in an empty repo
rebase-i: keep old parents when preserving merges
t7600-merge: Use test_expect_failure to test option parsing
Fix buffer overflow in prepare_attr_stack
Fix buffer overflow in git diff
Fix buffer overflow in git-grep
git-cvsserver: fix call to nonexistant cleanupWorkDir()
Documentation/git-cherry-pick.txt et al.: Fix misleading -n description
Conflicts:
RelNotes
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>
* mv/merge-in-c:
reduce_heads(): protect from duplicate input
reduce_heads(): thinkofix
Add a new test for git-merge-resolve
t6021: add a new test for git-merge-resolve
Teach merge.log to "git-merge" again
Build in merge
Fix t7601-merge-pull-config.sh on AIX
git-commit-tree: make it usable from other builtins
Add new test case to ensure git-merge prepends the custom merge message
Add new test case to ensure git-merge reduces octopus parents when possible
Introduce reduce_heads()
Introduce get_merge_bases_many()
Add new test to ensure git-merge handles more than 25 refs.
Introduce get_octopus_merge_bases() in commit.c
git-fmt-merge-msg: make it usable from other builtins
Move read_cache_unmerged() to read-cache.c
Add new test to ensure git-merge handles pull.twohead and pull.octopus
Move parse-options's skip_prefix() to git-compat-util.h
Move commit_list_count() to commit.c
Move split_cmdline() to alias.c
Conflicts:
Makefile
parse-options.c
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>
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: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
GIT 1.5.6.3
git-am: Do not exit silently if committer is unset
t0004: fix timing bug
git-mailinfo: document the -n option
Fix backwards-incompatible handling of core.sharedRepository
* jc/report-tracking:
branch -r -v: do not spit out garbage
stat_tracking_info(): clear object flags used during counting
git-branch -v: show the remote tracking statistics
git-status: show the remote tracking statistics
Refactor "tracking statistics" code used by "git checkout"
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: Junio 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: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio 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: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio 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: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio 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: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio 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: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio 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: Junio C Hamano <gitster@pobox.com>
using git-init as directory name confused 'make remove-dashes', so just
drop the 'git-' prefix.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
06cbe85 (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: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio 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: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
7ebd52a (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: Junio C Hamano <gitster@pobox.com>
* js/apply-root:
git-apply --directory: make --root more similar to GNU diff
apply --root: thinkofix.
Teach "git apply" to prepend a prefix with "--root=<root>"
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: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio 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: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Start preparing release notes for 1.5.6.3
git-submodule - Fix bugs in adding an existing repo as a module
bash: offer only paths after '--'
Remove unnecessary pack-*.keep file after successful git-clone
make deleting a missing ref more quiet
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: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio 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: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio 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: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio 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: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unpacked objects should receive the timestamp of the pack they were
unpacked from. Check.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Once a clone is successful we no longer need to hold onto the
.keep file created by the transport. Delete the file so we
can later repack the complete repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the user specifies a ref by a reflog entry older than
one we have (e.g., "HEAD@{20 years ago"}), we issue a
warning and give them the "from" value of the oldest reflog
entry. That is, we say "we don't know what happened before
this entry, but before this we know we had some particular
SHA1".
However, the oldest reflog entry is often a creation event
such as clone or branch creation. In this case, the entry
claims that the ref went from "00000..." (the null sha1) to
the new value, and the reflog lookup returns the null sha1.
While this is technically correct (the entry tells us that
the ref didn't exist at the specified time) it is not
terribly useful to the end user. What they probably want
instead is "the oldest useful sha1 that this ref ever had".
This patch changes the behavior such that if the oldest ref
would return the null sha1, it instead returns the first
value the ref ever had.
We never discovered this problem in the test scripts because
we created "fake" reflogs that had only a specified segment
of history. This patch updates the tests with a creation
event at the beginning of history.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If git attempts to delete a ref, but the unlink of the ref
file fails, we print a message to stderr. This is usually a
good thing, but if the error is ENOENT, then it indicates
that the ref has _already_ been deleted. And since that's
our goal, it doesn't make sense to complain to the user.
This harmonizes the error reporting behavior for the
unpacked and packed cases; the packed case already printed
nothing on ENOENT, but the unpacked printed unconditionally.
Additionally, send-pack would, when deleting the tracking
ref corresponding to a remote delete, print "Failed to
delete" on any failure. This can be a misleading
message, since we actually _did_ delete at the remote side,
but we failed to delete locally. Rather than make the
message more precise, let's just eliminate it entirely; the
delete_ref routine already takes care of printing out a much
more specific message about what went wrong.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A root commit couldn't be cherry-picked. But its semantics can be
defined as simply merging two trees by overlaying disjoint parts
and merging overlapping files without any common ancestor. You
should be able to rebase originally independent branches on top of
another branch by using this.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* dr/ceiling:
Eliminate an unnecessary chdir("..")
Add support for GIT_CEILING_DIRECTORIES
Fold test-absolute-path into test-path-utils
Implement normalize_absolute_path
Conflicts:
cache.h
setup.c
Make sure that applying the stash to a new branch after a conflicting
change doesn't result in an error when you try to commit.
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Applying a patch in the directory that is different from what the patch
records is done with --directory option in GNU diff. The --root option we
introduced previously does the same, and we can call it the same way to
give users more familiar feel.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test failed on AIX (and likely other OS, such as apparently OSX)
where wc -l outputs whitespace.
Also, avoid unnecessary eval in conflict_count().
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There was no test for this before, so the testsuite passed, even in case
the merge summary was missing from the merge commit message.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a patch modifies the last line of a file that previously had no
terminating '\n', it looks like
-old text
\ No newline at end of file
+new text
Hence, a '\' line does not signal the end of the hunk. This modifies
'git apply --recount' to take this into account.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When left-right traversal counts the commits in a diverged history, it
leaves the flags in the commits smudged, and we need to clear them before
we return. Otherwise the caller cannot inspect other branches with this
function again.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we match a lightweight (non-annotated tag) as the name to
output and --long was requested we do not have a tag, nor do
we have a tagged object to display. Instead we must use the
object we were passed as input for the long format display.
Reported-by: Mark Burton <markb@ordern.com>
Backtraced-by: Mikael Magnusson <mikachu@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adds a new option 'e' to the 'add -p' command loop that lets you edit
the current hunk in your favourite editor.
If the resulting patch applies cleanly, the edited hunk will
immediately be marked for staging. If it does not apply cleanly, you
will be given an opportunity to edit again. If all lines of the hunk
are removed, then the edit is aborted and the hunk is left unchanged.
Applying the changed hunk(s) relies on Johannes Schindelin's new
--recount option for git-apply.
Note that the "real patch" test intentionally uses
(echo e; echo n; echo d) | git add -p
even though the 'n' and 'd' are superfluous at first sight. They
serve to get out of the interaction loop if git add -p wrongly
concludes the patch does not apply.
Many thanks to Jeff King <peff@peff.net> for lots of help and
suggestions.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The end of a string is string[length-1], not string[length+1].
I pointed it out during the review, but I forgot about it when applying the
patch. This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With "git apply --root=<root>", all file names in the patch are prepended
with <root>. If a "-p" value was given, the paths are stripped _before_
prepending <root>.
Wished for by HPA.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/checkdiff:
Fix t4017-diff-retval for white-space from wc
Update sample pre-commit hook to use "diff --check"
diff --check: detect leftover conflict markers
Teach "diff --check" about new blank lines at end
checkdiff: pass diff_options to the callback
check_and_emit_line(): rename and refactor
diff --check: explain why we do not care whether old side is binary
The old shell version used show-branch --independent to filter for the
ones that cannot be reached from any other reference.
The new C version uses reduce_heads() from commit.c for this, so
add test to ensure it works as expected.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old shell version handled only 25 refs but we no longer have this
limitation. Add a test to make sure this limitation will not be
introduced again in the future.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test if the given strategies are used and test the case when multiple
strategies are configured using a space separated list.
Also test if the best strategy is picked if none is specified. This is
done by adding a simple test case where recursive detects a rename, but
resolve does not, and verify that finally merge will pick up the
previous.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We don't need test results to be committed if we're fixing a test.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sometimes, the easiest way to fix up a patch is to edit it directly, even
adding or deleting lines. Now, many people are not as divine as certain
benevolent dictators as to update the hunk headers correctly at the first
try.
So teach the tool to do it for us.
[jc: with tests]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When working with a lot of people who backport patches all day long, every
once in a while I get a patch that modifies the same file more than once
inside the same patch. git-apply either fails if the second change relies
on the first change or silently drops the first change if the second change
is independent.
The silent part is the scary scenario for us. Also this behaviour is
different from the patch-utils.
I have modified git-apply to create a table of the filenames of files it
modifies such that if a later patch chunk modifies a file in the table it
will buffer the previously changed file instead of reading the original file
from disk.
Logic has been put in to handle creations/deletions/renames/copies. All the
relevant tests of git-apply succeed.
A new test has been added to cover the cases I addressed.
The fix is relatively straight-forward.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches "diff --check" to detect and complain if the change
adds lines that look like leftover conflict markers.
We should be able to remove the old Perl script used in the sample
pre-commit hook and modernize the script with this facility.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a patch adds new blank lines at the end, "git apply --whitespace"
warns. This teaches "diff --check" to do the same.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff --check" should return non-zero when there was any whitespace
error but the code only paid attention to the error status of the last
new line in the patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, we did a sanity check by doing for-each-ref
using each possible format atom. However, we never checked
the actual output produced by that atom, which recently let
an obvious bug go undetected for some time.
While we're at it, also clean up a few '!' into
test_must_fail.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
