- 18 11月, 2010 2 次提交
-
-
由 Johan Herland 提交于
Teach 'git merge' the --abort option, which verifies the existence of MERGE_HEAD and then invokes 'git reset --merge' to abort the current in-progress merge and attempt to reconstruct the pre-merge state. The reason for adding this option is to provide a user interface for aborting an in-progress merge that is consistent with the interface for aborting a rebase ('git rebase --abort'), aborting the application of a patch series ('git am --abort'), and aborting an in-progress notes merge ('git notes merge --abort'). The patch includes documentation and testcases that explain and verify the various scenarios in which 'git merge --abort' can run. The testcases also document the cases in which 'git merge --abort' is unable to correctly restore the pre-merge state (look for the '###' comments towards the bottom of t/t7609-merge-abort.sh). This patch has been improved by the following contributions: - Jonathan Nieder: Move test documentation into test_description Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJohan Herland <johan@herland.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johan Herland 提交于
Reorder the initial part of builtin/merge.c:cmd_merge() so that command-line options are parsed _before_ we load the index and check for MERGE_HEAD (and exits if it exists). This does not change the behaviour of 'git merge', but is needed in preparation for the implementation of 'git merge --abort' (which requires MERGE_HEAD to be present). This patch has been improved by the following contributions: - Junio C Hamano: fixup minor style issues Thanks-to: Junio C Hamano <gitster@pobox.com> Signed-off-by: NJohan Herland <johan@herland.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 11月, 2010 1 次提交
-
-
由 Clemens Buchacher 提交于
In case HEAD does not point to a valid commit yet, merge is implemented as a hard reset. This will cause untracked files to be overwritten. Instead, assume the empty tree for HEAD and do a regular merge. An untracked file will cause the merge to abort and do nothing. If no conflicting files are present, the merge will have the same effect as a hard reset. Signed-off-by: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 11月, 2010 1 次提交
-
-
由 Matthieu Moy 提交于
(Just like we did for documentation already) In the process, we change "non-remote branch" to "branch outside the refs/remotes/ hierarchy" to avoid the ugly "non-remote-tracking branch". The new formulation actually corresponds to how the code detects this case (i.e. prefixcmp(refname, "refs/remotes")). Also, we use 'remote-tracking branch' in generated merge messages (by merge an fmt-merge-msg). Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 10月, 2010 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Part of a campaign to make sure "git <command> -h" works correctly when run from distractingly bad repositories. [jn: with rewritten log message and tests] Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 9月, 2010 3 次提交
-
-
由 Ramkumar Ramachandra 提交于
Make 'merge.log' an integer or boolean option to set the number of shortlog entries to display in the merge commit. Note that it defaults to false, and that true means a default value of 20. Also update corresponding documentation. Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com> Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Johannes Sixt <j.sixt@viscovery.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ramkumar Ramachandra 提交于
Change the command-line '--log' option from a boolean option to an integer option, and parse the optional integer provided on the command-line into the 'shortlog_len' variable. Also update the documentation accordingly. Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com> Reported-by: NYaroslav Halchenko <debian@onerussian.com> Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Johannes Sixt <j.sixt@viscovery.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ramkumar Ramachandra 提交于
Give "shortlog_len" parameter to the fmt_merge_msg(), remove its "merge_summary" parameter, and remove fmt_merge_msg_shortlog() function. In the updated API, shortlog_len == 0 means no shortlog is given. The parameter "merge_title" controls if the title of the merge commit is autogenerated (it reads something like "Merge branch ..."), and typically it is set to true when the caller does not give its own message. Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com> Mentored-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 9月, 2010 3 次提交
-
-
由 Matthieu Moy 提交于
Not only this makes the code clearer since setting up the porcelain error message is meant to work with show_all_errors, but this fixes a call to setup_unpack_trees_porcelain() in git_merge_trees() which did not set show_all_errors. add_rejected_path() used to double-check whether it was running in plumbing mode. This check was ineffective since it was setting show_all_errors too late for traverse_trees() to see it, and is made useless by this patch. Remove it. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Matthieu Moy 提交于
This is a preparation patch to let setup_unpack_trees_porcelain set show_all_errors itself. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Matthieu Moy 提交于
The function is currently dealing only with error messages, but the intent of calling it is really to notify the unpack-tree mechanics that it is running in porcelain mode. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 8月, 2010 1 次提交
-
-
由 Jonathan Nieder 提交于
There are two very similar blocks of code that recognize options for the "recursive" merge strategy. Unify them. No functional change intended. Cc: Avery Pennarun <apenwarr@gmail.com> Helped-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 8月, 2010 1 次提交
-
-
由 Jonathan Nieder 提交于
If no branch 'foo' exists but a tag 'foo' does, then git merge foo^ results in Merge branch 'foo' (early part) as a commit message, because the relevant code path checks that refs/heads/foo is a valid refname for writing rather than for reading. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 8月, 2010 1 次提交
-
-
由 Jonathan Nieder 提交于
As v1.6.1-rc1~294^2 (2008-08-23) explains, custom merge strategies do not even kick in when the merge is truly trivial. But they should, since otherwise a custom “--strategy=theirs” is not useful. Perhaps custom strategies should not allow fast-forward either. This patch does not make that change, since it is less important (because it is always possible to explicitly use --no-ff). Reported-by: NYaroslav Halchenko <debian@onerussian.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 8月, 2010 4 次提交
-
-
由 Matthieu Moy 提交于
When an error is encountered, it calls add_rejected_file() which either - directly displays the error message and stops if in plumbing mode (i.e. if show_all_errors is not initialized at 1) - or stores it so that it will be displayed at the end with display_error_msgs(), Storing the files by error type permits to have a list of files for which there is the same error instead of having a serie of almost identical errors. As each bind_overlap error combines a file and an old file, a list cannot be done, therefore, theses errors are not stored but directly displayed. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Diane Gasselin 提交于
A porcelain message was first added in checkout.c in the commit 8ccba008 (Junio C Hamano, Sat May 17 21:03:49 2008, unpack-trees: allow Porcelain to give different error messages) to give better feedback in the case of merge errors. This patch adapts the porcelain messages for the case of checkout instead. This way, when having a checkout error, "merge" no longer appears in the error message. While we're there, we add an advice in the case of would_lose_untracked_file. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Matthieu Moy 提交于
The list of error messages was introduced as a structure, but an array indexed over an enum is more flexible, since it allows one to store a type of error message (index in the array) in a variable. This change needs to rename would_lose_untracked -> would_lose_untracked_file to avoid a clash with the function would_lose_untracked in merge-recursive.c. Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Greg Brockman 提交于
This allows the caller to add its own error message to that returned by split_cmdline. Thus error output following a failed split_cmdline can be of the form fatal: Bad alias.test string: cmdline ends with \ rather than error: cmdline ends with \ fatal: Bad alias.test string Signed-off-by: NGreg Brockman <gdb@mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 8月, 2010 1 次提交
-
-
由 Jonathan Nieder 提交于
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>
-
- 03 7月, 2010 1 次提交
-
-
由 Eyvind Bernhardsen 提交于
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>
-
- 11 5月, 2010 3 次提交
-
-
由 Tay Ray Chuan 提交于
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>
-
由 Tay Ray Chuan 提交于
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>
-
由 Tay Ray Chuan 提交于
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>
-
- 02 4月, 2010 2 次提交
-
-
由 Christian Couder 提交于
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
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>
-
- 23 2月, 2010 1 次提交
-
-
由 Linus Torvalds 提交于
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>
-
- 18 1月, 2010 2 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 Avery Pennarun 提交于
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>
-
- 13 1月, 2010 1 次提交
-
-
由 Matthieu Moy 提交于
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>
-
- 26 12月, 2009 2 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
- 09 12月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 04 12月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 03 12月, 2009 2 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 Junio C Hamano 提交于
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>
-
- 02 12月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
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>
-
- 30 11月, 2009 2 次提交
-
-
由 Matthieu Moy 提交于
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>
-
由 Avery Pennarun 提交于
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>
-
- 11 11月, 2009 1 次提交
-
-
由 Jonathan Nieder 提交于
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>
-
- 31 10月, 2009 1 次提交
-
-
由 Björn Gustavsson 提交于
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>
-