Teach "git merge-recursive" a --renormalize option to enable the
merge.renormalize configuration.  The --no-renormalize option can
be used to override it in the negative.

So in the future, you might be able to, e.g.:

	git checkout -m -Xrenormalize otherbranch

or

	git revert -Xrenormalize otherpatch

or

	git pull --rebase -Xrenormalize

The bad part: merge.renormalize is still not honored for most
commands.  And it reveals lots of places that -X has not been plumbed
in (so we get "git merge -Xrenormalize" but not much else).

NEEDSWORK: tests

Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently, merging across changes in line ending normalization is
painful since files containing CRLF will conflict with normalized files,
even if the only difference between the two versions is the line
endings.  Additionally, any "real" merge conflicts that exist are
obscured because every line in the file has a conflict.

Assume you start out with a repo that has a lot of text files with CRLF
checked in (A):

      o---C
     /     \
    A---B---D

B: Add "* text=auto" to .gitattributes and normalize all files to
   LF-only

C: Modify some of the text files

D: Try to merge C

You will get a ridiculous number of LF/CRLF conflicts when trying to
merge C into D, since the repository contents for C are "wrong" wrt the
new .gitattributes file.

Fix ll-merge so that the "base", "theirs" and "ours" stages are passed
through convert_to_worktree() and convert_to_git() before a three-way
merge.  This ensures that all three stages are normalized in the same
way, removing from consideration differences that are only due to
normalization.

This feature is optional for now since it changes a low-level mechanism
and is not necessary for the majority of users.  The "merge.renormalize"
config variable enables it.
Signed-off-by: NEyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When the user specifies a message, use fmt_merge_msg_shortlog() to
append the shortlog.

Previously, when a message was specified, we ignored the merge title
("Merge <foo> into <bar>") and shortlog from fmt_merge_msg().

Update the documentation for -m to reflect this too.
Signed-off-by: NTay Ray Chuan <rctay89@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It is more accurate to call it 'merge_names' instead of 'msg', as it
does not contain the final message.
Signed-off-by: NTay Ray Chuan <rctay89@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

ce9d823b (merge: do not add standard message when message is given with
-m option) changed the behaviour of the code that the comment addressed,
but the comment was not similarly updated.

Fix this.
Signed-off-by: NTay Ray Chuan <rctay89@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In the try_merge_strategy() function, when the strategy is "recursive"
or "subtree", the merge_recursive() function is called.
Otherwise we launch a "git merge-STRATEGY" process.

To make it possible to reuse code that launches a "git merge-STRATEGY"
process, this patch refactors this code into a new try_merge_command()
function.
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This shrinks the top-level directory a bit, and makes it much more
pleasant to use auto-completion on the thing. Instead of

	[torvalds@nehalem git]$ em buil<tab>
	Display all 180 possibilities? (y or n)
	[torvalds@nehalem git]$ em builtin-sh
	builtin-shortlog.c     builtin-show-branch.c  builtin-show-ref.c
	builtin-shortlog.o     builtin-show-branch.o  builtin-show-ref.o
	[torvalds@nehalem git]$ em builtin-shor<tab>
	builtin-shortlog.c  builtin-shortlog.o
	[torvalds@nehalem git]$ em builtin-shortlog.c

you get

	[torvalds@nehalem git]$ em buil<tab>		[type]
	builtin/   builtin.h
	[torvalds@nehalem git]$ em builtin		[auto-completes to]
	[torvalds@nehalem git]$ em builtin/sh<tab>	[type]
	shortlog.c     shortlog.o     show-branch.c  show-branch.o  show-ref.c     show-ref.o
	[torvalds@nehalem git]$ em builtin/sho		[auto-completes to]
	[torvalds@nehalem git]$ em builtin/shor<tab>	[type]
	shortlog.c  shortlog.o
	[torvalds@nehalem git]$ em builtin/shortlog.c

which doesn't seem all that different, but not having that annoying
break in "Display all 180 possibilities?" is quite a relief.

NOTE! If you do this in a clean tree (no object files etc), or using an
editor that has auto-completion rules that ignores '*.o' files, you
won't see that annoying 'Display all 180 possibilities?' message - it
will just show the choices instead.  I think bash has some cut-off
around 100 choices or something.

