Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 16 2月, 2011 2 次提交
  3. 18 11月, 2010 2 次提交
    • J
      Provide 'git merge --abort' as a synonym to 'git reset --merge' · 35d2fffd
      由 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>
      35d2fffd
    • J
      cmd_merge(): Parse options before checking MERGE_HEAD · 2a22c1b3
      由 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>
      2a22c1b3
  5. 16 11月, 2010 1 次提交
  7. 04 11月, 2010 1 次提交
  9. 23 10月, 2010 1 次提交
  11. 10 9月, 2010 3 次提交
  13. 04 9月, 2010 3 次提交
  15. 27 8月, 2010 1 次提交
  17. 19 8月, 2010 1 次提交
  19. 16 8月, 2010 1 次提交
  21. 12 8月, 2010 4 次提交
    • M
      unpack_trees: group error messages by type · e6c111b4
      由 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>
      e6c111b4
    • D
      merge-recursive: porcelain messages for checkout · 23cbf11b
      由 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>
      23cbf11b
    • M
      Turn unpack_trees_options.msgs into an array + enum · 08353ebb
      由 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>
      08353ebb
    • G
      split_cmdline: Allow caller to access error string · ad9ac6db
      由 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>
      ad9ac6db
  23. 07 8月, 2010 1 次提交
    • J
      merge-recursive --renormalize · 7610fa57
      由 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>
      7610fa57
  25. 03 7月, 2010 1 次提交
    • E
      Avoid conflicts when merging branches with mixed normalization · f217f0e8
      由 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>
      f217f0e8
  27. 11 5月, 2010 3 次提交
  29. 02 4月, 2010 2 次提交
  31. 23 2月, 2010 1 次提交
    • L
      Move 'builtin-*' into a 'builtin/' subdirectory · 81b50f3c
      由 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>
      81b50f3c
  33. 18 1月, 2010 2 次提交
    • J
      Make "subtree" part more orthogonal to the rest of merge-recursive. · 85e51b78
      由 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>
      85e51b78
    • A
      git merge -X<option> · 8cc5b290
      由 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>
      8cc5b290
  35. 13 1月, 2010 1 次提交
    • M
      Be more user-friendly when refusing to do something because of conflict. · d38a30df
      由 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>
      d38a30df
  37. 26 12月, 2009 2 次提交
    • J
      resolve-undo: record resolved conflicts in a new index extension section · cfc5789a
      由 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>
      cfc5789a
    • J
      builtin-merge.c: use standard active_cache macros · be6ff819
      由 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>
      be6ff819
  39. 09 12月, 2009 1 次提交
    • J
      Revert recent "git merge <msg> HEAD <commit>..." deprecation · 77c29b4a
      由 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>
      77c29b4a
  41. 04 12月, 2009 1 次提交
  43. 03 12月, 2009 2 次提交
    • J
      merge: do not add standard message when message is given with -m option · ce9d823b
      由 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>
      ce9d823b
    • J
      Do not misidentify "git merge foo HEAD" as an old-style invocation · 76bf488e
      由 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>
      76bf488e
  45. 02 12月, 2009 1 次提交
    • J
      git-merge: a deprecation notice of the ancient command line syntax · b81e00a9
      由 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>
      b81e00a9
  47. 30 11月, 2009 2 次提交