Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 04 6月, 2014 2 次提交
    • J
      error_resolve_conflict: drop quotations around operation · d795216a
      由 Jeff King 提交于 
      When you try to commit with unmerged entries, you get an
error like:

  $ git commit
  error: 'commit' is not possible because you have unmerged files.

The quotes around "commit" are clunky; the user doesn't care
that this message is a template with the command-name filled
in.  Saying:

  error: commit is not possible because you have unmerged files

is easier to read. As this code is called from other places,
we may also end up with:

  $ git merge
  error: merge is not possible because you have unmerged files

  $ git cherry-pick foo
  error: cherry-pick is not possible because you have unmerged files

  $ git revert foo
  error: revert is not possible because you have unmerged files

All of which look better without the quotes. This also
happens to match the behavior of "git pull", which generates
a similar message (but does not share code, as it is a shell
script).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d795216a
    • J
      error_resolve_conflict: rewrap advice message · c057b242
      由 Jeff King 提交于 
      If you try to commit with unresolved conflicts in the index,
you get this message:

	$ git commit
	U       foo
	error: 'commit' is not possible because you have unmerged files.
	hint: Fix them up in the work tree,
	hint: and then use 'git add/rm <file>' as
	hint: appropriate to mark resolution and make a commit,
	hint: or use 'git commit -a'.
	fatal: Exiting because of an unresolved conflict.

The irregular line-wrapping makes this awkward to read, and
it takes up more lines than necessary. Instead, let's rewrap
it to about 60 characters per line:

	$ git commit
	U       foo
	error: 'commit' is not possible because you have unmerged files.
	hint: Fix them up in the work tree, and then use 'git add/rm <file>'
	hint: as appropriate to mark resolution and make a commit, or use
	hint: 'git commit -a'.
	fatal: Exiting because of an unresolved conflict.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c057b242
  3. 14 11月, 2013 1 次提交
  5. 01 8月, 2013 1 次提交
  7. 19 6月, 2013 1 次提交
  9. 13 6月, 2013 1 次提交
  11. 30 5月, 2013 1 次提交
  13. 03 4月, 2013 1 次提交
  15. 17 3月, 2013 1 次提交
  17. 25 1月, 2013 1 次提交
    • J
      push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE · 75e5c0dc
      由 Junio C Hamano 提交于 
      When we push to update an existing ref, if:

 * the object at the tip of the remote is not a commit; or
 * the object we are pushing is not a commit,

it won't be correct to suggest to fetch, integrate and push again,
as the old and new objects will not "merge".  We should explain that
the push must be forced when there is a non-committish object is
involved in such a case.

If we do not have the current object at the tip of the remote, we do
not even know that object, when fetched, is something that can be
merged.  In such a case, suggesting to pull first just like
non-fast-forward case may not be technically correct, but in
practice, most such failures are seen when you try to push your work
to a branch without knowing that somebody else already pushed to
update the same branch since you forked, so "pull first" would work
as a suggestion most of the time.  And if the object at the tip is
not a commit, "pull first" will fail, without making any permanent
damage.  As a side effect, it also makes the error message the user
will get during the next "push" attempt easier to understand, now
the user is aware that a non-commit object is involved.

In these cases, the current code already rejects such a push on the
client end, but we used the same error and advice messages as the
ones used when rejecting a non-fast-forward push, i.e. pull from
there and integrate before pushing again.

Introduce new rejection reasons and reword the messages
appropriately.

[jc: with help by Peff on message details]
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      75e5c0dc
  19. 04 12月, 2012 2 次提交
  21. 24 7月, 2012 1 次提交
    • J
      advice: pass varargs to strbuf_vaddf, not strbuf_addf · 447b99c8
      由 Jeff King 提交于 
      The advise() function takes a variable number of arguments
and converts them into a va_list object to pass to strbuf
for handling. However, we accidentally called strbuf_addf
(that takes a variable number of arguments) instead of
strbuf_vaddf (that takes a va_list).

This bug dates back to v1.7.8.1-1-g23cb5bf3, but we never
noticed because none of the current callers passes a string
with a format specifier in it. And the compiler did not
notice because the format string is not available at
compile time.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      447b99c8
  23. 20 3月, 2012 1 次提交
    • C
      push: Provide situational hints for non-fast-forward errors · f25950f3
      由 Christopher Tiwald 提交于 
      Pushing a non-fast-forward update to a remote repository will result in