So the reason I see this is that I'm using an odd editory, and thus
don't have the rules to cut down on auto-completion.  But you can
simulate that by using 'ls' instead, or something similar.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This makes "subtree" more orthogonal to the rest of recursive merge, so
that you can use subtree and ours/theirs features at the same time.  For
example, you can now say:

	git merge -s subtree -Xtheirs other

to merge with "other" branch while shifting it up or down to match the
shape of the tree of the current branch, and resolving conflicts favoring
the changes "other" branch made over changes made in the current branch.

It also allows the prefix used to shift the trees to be specified using
the "-Xsubtree=$prefix" option.  Giving an empty prefix tells the command
to figure out how much to shift trees automatically as we have always
done.  "merge -s subtree" is the same as "merge -s recursive -Xsubtree="
(or "merge -s recursive -Xsubtree").

Based on an old patch done back in the days when git-merge was a script;
Avery ported the script part to builtin-merge.c.  Bugs in shift_tree()
is mine.
Signed-off-by: NAvery Pennarun <apenwarr@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Teach "-X <option>" command line argument to "git merge" that is passed to
strategy implementations.  "ours" and "theirs" autoresolution introduced
by the previous commit can be asked to the recursive strategy.
Signed-off-by: NAvery Pennarun <apenwarr@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Various commands refuse to run in the presence of conflicts (commit,
merge, pull, cherry-pick/revert). They all used to provide rough, and
inconsistant error messages.

A new variable advice.resolveconflict is introduced, and allows more
verbose messages, pointing the user to the appropriate solution.

For commit, the error message used to look like this:

$ git commit
foo.txt: needs merge
foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
error: Error building trees

The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
option to make the output more consistant with the other porcelain
commands, and catch the error in return, to stop with a clean error
message. The next lines were displayed by a call to cache_tree_update(),
which is not reached anymore if we noticed the conflict.

The new output looks like:

U       foo.txt
fatal: 'commit' is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>' as
appropriate to mark resolution and make a commit, or use 'git commit -a'.

Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD
exists instead of waiting for merge to complain.

The behavior of merge and the test-case are slightly modified to reflect
the usual flow: start with conflicts, fix them, and afterwards get rid of
MERGE_HEAD, with different error messages at each stage.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When resolving a conflict using "git add" to create a stage #0 entry, or
"git rm" to remove entries at higher stages, remove_index_entry_at()
function is eventually called to remove unmerged (i.e. higher stage)
entries from the index.  Introduce a "resolve_undo_info" structure and
keep track of the removed cache entries, and save it in a new index
extension section in the index_state.

Operations like "read-tree -m", "merge", "checkout [-m] <branch>" and
"reset" are signs that recorded information in the index is no longer
necessary.  The data is removed from the index extension when operations
start; they may leave conflicted entries in the index, and later user
actions like "git add" will record their conflicted states afresh.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Instead of using the low-level index_state interface, use the bog standard
active_cache and active_nr macros to access the cache entries when using the
default one.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This reverts commit c0ecb070 "git-pull.sh:
Fix call to git-merge for new command format" and

commit b81e00a9 "git-merge: a deprecation
notice of the ancient command line syntax".

They caused a "git pull" (without any arguments, and without any local
commits---only to update to the other side) to warn that commit log
message is ignored because the merge resulted in a fast-forward.

Another possible solution is to add an extra option to "git merge" so that
"git pull" can tell it that the message given is not coming from the end
user (the canned message is passed just in case the merge resulted in a
non-ff and caused commit), but I think it is easier _not_ to deprecate the
old syntax.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Introduce a command line option to override rerere.autoupdate configuration
variable to make it more useful.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Even if the user explicitly gave her own message to "git merge", the
command still added its standard merge message.  It resulted in a
useless repetition like this:

    % git merge -m "Merge early part of side branch" `git rev-parse side~2`
    % git show -s
    commit 37217141e7519629353738d5e4e677a15096206f
    Merge: e68e646 a1d2374
    Author: しらいし ななこ <nanako3@lavabit.com>
    Date:   Wed Dec 2 14:33:20 2009 +0900

	Merge early part of side branch

	Merge commit 'a1d2374f8f52f4e8a53171601a920b538a6cec23'

