* cb/maint-merge-recursive-fix:
merge-recursive: do not clobber untracked working tree garbage
modify/delete conflict resolution overwrites untracked file
When merge-recursive wanted to create a new file in the work tree (either
as the final result, or a hint for reference purposes while delete/modify
conflicts), it unconditionally overwrote an untracked file in the working
tree. Be careful not to lose whatever the user has that is not tracked.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a file was removed in HEAD, but modified in MERGE_HEAD, recursive merge
will result in a "CONFLICT (delete/modify)". If the (now untracked) file
already exists and was not added to the index, it is overwritten with the
conflict resolution contents.
In similar situations (cf. test 2), the merge would abort with
"error: Untracked working tree 'file' would be overwritten by merge."
The same should happen in this case.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In dc871831(Only use GIT_CONFIG in "git config", not other programs),
GIT_CONFIG_LOCAL was rested in peace, in favor of not reading
/etc/gitconfig and $HOME/.gitconfig at all when GIT_CONFIG is set.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now git gui has a customizable Tools menu, so this adds
information about variables that are used to configure it.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Internal "allocate in bulk, we will never free this memory anyway"
allocator used in fast-import had a logic to round up the size of the
requested memory block in a wrong place (it computed if the available
space is enough to fit the request first, and then carved a chunk of
memory by size rounded up to the alignment, which could go beyond the
actually available space).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-commit uses commit_tree() from builtin-commit-tree since
6bb6b03 (builtin-commit: use commit_tree(), 2008-09-10), where the
same message is used.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it easier to recover from a mistaken branch deletion by displaying the
sha1 of the branch's tip commit.
Update t3200 test to match the change in output.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The logic to mark all objects that are reachable from tips of refs were
implemented as a set of recursive functions. In a repository with a deep
enough history, this can easily eat up all the available stack space.
Restructure the code to require less stackspace by using an object array
to keep track of the objects that still need to be processed.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you have unstaged changes in your working tree and try to
rebase, you will get the cryptic "foo: needs update"
message, but nothing else. If you have staged changes, you
get "your index is not up-to-date".
Let's improve this situation in two ways:
- for unstaged changes, let's also tell them we are
canceling the rebase, and why (in addition to the "needs
update" lines)
- for the staged changes case, let's use language that is a
little more clear to the user: their index contains
uncommitted changes
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Especially on Windows where an opened file cannot be replaced, make
sure pack-objects always close packs it is about to replace. Even on
non Windows systems, this could save potential bad results if ever
objects were to be read from the new pack file using offset from the old
index.
This should fix t5303 on Windows.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Tested-by: Johannes Sixt <j6t@kdbg.org> (MinGW)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reported-by: Tim Daly <daly@axiom-developer.org>
Signed-off-by: Alexander Potashev <aspotashev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When I tweaked the patch to use $SHELL_PATH instead of a hard-coded
"#!/bin/sh" to produce 3aa1f7c (diff: respect textconv in rewrite diffs,
2008-12-09), I screwed up. This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently we just skip rewrite diffs for binary files; this
patch makes an exception for files which will be textconv'd,
and actually performs the textconv before generating the
diff.
Conceptually, rewrite diffs should be in the exact same
format as the a non-rewrite diff, except that we refuse to
share any context. Thus it makes very little sense for "git
diff" to show a textconv'd diff, but for "git diff -B" to
show "Binary files differ".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current emit_rewrite_diff code always writes a text patch without
checking whether the content is binary. This means that if you end up with
a rewrite diff for a binary file, you get lots of raw binary goo in your
patch.
Instead, if we have binary files, then let's just skip emit_rewrite_diff
altogether. We will already have shown the "dissimilarity index" line, so
it is really about the diff contents. If binary diffs are turned off, the
"Binary files a/file and b/file differ" message should be the same in
either case. If we do have binary patches turned on, there isn't much
point in making a less-efficient binary patch that does a total rewrite;
no human is going to read it, and since binary patches don't apply with
any fuzz anyway, the result of application should be the same.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unfortunately, I introduced a bug in commit 7f705dc36 (git-p4: Fix bug in
p4Where method). This happens because sometimes the result from
"p4 where <somepath>" doesn't contain a "depotFile" key, but instead a
"data" key that needs further parsing. This commit should ensure that both
of these cases are checked.
Signed-off-by: Tor Arvid Lund <torarvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Improve some minor language and format issues like hyphenation,
phrases, spacing, word order, comma, attributes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It appears that a reference to an anchor defined as [[anchor-name]] from
another place using <<anchor-name>> syntax, when the anchor name contains
a string "-with-" in its name, triggers these warnings from Python
interpreter.
asciidoc -b docbook -d book user-manual.txt
<string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
<string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
<string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
<string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
There currently is no reference to "Finding comments with given content",
but for consistency and for futureproofing, the anchor is also updated as
the other ones that are actually used and trigger these warnings.
Signed-off-by: Junio C Hamano <junio@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Starting with asciidoc 8.3.0 linkgit macro is no longer recognized by
asciidoc and user guide suggests
(http://www.methods.co.nz/asciidoc/userguide.html#_macro_definitions)
that macros are supposed to be defined in [macros] section. I'm not
sure whether undefined linkgit macro was working by pure chance or it
is a regression in asciidoc 8.3.0, but this patch adds proper
definition for the linkgit macro, allowing it to work on 8.3.0.
Signed-off-by: Alexey Borzenkov <snaury@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
find_parent_branch generates branch@rev type branches when one has to
look back through SVN history to properly get the history for a branch
copied from somewhere not already being tracked by git-svn. If in the
process of fetching this history, git-svn is interrupted, then when one
fetches again, it will use whatever was last fetched as the parent
commit and fail to fetch any more history which it didn't get to before
being terminated. This is especially troubling in that different
git-svn copies of the same SVN repository can end up with different
commit sha1s, incorrectly showing the history as divergent and
precluding easy collaboration using git push and fetch.
To fix this, when we initialise the Git::SVN object $gs to search for
and perhaps fetch history, we check if there are any commits in SVN in
the range between the current revision $gs is at, and the top revision
for which we were asked to fill history. If there are commits we're
missing in that range, we continue the fetch from the current revision
to the top, properly getting all history before using it as the parent
for the branch we're trying to create.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In insert_file() subroutine (which is used to insert HTML fragments as
custom header, footer, hometext (for projects list view), and per
project README.html (for summary view)) we used:
map(to_utf8, <$fd>);
This doesn't work, and other form has to be used:
map { to_utf8($_) } <$fd>;
Now with test for t9600 added, for $GIT_DIR/README.html.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some history viewers use the diff plumbing to generate diffs
rather than going through the "git diff" porcelain.
Currently, there is no way for them to specify that they
would like to see the text-converted version of the diff.
This patch adds a "--textconv" option to allow such a
plumbing user to allow text conversion. The user can then
tell the viewer whether or not they would like text
conversion enabled.
While it may be tempting add a configuration option rather
than requiring each plumbing user to be configured to pass
--textconv, that is somewhat dangerous. Text-converted diffs
generally cannot be applied directly, so each plumbing user
should "opt in" to generating such a diff, either by
explicit request of the user or by confirming that their
output will not be fed to patch.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Right now for the diff porcelain and the log family, we
call:
init_revisions();
setup_revisions();
DIFF_OPT_SET(ALLOW_TEXTCONV);
However, that means textconv will _always_ be on, instead of
being a default that can be manipulated with
setup_revisions. Instead, we want:
init_revisions();
DIFF_OPT_SET(ALLOW_TEXTCONV);
setup_revisions();
which is what this patch does.
We'll go ahead and move the callsite in wt-status, also;
even though the user can't pass any options here, it is a
cleanup that will help avoid any surprise later if the
setup_revisions line is changed.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A handful of fixes have been backmerged to 'maint' and are now contained
in 1.6.0.X series as the result, so drop them from this document.
Also contains typofix and duplicate removal pointed out by
Bjørn Lindeijer and Jakub Narebski.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
GIT 1.6.0.5
"git diff <tree>{3,}": do not reverse order of arguments
tag: delete TAG_EDITMSG only on successful tag
gitweb: Make project specific override for 'grep' feature work
http.c: use 'git_config_string' to get 'curl_http_proxy'
fetch-pack: Avoid memcpy() with src==dst
According to the message of commit 0fe7c1de16,
"git diff" with three or more trees expects the merged tree first followed by
the parents, in order. However, this command reversed the order of its
arguments, resulting in confusing diffs. A comment /* Again, the revs are all
reverse */ suggested there was a reason for this, but I can't figure out the
reason, so I removed the reversal of the arguments. Test case included.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The user may put some effort into writing an annotated tag
message. When the tagging process later fails (which can
happen fairly easily, since it may be dependent on gpg being
correctly configured and used), there is no record left on
disk of the tag message.
Instead, let's keep the TAG_EDITMSG file around until we are
sure the tag has been created successfully. If we die
because of an error, the user can recover their text from
that file. Leaving the file in place causes no conflicts;
it will be silently overwritten by the next annotated tag
creation.
This matches the behavior of COMMIT_EDITMSG, which stays
around in case of error.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'grep' feature was marked in the comments as having project
specific config, but it lacked 'sub' key required for it to work.
Kind-of-Noticed-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
memcpy() may only be used for disjoint memory areas, but when invoked
from cmd_fetch_pack(), we have my_args == &args. (The argument cannot
be removed entirely because transport.c invokes with its own
variable.)
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/am-options:
git-am: rename apply_opt_extra file to apply-opt
Test that git-am does not lose -C/-p/--whitespace options
git-am: propagate --3way options as well
git-am: propagate -C<n>, -p<n> options as well
git-am --whitespace: do not lose the command line option
All other state files use dash in their names, not underscores.
Also, there is no reason to call this "extra". Drop it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These tests make sure that "git am" does not lose command line options
specified when it was started, after it is interrupted by a patch that
does not apply earlier in the series.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The reasoning is the same as the previous patch, where we made -C<n>
and -p<n> propagate across a failure.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These options are meant to deal with patches that do not apply cleanly
due to the differences between the version the patch was based on and
the version "git am" is working on.
Because a series of patches applied in the same "git am" run tends to
come from the same source, it is more useful to propagate these options
after the application stops.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you start "git am --whitespace=fix" and the patch application process
is interrupted by an unapplicable patch early in the series, after
fixing the offending patch, the remainder of the patch should be processed
still with --whitespace=fix when restarted with "git am --resolved" (or
dropping the offending patch with "git am --skip").
The breakage was introduced by the commit 67dad68 (add -C[NUM] to git-am,
2007-02-08); this should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running:
p4 where //depot/SomePath/...
The result can in some situations look like:
//depot/SomePath/... //client/SomePath/... /home/user/p4root/SomePath/...
-//depot/SomePath/UndesiredSubdir/... //client/SomePath/UndesiredSubdir/... /home/user/p4root/SomePath/UndesiredSubdir/...
This depends on the users Client view. The current p4Where method will now
return /home/user/p4root/SomePath/UndesiredSubdir/... which is not what we
want. This patch loops through the results from "p4 where", and picks the one
where the depotFile exactly matches the given depotPath (//depot/SomePath/...
in this example).
Signed-off-by: Tor Arvid Lund <torarvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
