summaryrefslogtreecommitdiff
path: root/builtin/merge.c
AgeCommit message (Collapse)AuthorFilesLines
2012-08-22Merge branch 'tr/void-diff-setup-done'Libravatar Junio C Hamano1-2/+1
Remove unnecessary code. * tr/void-diff-setup-done: diff_setup_done(): return void
2012-08-03diff_setup_done(): return voidLibravatar Thomas Rast1-2/+1
diff_setup_done() has historically returned an error code, but lost the last nonzero return in 943d5b7 (allow diff.renamelimit to be set regardless of -M/-C, 2006-08-09). The callers were in a pretty confused state: some actually checked for the return code, and some did not. Let it return void, and patch all callers to take this into account. This conveniently also gets rid of a handful of different(!) error messages that could never be triggered anyway. Note that the function can still die(). Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-24ident: rename IDENT_ERROR_ON_NO_NAME to IDENT_STRICTLibravatar Jeff King1-2/+2
Callers who ask for ERROR_ON_NO_NAME are not so much concerned that the name will be blank (because, after all, we will fall back to using the username), but rather it is a check to make sure that low-quality identities do not end up in things like commit messages or emails (whereas it is OK for them to end up in things like reflogs). When future commits add more quality checks on the identity, each of these callers would want to use those checks, too. Rather than modify each of them later to add a new flag, let's refactor the flag. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-27Merge branch 'jc/merge-reduce-parents-early'Libravatar Junio C Hamano1-54/+88
Octopus merge strategy did not reduce heads that are recorded in the final commit correctly. By Junio C Hamano (4) and Michał Kiedrowicz (1) * jc/merge-reduce-parents-early: fmt-merge-msg: discard needless merge parents builtin/merge.c: reduce parents early builtin/merge.c: collect other parents early builtin/merge.c: remove "remoteheads" global variable merge tests: octopus with redundant parents
2012-04-17builtin/merge.c: reduce parents earlyLibravatar Junio C Hamano1-25/+40
Instead of waiting until we record the parents of resulting merge, reduce redundant parents (including our HEAD) immediately after reading them. The change to t7602 illustrates the essence of the effect of this change. The octopus merge strategy used to be fed with redundant commits only to discard them as "up-to-date", but we no longer feed such redundant commits to it and the affected test degenerates to a regular two-head merge. And obviously the known-to-be-broken test in t6028 is now fixed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17builtin/merge.c: collect other parents earlyLibravatar Junio C Hamano1-13/+27
Move the code around to populate remoteheads list early in the process before any decision regarding twohead vs octopus and fast-forwardness is made. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-17builtin/merge.c: remove "remoteheads" global variableLibravatar Junio C Hamano1-23/+28
Instead pass it around starting from the toplevel cmd_merge() as an explicit parameter. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-02Sync with 1.7.9.6Libravatar Junio C Hamano1-4/+1
2012-03-20merge: backport GIT_MERGE_AUTOEDIT supportLibravatar Junio C Hamano1-1/+28
Even though 1.7.9.x series does not open the editor by default when merging in general, it does do so in one occassion: when merging an annotated tag. And worse yet, there is no good way for older scripts to decline this. Backport the support for GIT_MERGE_AUTOEDIT environment variable from 1.7.10 track to help those stuck on 1.7.9.x maintenance track. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-06Merge branch 'zj/diff-stat-dyncol'Libravatar Junio C Hamano1-0/+2
By Zbigniew Jędrzejewski-Szmek (8) and Junio C Hamano (1) * zj/diff-stat-dyncol: : This breaks tests. Perhaps it is not worth using the decimal-width stuff : for this series, at least initially. diff --stat: add config option to limit graph width diff --stat: enable limiting of the graph part diff --stat: add a test for output with COLUMNS=40 diff --stat: use a maximum of 5/8 for the filename part merge --stat: use the full terminal width log --stat: use the full terminal width show --stat: use the full terminal width diff --stat: use the full terminal width diff --stat: tests for long filenames and big change counts
2012-03-01diff --stat: add config option to limit graph widthLibravatar Zbigniew Jędrzejewski-Szmek1-0/+1
Config option diff.statGraphWidth=<width> is equivalent to --stat-graph-width=<width>, except that the config option is ignored by format-patch. For the graph-width limiting to be usable, it should happen 'automatically' once configured, hence the config option. Nevertheless, graph width limiting only makes sense when used on a wide terminal, so it should not influence the output of format-patch, which adheres to the 80-column standard. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-01merge --stat: use the full terminal widthLibravatar Zbigniew Jędrzejewski-Szmek1-0/+1
Make merge --stat behave like diff --stat and use the full terminal width. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-27Merge branch 'tr/merge-edit-guidance' into maintLibravatar Junio C Hamano1-0/+10
* tr/merge-edit-guidance: merge: add instructions to the commit message when editing
2012-02-23merge: do not trust fstat(2) too much when checking interactivenessLibravatar Junio C Hamano1-1/+1
The heuristic used by "git merge" to decide if it automatically gives an editor upon clean automerge is to see if the standard input and the standard output is the same device and is a tty, we are in an interactive session. "The same device" test was done by comparing fstat(2) result on the two file descriptors (and they must match), and we asked isatty() only for the standard input (we insist that they are the same device and there is no point asking tty-ness of the standard output). The stat(2) emulation in the Windows port however does not give a usable value in the st_ino field, so even if the standard output is connected to something different from the standard input, "The same device" test may incorrectly return true. To accomodate it, add another isatty() check for the standard output stream as well. Reported-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-12Merge branch 'jn/merge-no-edit-fix'Libravatar Junio C Hamano1-1/+2
* jn/merge-no-edit-fix: merge: do not launch an editor on "--no-edit $tag" Conflicts: builtin/merge.c
2012-02-10Merge branch 'jc/merge-ff-only-stronger-than-signed-merge'Libravatar Junio C Hamano1-1/+2
* jc/merge-ff-only-stronger-than-signed-merge: merge: do not create a signed tag merge under --ff-only option
2012-02-09merge: do not launch an editor on "--no-edit $tag"Libravatar Junio C Hamano1-3/+7
When the user explicitly asked us not to, don't launch an editor. But do everything else the same way as the "edit" case, i.e. leave the comment with verification result in the log template and record the mergesig in the resulting merge commit for later inspection. Based on initiail analysis by Jonathan Nieder. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-05merge: do not create a signed tag merge under --ff-only optionLibravatar Junio C Hamano1-1/+2
Starting at release v1.7.9, if you ask to merge a signed tag, "git merge" always creates a merge commit, even when the tag points at a commit that happens to be a descendant of your current commit. Unfortunately, this interacts rather badly for people who use --ff-only to make sure that their branch is free of local developments. It used to be possible to say: $ git checkout -b frotz v1.7.9~30 $ git merge --ff-only v1.7.9 and expect that the resulting tip of frotz branch matches v1.7.9^0 (aka the commit tagged as v1.7.9), but this fails with the updated Git with: fatal: Not possible to fast-forward, aborting. because a merge that merges v1.7.9 tag to v1.7.9~30 cannot be created by fast forwarding. We could teach users that now they have to do $ git merge --ff-only v1.7.9^0 but it is far more pleasant for users if we DWIMmed this ourselves. When an integrator pulls in a topic from a lieutenant via a signed tag, even when the work done by the lieutenant happens to fast-forward, the integrator wants to have a merge record, so the integrator will not be asking for --ff-only when running "git pull" in such a case. Therefore, this change should not regress the support for the use case v1.7.9 wanted to add. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-31Merge branch 'tr/merge-edit-guidance'Libravatar Junio C Hamano1-0/+10
* tr/merge-edit-guidance: merge: add instructions to the commit message when editing
2012-01-31Merge branch 'jc/pull-signed-tag'Libravatar Junio C Hamano1-4/+34
* jc/pull-signed-tag: merge: use editor by default in interactive sessions Conflicts: Documentation/merge-options.txt
2012-01-31merge: add instructions to the commit message when editingLibravatar Thomas Rast1-0/+10
Before f824628 (merge: use editor by default in interactive sessions, 2012-01-10), git-merge only started an editor if the user explicitly asked for it with --edit. Thus it seemed unlikely that the user would need extra guidance. After f824628 the _normal_ thing is to start an editor. Give at least an indication of why we are doing it. The sentence about justification is one of the few things about standard git that are not agnostic to the workflow that the user chose. However, f824628 was proposed by Linus specifically to discourage users from merging unrelated upstream progress into topic branches. So we may as well take another step in the same direction. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-23merge: use editor by default in interactive sessionsLibravatar Junio C Hamano1-4/+34
Traditionally, a cleanly resolved merge was committed by "git merge" using the auto-generated merge commit log message without invoking the editor. After 5 years of use in the field, it turns out that people perform too many unjustified merges of the upstream history into their topic branches. These merges are not just useless, but they are often not explained well, and making the end result unreadable when it gets time for merging their history back to their upstream. Earlier we added the "--edit" option to the command, so that people can edit the log message to explain and justify their merge commits. Let's take it one step further and spawn the editor by default when we are in an interactive session (i.e. the standard input and the standard output are pointing at the same tty device). There may be existing scripts that leave the standard input and the standard output of the "git merge" connected to whatever environment the scripts were started, and such invocation might trigger the above "interactive session" heuristics. GIT_MERGE_AUTOEDIT environment variable can be set to "no" at the beginning of such scripts to use the historical behaviour while the script runs. Note that this backward compatibility is meant only for scripts, and we deliberately do *not* support "merge.edit = yes/no/auto" configuration option to allow people to keep the historical behaviour. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-06Merge branch 'jc/show-sig'Libravatar Junio C Hamano1-2/+12
* jc/show-sig: log --show-signature: reword the common two-head merge case log-tree: show mergetag in log --show-signature output log-tree.c: small refactor in show_signature() commit --amend -S: strip existing gpgsig headers verify_signed_buffer: fix stale comment gpg-interface: allow use of a custom GPG binary pretty: %G[?GS] placeholders test "commit -S" and "log --show-signature" log: --show-signature commit: teach --gpg-sign option Conflicts: builtin/commit-tree.c builtin/commit.c builtin/merge.c notes-cache.c pretty.c
2011-12-22Merge branch 'jk/maint-strbuf-missing-init'Libravatar Junio C Hamano1-1/+1
* jk/maint-strbuf-missing-init: commit, merge: initialize static strbuf Conflicts: builtin/merge.c
2011-12-22Merge branch 'nd/war-on-nul-in-commit'Libravatar Junio C Hamano1-2/+4
* nd/war-on-nul-in-commit: commit_tree(): refuse commit messages that contain NULs Convert commit_tree() to take strbuf as message merge: abort if fails to commit Conflicts: builtin/commit.c commit.c commit.h
2011-12-19Merge branch 'nd/resolve-ref'Libravatar Junio C Hamano1-7/+5
* nd/resolve-ref: Rename resolve_ref() to resolve_ref_unsafe() Convert resolve_ref+xstrdup to new resolve_refdup function revert: convert resolve_ref() to read_ref_full()
2011-12-18Update jk/maint-strbuf-missing-init to builtin/ renameLibravatar Junio C Hamano1-0/+1292
2011-12-15Convert commit_tree() to take strbuf as messageLibravatar Nguyễn Thái Ngọc Duy1-2/+2
There wan't a way for commit_tree() to notice if the message the caller prepared contained a NUL byte, as it did not take the length of the message as a parameter. Use a pointer to a strbuf instead, so that we can either choose to allow low-level plumbing commands to make commits that contain NUL byte in its message, or forbid NUL everywhere by adding the check in commit_tree(), in later patches. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15merge: abort if fails to commitLibravatar Nguyễn Thái Ngọc Duy1-2/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13Merge branch 'nd/ignore-might-be-precious'Libravatar Junio C Hamano1-4/+8
* nd/ignore-might-be-precious: checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore
2011-12-13Convert resolve_ref+xstrdup to new resolve_refdup functionLibravatar Nguyễn Thái Ngọc Duy1-7/+5
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09Merge branch 'nd/resolve-ref'Libravatar Junio C Hamano1-24/+41
* nd/resolve-ref: Copy resolve_ref() return value for longer use Convert many resolve_ref() calls to read_ref*() and ref_exists() Conflicts: builtin/fmt-merge-msg.c builtin/merge.c refs.c
2011-12-09Merge branch 'jc/pull-signed-tag'Libravatar Junio C Hamano1-45/+50
* jc/pull-signed-tag: commit-tree: teach -m/-F options to read logs from elsewhere commit-tree: update the command line parsing commit: teach --amend to carry forward extra headers merge: force edit and no-ff mode when merging a tag object commit: copy merged signed tags to headers of merge commit merge: record tag objects without peeling in MERGE_HEAD merge: make usage of commit->util more extensible fmt-merge-msg: Add contents of merged tag in the merge message fmt-merge-msg: package options into a structure fmt-merge-msg: avoid early returns refs DWIMmery: use the same rule for both "git fetch" and others fetch: allow "git fetch $there v1.0" to fetch a tag merge: notice local merging of tags and keep it unwrapped fetch: do not store peeled tag object names in FETCH_HEAD Split GPG interface into its own helper library Conflicts: builtin/fmt-merge-msg.c builtin/merge.c
2011-12-09Merge branch 'jc/request-pull-show-head-4'Libravatar Junio C Hamano1-10/+10
* jc/request-pull-show-head-4: request-pull: use the annotated tag contents fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error environment.c: Fix an sparse "symbol not declared" warning builtin/log.c: Fix an "Using plain integer as NULL pointer" warning fmt-merge-msg: use branch.$name.description request-pull: use the branch description request-pull: state what commit to expect request-pull: modernize style branch: teach --edit-description option format-patch: use branch description in cover letter branch: add read_branch_desc() helper function Conflicts: builtin/branch.c
2011-12-05Copy resolve_ref() return value for longer useLibravatar Nguyễn Thái Ngọc Duy1-22/+40
resolve_ref() may return a pointer to a static buffer. Callers that use this value longer than a couple of statements should copy the value to avoid some hidden resolve_ref() call that may change the static buffer's value. The bug found by Tony Wang <wwwjfy@gmail.com> in builtin/merge.c demonstrates this. The first call is in cmd_merge() branch = resolve_ref("HEAD", head_sha1, 0, &flag); Then deep in lookup_commit_or_die() a few lines after, resolve_ref() may be called again and destroy "branch". lookup_commit_or_die lookup_commit_reference lookup_commit_reference_gently parse_object lookup_replace_object do_lookup_replace_object prepare_replace_object for_each_replace_ref do_for_each_ref get_loose_refs get_ref_dir get_ref_dir resolve_ref All call sites are checked and made sure that xstrdup() is called if the value should be saved. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-05Merge branch 'nd/maint-ignore-exclude'Libravatar Junio C Hamano1-1/+1
* nd/maint-ignore-exclude: checkout,merge: loosen overwriting untracked file check based on info/exclude
2011-12-05Merge branch 'vr/git-merge-default-to-upstream'Libravatar Junio C Hamano1-3/+6
* vr/git-merge-default-to-upstream: Show error for 'git merge' with unset merge.defaultToUpstream
2011-11-28checkout,merge: disallow overwriting ignored files with --no-overwrite-ignoreLibravatar Nguyễn Thái Ngọc Duy1-4/+8
Ignored files usually are generated files (e.g. .o files) and can be safely discarded. However sometimes users may have important files in working directory, but still want a clean "git status", so they mark them as ignored files. But in this case, these files should not be overwritten without asking first. Enable this use case with --no-overwrite-ignore, where git only sees tracked and untracked files, no ignored files. Those who mix discardable ignored files with important ones may have to sort it out themselves. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28Merge branch 'nd/maint-ignore-exclude' into nd/ignore-might-be-preciousLibravatar Junio C Hamano1-1/+1
* nd/maint-ignore-exclude: checkout,merge: loosen overwriting untracked file check based on info/exclude
2011-11-28checkout,merge: loosen overwriting untracked file check based on info/excludeLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Back in 1127148 (Loosen "working file will be lost" check in Porcelain-ish - 2006-12-04), git-checkout.sh learned to quietly overwrite ignored files. Howver the code only took .gitignore files into account. Standard ignored files include all specified in .gitignore files in working directory _and_ $GIT_DIR/info/exclude. This patch makes sure ignored files in info/exclude can also be overwritten automatically in the spirit of the original patch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-21Show error for 'git merge' with unset merge.defaultToUpstreamLibravatar Vincent van Ravesteijn1-3/+6
'git merge' can be called without any arguments if merge.defaultToUpstream is set. However, when merge.defaultToUpstream is not set, the user will be presented the usage information as if he entered a command with a wrong syntaxis. Ironically, the usage information confirms that no arguments are mandatory. This adds a proper error message telling the user why the command failed. As a side-effect this can help the user in discovering the possibility to merge with the upstream branch by setting merge.defaultToUpstream. Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-17do not let git_path clobber errno when reporting errorsLibravatar Jonathan Nieder1-20/+29
Because git_path() calls vsnprintf(), code like fd = open(git_path("SQUASH_MSG"), O_WRONLY | O_CREAT, 0666); die_errno(_("Could not write to '%s'"), git_path("SQUASH_MSG")); can end up printing an error indicator from vsnprintf() instead of open() by mistake. Store the path we are trying to write to in a temporary variable and pass _that_ to die_errno(), so the messages written by git cherry-pick/revert and git merge can avoid this source of confusion. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-13Convert many resolve_ref() calls to read_ref*() and ref_exists()Libravatar Nguyễn Thái Ngọc Duy1-2/+2
resolve_ref() may return a pointer to a static buffer, which is not safe for long-term use because if another resolve_ref() call happens, the buffer may be changed. Many call sites though do not care about this buffer. They simply check if the return value is NULL or not. Convert all these call sites to new wrappers to reduce resolve_ref() calls from 57 to 34. If we change resolve_ref() prototype later on to avoid passing static buffer out, this helps reduce changes. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-12commit: teach --gpg-sign optionLibravatar Junio C Hamano1-2/+14
This uses the gpg-interface.[ch] to allow signing the commit, i.e. $ git commit --gpg-sign -m foo You need a passphrase to unlock the secret key for user: "Junio C Hamano <gitster@pobox.com>" 4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7) [master 8457d13] foo 1 files changed, 1 insertions(+), 0 deletions(-) The lines of GPG detached signature are placed in a new multi-line header field, instead of tucking the signature block at the end of the commit log message text (similar to how signed tag is done), for multiple reasons: - The signature won't clutter output from "git log" and friends if it is in the extra header. If we place it at the end of the log message, we would need to teach "git log" and friends to strip the signature block with an option. - Teaching new versions of "git log" and "gitk" to optionally verify and show signatures is cleaner if we structurally know where the signature block is (instead of scanning in the commit log message). - The signature needs to be stripped upon various commit rewriting operations, e.g. rebase, filter-branch, etc. They all already ignore unknown headers, but if we place signature in the log message, all of these tools (and third-party tools) also need to learn how a signature block would look like. - When we added the optional encoding header, all the tools (both in tree and third-party) that acts on the raw commit object should have been fixed to ignore headers they do not understand, so it is not like that new header would be more likely to break than extra text in the commit. A commit made with the above sample sequence would look like this: $ git cat-file commit HEAD tree 3cd71d90e3db4136e5260ab54599791c4f883b9d parent b87755351a47b09cb27d6913e6e0e17e6254a4d4 author Junio C Hamano <gitster@pobox.com> 1317862251 -0700 committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700 gpgsig -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG ... =dt98 -----END PGP SIGNATURE----- foo but "git log" (unless you ask for it with --pretty=raw) output is not cluttered with the signature information. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-09merge: force edit and no-ff mode when merging a tag objectLibravatar Junio C Hamano1-0/+6
Now that we allow pulling a tag from the remote site to validate the authenticity, we should give the user the final chance to verify and edit the merge message. The integrator is expected to leave a meaningful merge commit log in the history. Disallow fast-forwarding in such a case to ensure that a merge commit is always recorded. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-08merge: record tag objects without peeling in MERGE_HEADLibravatar Junio C Hamano1-3/+10
Otherwise, "git commit" wouldn't have a way to tell that we were in the middle of merging an annotated or signed tag, not a plain commit, after "git merge" stops to ask the user to resolve conflicts. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-08merge: make usage of commit->util more extensibleLibravatar Junio C Hamano1-40/+23
The merge-recursive code uses the commit->util field directly to annotate the commit objects given from the command line, i.e. the remote heads to be merged, with a single string to be used to describe it in its trace messages and conflict markers. Correct this short-signtedness by redefining the field to be a pointer to a structure "struct merge_remote_desc" that later enhancements can add more information. Store the original objects we were told to merge in a field "obj" in this struct, so that we can recover the tag we were told to merge. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-07fmt-merge-msg: package options into a structureLibravatar Junio C Hamano1-2/+6
This way new features can be added more easily Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-07merge: notice local merging of tags and keep it unwrappedLibravatar Junio C Hamano1-0/+5
This also updates the autogenerated merge title message from "merge commit X" to "merge tag X", and its effect can be seen in the changes to the test suite. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-21Merge branch 'nd/maint-autofix-tag-in-head' into maintLibravatar Junio C Hamano1-56/+61
* nd/maint-autofix-tag-in-head: Accept tags in HEAD or MERGE_HEAD merge: remove global variable head[] merge: use return value of resolve_ref() to determine if HEAD is invalid merge: keep stash[] a local variable Conflicts: builtin/merge.c