The gave her own message because she didn't want git to add the
standard message (if she wanted to, she wouldn't have given one,
or she would have prepared it using git-fmt-merge-msg command).

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

This was misinterpreted as an ancient style "git merge <message> HEAD
<commit> <commit>..." that merges one (or more) <commit> into the current
branch and record the resulting commit with the given message.  Then a
later sanity check found that there is no <commit> specified and gave
a usage message.
Tested-by: NNanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The ancient form of git merge command used in the original sample script
has been copied from Linus and are still found everywhere, I think, and
people may still have it in their scripts, but on the other hand, it is so
unintuitive that even people reasonably familiar with git are surprised by
accidentally triggering the support to parse this ancient form.

Gently nudge people to upgrade their script to more recent and readable
style for eventual removal of the original syntax.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

fadd069d (merge-recursive: give less scary messages when merge did not
start, Sep 7 2009) introduced some friendlier error message for merge
failure, but the messages were shown only for non-fast forward merges.
This patch uses the same for fast-forward.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We need to call exclude_cmds() after the loop, not during the loop, because
excluding a command from the array can change the indexes of objects in the
array.  The result is that, depending on file ordering, some commands
weren't excluded as they should have been.
Signed-off-by: NAvery Pennarun <apenwarr@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Builtins do not need to run setup_worktree() for themselves, since
the builtin machinery runs it for them.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

For convenience in scripts and aliases, add the option
--ff-only to only allow fast-forwards (and up-to-date,
despite the name).

Disallow combining --ff-only and --no-ff, since they
flatly contradict each other.

Allow all other options to be combined with --ff-only
(i.e. do not add any code to handle them specially),
including the following options:

* --strategy (one or more): As long as the chosen merge
  strategy results in up-to-date or fast-forward, the
  command will succeed.

* --squash: I cannot imagine why anyone would want to
  squash commits only if fast-forward is possible, but I
  also see no reason why it should not be allowed.

* --message: The message will always be ignored, but I see
  no need to explicitly disallow providing a redundant message.

Acknowledgements: I did look at Yuval Kogman's earlier
patch (107768 in gmane), mainly as shortcut to find my
way in the code, but I did not copy anything directly.
Signed-off-by: NBjörn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It's a compound word.
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

pretty_print_commit() has a bunch of rarely-used arguments, and
introducing more of them requires yet another update of all the call
sites.  Refactor most of them into a struct to make future extensions
easier.

The ones that stay "plain" arguments were chosen on the grounds that
all callers put real arguments there, whereas some callers have 0/NULL
for all arguments that were factored into the struct.

We declare the struct 'const' to ensure none of the callers are bitten
by the changed (no longer call-by-value) semantics.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Previously when merging directly from a local tracking
branch like:

  git merge origin/master

The merge message said:

   Merge commit 'origin/master'

     * commit 'origin/master':
       ...

Instead, let's be more explicit about what we are merging:

   Merge remote branch 'origin/master'

     * origin/master:
       ...

We accomplish this by recognizing remote tracking branches
in git-merge when we build the simulated FETCH_HEAD output
that we feed to fmt-merge-msg.

In addition to a new test in t7608, we have to tweak the
expected output of t3409, which does such a merge.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If we have both a tag and a branch named "foo", then calling
"git merge foo" will warn about the ambiguous ref, but merge
the tag.

When generating the commit message, though, we simply
checked whether "refs/heads/foo" existed, and if it did,
assumed it was a branch. This led to the statement "Merge
branch 'foo'" in the commit message, which is quite wrong.

Instead, we should use dwim_ref to find the actual ref used,
and describe it appropriately.

In addition to the test in t7608, we must also tweak the
expected output of t4202, which was accidentally triggering
this bug.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

As a general guideline, functions in git's code return zero to indicate
success and negative values to indicate failure. The run_command family of
functions followed this guideline. But there are actually two different
kinds of failure:

- failures of system calls;

- non-zero exit code of the program that was run.

