CE_WT_REMOVE has already grabbed the same value.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Commit 9e8eceab (Add 'merge' mode to 'git reset', 2008-12-01) disallowed
"git reset --merge" when there was unmerged entries.  But it wished if
unmerged entries were reset as if --hard (instead of --merge) has been
used.  This makes sense because all "mergy" operations makes sure that
any path involved in the merge does not have local modifications before
starting, so resetting such a path away won't lose any information.

The previous commit changed the behavior of --merge to accept resetting
unmerged entries if they are reset to a different state than HEAD, but it
did not reset the changes in the work tree, leaving the conflict markers
in the resulting file in the work tree.

Fix it by doing three things:

 - Update the documentation to match the wish of original "reset --merge"
   better, namely, "An unmerged entry is a sign that the path didn't have
   any local modification and can be safely resetted to whatever the new
   HEAD records";

 - Update read_index_unmerged(), which reads the index file into the cache
   while dropping any higher-stage entries down to stage #0, not to copy
   the object name from the higher stage entry.  The code used to take the
   object name from the a stage entry ("base" if you happened to have
   stage #1, or "ours" if both sides added, etc.), which essentially meant
   that you are getting random results depending on what the merge did.

   The _only_ reason we want to keep a previously unmerged entry in the
   index at stage #0 is so that we don't forget the fact that we have
   corresponding file in the work tree in order to be able to remove it
   when the tree we are resetting to does not have the path.  In order to
   differentiate such an entry from ordinary cache entry, the cache entry
   added by read_index_unmerged() is marked as CE_CONFLICTED.

 - Update merged_entry() and deleted_entry() so that they pay attention to
   cache entries marked as CE_CONFLICTED.  They are previously unmerged
   entries, and the files in the work tree that correspond to them are
   resetted away by oneway_merge() to the version from the tree we are
   resetting to.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This patch makes "reset_index_file()" call "unpack_trees()" directly
instead of forking and execing "git read-tree". So the code is more
efficient.

And it's also easier to see which unpack_tree() options will be used,
as we don't need to follow "git read-tree"'s command line parsing
which is quite complex.

As Daniel Barkalow found, there is a difference between this new
version and the old one. The old version gives an error for
"git reset --merge" with unmerged entries, and the new version does
not when we reset the entries to some states that differ from HEAD.
Instead, it resets the index entry and succeeds, while leaving the
conflict markers in the corresponding file in the work tree (which
will be corrected by the next patch).

The code comes from the sequencer GSoC project:

git://repo.or.cz/git/sbeyer.git

(at commit 5a78908b70ceb5a4ea9fd4b82f07ceba1f019079)
Mentored-by: NDaniel Barkalow <barkalow@iabervon.org>
Mentored-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NStephan Beyer <s-beyer@gmx.net>
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Commit 9e8eceab ("Add 'merge' mode to 'git reset'", 2008-12-01),
added the --merge option to git reset, but there were no test cases
for it.

This was not a big problem because "git reset" was just forking and
execing "git read-tree", but this will change in a following patch.

So let's add a few test cases to make sure that there will be no
regression.
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This patch adds a DISCUSSION section that contains some tables to
show how the different "git reset" options work depending on the
states of the files in the working tree, the index, HEAD and the
target commit.
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When running a "git reset --mixed" in a bare repository, the
message displayed is something like:

fatal: This operation must be run in a work tree
fatal: Could not reset index file to revision 'HEAD^'.

This message is a little bit misleading because a mixed reset is
ok in a git directory, so it is not absolutely needed to run it in
a work tree.

So this patch improves upon the above by changing the message to:

fatal: mixed reset is not allowed in a bare repository

And if "git reset" is ever sped up by using unpack_tree() directly
(instead of execing "git read-tree"), this patch will also make
sure that a mixed reset is still disallowed in a bare repository.
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

git svn gc will compress the unhandled.log files that git svn mkdirs reads,
causing git svn mkdirs to skip directory creation.

[ew: trivial whitespace cleanups]
Acked-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NRobert Zeh <robert.a.zeh@gmail.com>

svn+ssh:// repositories often have userinfo embedded in the URL
which were stripped out of the "git-svn-id:" trailers.  Since
the SVN::Client::copy function takes userinfo into account when
matching URLs for SVN repositories, we need to retrieve the full
URL with embedded userinfo in it to avoid mismatched URLs.
Tested-by: NFlorian Köberle <florian@fkoeberle.de>
Signed-off-by: NEric Wong <normalperson@yhbt.net>

* maint:
  Prevent git blame from segfaulting on a missing author name

This appears to be a trivial case where array indices were being
passed to git rev-list, instead of the contents stored in the
array itself.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

The human-readable author and committer name can be missing from
commits imported from foreign SCM interfaces.  Make sure we parse
the "author" and "committer" line a bit more leniently and avoid
segfaulting by assuming the name always exists.
Signed-off-by: NDavid Reiss <dreiss@facebook.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Change git-svn not to impose a limit of 16 parents on a merge.

This limit in git-svn artificially prevents cloning svn repositories
that contain commits with more than 16 merge parents.

The limit was removed from builtin-commit-tree.c for git v1.6.0 in commit
ef98c5ca, so there is no need to check for it
it in git-svn.
Signed-off-by: NAndrew Myrick <amyrick@apple.com>
Acked-by: NEric Wong <normalperson@yhbt.net>

The old function was incorrect; in some instances it marks a cherry picked
range as a merged branch (because of an incorrect assumption that
'rev-list COMMIT --not RANGE' would work).  This is replaced with a
function which should detect them correctly, memoized to limit the expense
of dealing with branches with many cherry picks to one 'merge-base' call
per merge, per branch which used cherry picking.
Signed-off-by: NSam Vilain <sam@vilain.net>
Acked-by: NEric Wong <normalperson@yhbt.net>

The old function would have to check all mentioned merge tips, every time
that the mergeinfo ticket changed.  This involved 1-2 rev-list operation
for each listed mergeinfo line.  If there are a lot of feature branches
being merged into a trunk, this makes for a very expensive operation for
detecting the new parents on every merge.

This new version first uses a single 'rev-list' to figure out which commit
ranges are already reachable from the parents.  This is used to eliminate
the already merged branches from the list.
Signed-off-by: NSam Vilain <sam@vilain.net>
Acked-by: NEric Wong <normalperson@yhbt.net>

SVN's list of commit ranges in mergeinfo tickets is inclusive, whereas
git commit ranges are exclusive on the left hand side.  Also, the end
points of the commit ranges may not exist; they simply delineate
ranges of commits which may or may not exist.  Fix these two mistakes.
Signed-off-by: NSam Vilain <sam@vilain.net>
Acked-by: NEric Wong <normalperson@yhbt.net>

Each time the svn mergeinfo ticket changes, we look it up in the rev_map;
when there are a lot of merged branches, this will result in many repeated
lookups of the same information for subsequent commits.  Arrange the slow
part of the function so that it may be memoized, and memoize it.  The more
expensive revision walking operation can be memoized separately.

[ew: changed "next" to "return" for function exit]
Signed-off-by: NSam Vilain <sam@vilain.net>
Acked-by: NEric Wong <normalperson@yhbt.net>

As shown, git-svn has some problems; not all svn merges are correctly
detected, and cherry picks may incorrectly be detected as real merges.
These test cases will be marked as _success once the relevant fixes are in.
Signed-off-by: NSam Vilain <sam@vilain.net>
Acked-by: NEric Wong <normalperson@yhbt.net>

Signed-off-by: NEric Wong <normalperson@yhbt.net>

When using the -r/--revision argument to fetch deleted history,
calling SVN::Ra::get_log() from an SVN::Ra object initialized
to track the deleted URL will fail.

This regression was introduced in:
  commit 4aacaeb3
  "fix shallow clone when upstream revision is too new"

We now ignore errors from SVN::Ra::get_log() here because using
--revision will always override the value of $head here if
(and only if) we're tracking deleted directories.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

Hopefully the last rc before the final one.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  rebase -i: abort cleanly if the editor fails to launch
  technical-docs: document hash API
  api-strbuf.txt: fix typos and document launch_editor()

If the user's configured editor is emacsclient, the editor
will fail to launch if emacs is not running and the git
command that tried to lanuch the editor will abort. For most
commands, all you have to do is to start emacs and repeat
the command.

The "git rebase -i" command, however, aborts without cleaning
the "$GIT_DIR/rebase-merge" directory if it fails to launch the
editor, so you'll need to do "git rebase --abort" before
repeating the rebase command.

Change "git rebase -i" to terminate using "die_abort" (instead of
with "die") if the initial launch of the editor fails.
Signed-off-by: NBjörn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Using 'svn' directly may not work for all users.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

The "git svn gc" command creates and appends to unhandled.log.gz
files which should be parsed before the uncompressed
unhandled.log files.

Reported-by: Robert Zeh
Signed-off-by: NEric Wong <normalperson@yhbt.net>

Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* maint:
  Git 1.6.5.7
  worktree: don't segfault with an absolute pathspec without a work tree
  ignore unknown color configuration
  help.autocorrect: do not run a command if the command given is junk
  Illustrate "filter" attribute with an example

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

If a command is run with an absolute path as a pathspec inside a bare
repository, e.g. "rev-list HEAD -- /home", the code tried to run strlen()
on NULL, which is the result of get_git_work_tree(), and segfaulted.  It
should just fail instead.

Currently the function returns NULL even inside .git/ in a repository
with a work tree, but that is a separate issue.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When parsing the config file, if there is a value that is
syntactically correct but unused, we generally ignore it.
This lets non-core porcelains store arbitrary information in
the config file, and it means that configuration files can
be shared between new and old versions of git (the old
versions might simply ignore certain configuration).

The one exception to this is color configuration; if we
encounter a color.{diff,branch,status}.$slot variable, we
die if it is not one of the recognized slots (presumably as
a safety valve for user misconfiguration). This behavior
has existed since 801235c5 (diff --color: use
$GIT_DIR/config, 2006-06-24), but hasn't yet caused a
problem. No porcelain has wanted to store extra colors, and
we once a color area (like color.diff) has been introduced,
we've never changed the set of color slots.

However, that changed recently with the addition of
color.diff.func. Now a user with color.diff.func in their
config can no longer freely switch between v1.6.6 and older
versions; the old versions will complain about the existence
of the variable.

This patch loosens the check to match the rest of
git-config; unknown color slots are simply ignored. This
doesn't fix this particular problem, as the older version
(without this patch) is the problem, but it at least
prevents it from happening again in the future.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If a given command is not found, then help.c tries to guess which one the
user could have meant. If help.autocorrect is 0 or unset, then a list of
suggestions is given as long as the dissimilarity between the given command
and the candidates is not excessively high. But if help.autocorrect was
non-zero (i.e., a delay after which the command is run automatically), the
latter restriction on dissimilarity was not obeyed.

In my case, this happened:

 $ git ..daab02
 WARNING: You called a Git command named '..daab02', which does not exist.
 Continuing under the assumption that you meant 'read-tree'
 in 4.0 seconds automatically...

The patch reuses the similarity limit that is also applied when the list of
suggested commands is printed.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The example was taken from aa4ed402
(Add 'filter' attribute and external filter driver definition).
Signed-off-by: NNanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Support the new options --all, --prune, and --dry-run for
'git fetch'.

As the --multiple option was primarily introduced to enable
'git remote update' to be re-implemented in terms of 'git fetch'
(16679e37) and is not likely to be used much from the command
line, it does not seems worthwhile to complicate the code
(to support completion of multiple remotes) to handle it.
Signed-off-by: NBjörn Gustavsson <bgustavsson@gmail.com>
Acked-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

These three have already been backported to 1.6.5.5
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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

Giving --format from the command line, or using output file extention to
DWIM the output format, with a pathspec that is disambiguated with an
explicit double-dash on the command line, e.g.

    git archive -o file --format=zip HEAD -- path
    git archive -o file.zip HEAD -- path

didn't work correctly.

This was because the code reordered (when one was given) or added (when
the format was inferred) a --format argument at the end, effectively
making it to "archive HEAD -- path --format=zip", i.e. an extra pathspec
that is unlikely to match anything.

The command line argument list should always be "options, revs and then
paths", and we should set a good example by inserting the --format at the
beginning instead.
Reported-by: NIlari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This hook runs after "git fetch" in the repository the objects are
fetched from as the user who fetched, and has security implications.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>