an error, but the hint text doesn't provide the correct resolution in
every case. Give better resolution advice in three push scenarios:

1) If you push your current branch and it triggers a non-fast-forward
error, you should merge remote changes with 'git pull' before pushing
again.

2) If you push to a shared repository others push to, and your local
tracking branches are not kept up to date, the 'matching refs' default
will generate non-fast-forward errors on outdated branches. If this is
your workflow, the 'matching refs' default is not for you. Consider
setting the 'push.default' configuration variable to 'current' or
'upstream' to ensure only your current branch is pushed.

3) If you explicitly specify a ref that is not your current branch or
push matching branches with ':', you will generate a non-fast-forward
error if any pushed branch tip is out of date. You should checkout the
offending branch and merge remote changes before pushing again.

Teach transport.c to recognize these scenarios and configure push.c
to hint for them. If 'git push's default behavior changes or we
discover more scenarios, extension is easy. Standardize on the
advice API and add three new advice variables, 'pushNonFFCurrent',
'pushNonFFDefault', and 'pushNonFFMatching'. Setting any of these
to 'false' will disable their affiliated advice. Setting
'pushNonFastForward' to false will disable all three, thus preserving the
config option for users who already set it, but guaranteeing new
users won't disable push advice accidentally.
Based-on-patch-by: NJunio C Hamano <gitster@pobox.com>
Signed-off-by: NChristopher Tiwald <christiwald@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f25950f3
  25. 17 1月, 2012 1 次提交
  27. 23 12月, 2011 1 次提交
    • J
      i18n of multi-line advice messages · 23cb5bf3
      由 Junio C Hamano 提交于 
      Advice messages are by definition meant for human end-users, and prime
candidates for i18n/l10n. They tend to also be more verbose to be helpful,
and need to be longer than just one line.

Although we do not have parameterized multi-line advice messages yet, once
we do, we cannot emit such a message like this:

    advise(_("Please rename %s to something else"), gostak);
    advise(_("so that we can avoid distimming %s unnecessarily."), doshes);

because some translations may need to have the replacement of 'gostak' on
the second line (or 'doshes' on the first line). Some languages may even
need to use three lines in order to fit the same message within a
reasonable width.

Instead, it has to be a single advise() construct, like this:

    advise(_("Please rename %s to something else\n"
             "so that we can avoid distimming %s unnecessarily."),
           gostak, doshes);

Update the advise() function and its existing callers to

 - take a format string that can be multi-line and translatable as a
   whole;
 - use the string and the parameters to form a localized message; and
 - show each line in the result with the localization of the "hint: ".
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      23cb5bf3
  29. 05 8月, 2011 1 次提交
  31. 30 1月, 2010 1 次提交
    • J
      Reword "detached HEAD" notification · 13be3e31
      由 Junio C Hamano 提交于 
      The old "advice" message explained how to create a branch after going into
a detached HEAD state but didn't make it clear why the user may want to do
so.  Also "moving to ... which isn't a local branch" was unclear if it is
complaining, if it is describing the new state, or if it is explaining why
the HEAD is detached (the true reason is the last one).

Give the established phrase 'detached HEAD' first to make it easy for
users to look up the concept in documentation, and briefly describe what
can be done in the state (i.e. play around without having to clean up)
before telling the user how to keep what was done during the temporary
state.

Allow the long description to be hidden by setting advice.detachedHead
configuration to false.

We might want to customize the advice depending on how the commit to check
out was spelled (e.g. instead of "new-branch-name", we way want to say
"topic" when "git checkout origin/topic" triggered this message) in later
updates, but this encapsulates that into a separate function and it should
be a good first step.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      13be3e31
  33. 15 1月, 2010 1 次提交
    • J
      commit: allow suppression of implicit identity advice · b706fcfe
      由 Jeff King 提交于 
      We now nag the user with a giant warning when their identity
was pulled from the username, hostname, and gecos
information, in case it is not correct. Most users will
suppress this by simply setting up their information
correctly.

However, there may be some users who consciously want to use
that information, because having the value change from host
to host contains useful information. These users can now set
advice.implicitidentity to false to suppress the message.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b706fcfe
  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. 23 11月, 2009 1 次提交
  39. 12 9月, 2009 2 次提交