Usually, a non-zero exit code of the program is a failure and means a
failure to the caller. Except that sometimes it does not. For example, the
exit code of merge programs (e.g. external merge drivers) conveys
information about how the merge failed, and not all exit calls are
actually failures.

Furthermore, the return value of run_command is sometimes used as exit
code by the caller.

This change arranges that the exit code of the program is returned as a
positive value, which can now be regarded as the "result" of the function.
System call failures continue to be reported as negative values.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Lots of die() calls did not actually report the kind of error, which
can leave the user confused as to the real problem.  Use die_errno()
where we check a system/library call that sets errno on failure, or
one of the following that wrap such calls:

  Function              Passes on error from
  --------              --------------------
  odb_pack_keep         open
  read_ancestry         fopen
  read_in_full          xread
  strbuf_read           xread
  strbuf_read_file      open or strbuf_read_file
  strbuf_readlink       readlink
  write_in_full         xwrite
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Change calls to die(..., strerror(errno)) to use the new die_errno().

In the process, also make slight style adjustments: at least state
_something_ about the function that failed (instead of just printing
the pathname), and put paths in single quotes.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There are a few remaining ones, but this fixes the trivial ones. It boils
down to two main issues that sparse complains about:

 - warning: Using plain integer as NULL pointer

   Sparse doesn't like you using '0' instead of 'NULL'. For various good
   reasons, not the least of which is just the visual confusion. A NULL
   pointer is not an integer, and that whole "0 works as NULL" is a
   historical accident and not very pretty.

   A few of these remain: zlib is a total mess, and Z_NULL is just a 0.
   I didn't touch those.

 - warning: symbol 'xyz' was not declared. Should it be static?

   Sparse wants to see declarations for any functions you export. A lack
   of a declaration tends to mean that you should either add one, or you
   should mark the function 'static' to show that it's in file scope.

   A few of these remain: I only did the ones that should obviously just
   be made static.

That 'wt_status_submodule_summary' one is debatable. It has a few related
flags (like 'wt_status_use_color') which _are_ declared, and are used by
builtin-commit.c. So maybe we'd like to export it at some point, but it's
not declared now, and not used outside of that file, so 'static' it is in
this patch.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The following is an easy mistake to make for users coming from version
control systems with an "update and commit"-style workflow.

        1. git pull
        2. resolve conflicts
        3. git pull

Step 3 overrides MERGE_HEAD, starting a new merge with dirty index.
IOW, probably not what the user intended. Instead, refuse to merge
again if a merge is in progress.
Reported-by: NDave Olszewski <cxreg@pobox.com>
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

To give OPT_FILENAME the prefix, we pass the prefix to parse_options()
which passes the prefix to parse_options_start() which sets the prefix
member of parse_opts_ctx accordingly. If there isn't a prefix in the
calling context, passing NULL will suffice.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NAllan Caffee <allan.caffee@gmail.com>
Acked-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The function takes a user-supplied string that is supposed to be a branch
name, and puts it in a strbuf after expanding possible shorthand notation.

A handful of open coded sequence to do this in the existing code have been
changed to use this helper function.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

These allow you to say "git checkout @{-2}" to switch to the branch two
"branch switching" ago by pretending as if you typed the name of that
branch.  As it is likely that we will be introducing more short-hands to
write the name of a branch without writing it explicitly, rename the
functions from "nth_last_branch" to more generic "branch_name", to prepare
for different semantics.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

By having flags represented as bits in the new member variable 'flags',
it will be easier to use parse_options when dir_struct is involved.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

1.6.2 will have @{-1} syntax advertised as "usable anywhere you can use
a branch name".  However, "git merge @{-1}" did not work.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NAlexander Potashev <aspotashev@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

A function that runs a hook is used in several Git commands.
builtin-commit.c has the one that is most general for cases without
piping. The one in builtin-gc.c prints some useful warnings.
This patch moves a merged version of these variants into libgit and
lets the other builtins use this libified run_hook().

The run_hook() function used in receive-pack.c feeds the standard
input of the pre-receive or post-receive hooks. This function is
renamed to run_receive_hook() because the libified run_hook() cannot
handle this.
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: NJunio C Hamano <gitster@pobox.com>

So that full filesystem conditions or permissions problems won't go
unnoticed.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>