Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Mar 07, 2014

  1. Junio C Hamano

    Merge branch 'jc/push-2.0-default-to-simple'

    Finally update the "git push" default behaviour to "simple".
    authored March 07, 2014

Jun 24, 2013

  1. Junio C Hamano

    Merge branch 'mm/rm-coalesce-errors'

    Give a single message followed by list of paths from "git rm" to
    report multiple paths that cannot be removed.
    * mm/rm-coalesce-errors:
      rm: introduce advice.rmHints to shorten messages
      rm: better error message on failure for multiple files
    authored June 24, 2013

Jun 18, 2013

  1. Junio C Hamano

    push: switch default from "matching" to "simple"

    We promised to change the behaviour of lazy "git push [there]" that
    does not say what to push on the command line from "matching" to
    "simple" in Git 2.0.
    This finally flips that bit.
    Helped-by: Matthieu Moy <>
    Signed-off-by: Junio C Hamano <>
    authored January 04, 2013

Jun 11, 2013

  1. Junio C Hamano

    Merge branch 'nd/warn-ambiguous-object-name'

    "git cmd <name>", when <name> happens to be a 40-hex string,
    directly uses the 40-hex string as an object name, even if a ref
    "refs/<some hierarchy>/<name>" exists.  This disambiguation order
    is unlikely to change, but we should warn about the ambiguity just
    like we warn when more than one refs/ hierachies share the same
    * nd/warn-ambiguous-object-name:
      get_sha1: warn about full or short object names that look like refs
    authored June 11, 2013

Mar 21, 2013

  1. Junio C Hamano

    Merge branch 'tb/document-status-u-tradeoff'

    Suggest users to look into using--untracked=no option when "git
    status" takes too long.
    * tb/document-status-u-tradeoff:
      status: advise to consider use of -u when read_directory takes too long
      git status: document trade-offs in choosing parameters to the -u option
    authored March 21, 2013

Jan 24, 2013

  1. 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
    [jc: with help by Peff on message details]
    Signed-off-by: Junio C Hamano <>
    authored January 23, 2013

Jul 24, 2012

  1. Junio C Hamano

    Merge branch 'jk/maint-advise-vaddf'

    The advise() function did not use varargs correctly to format
    its message.
    * jk/maint-advise-vaddf:
      advice: pass varargs to strbuf_vaddf, not strbuf_addf
    authored July 24, 2012

Feb 01, 2012

  1. Junio C Hamano

    Merge branch 'nd/clone-detached'

    * nd/clone-detached:
      clone: fix up delay cloning conditions
      push: do not let configured foreign-vcs permanently clobbered
      clone: print advice on checking out detached HEAD
      clone: allow --branch to take a tag
      clone: refuse to clone if --branch points to bogus ref
      clone: --branch=<branch> always means refs/heads/<branch>
      clone: delay cloning until after remote HEAD checking
      clone: factor out remote ref writing
      clone: factor out HEAD update code
      clone: factor out checkout code
      clone: write detached HEAD in bare repositories
      t5601: add missing && cascade
    authored January 31, 2012

Dec 22, 2011

  1. Junio C Hamano

    i18n of multi-line advice messages

    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
     - 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: Junio C Hamano <>
    authored December 22, 2011

Jan 30, 2010

  1. Junio C Hamano

    Reword "detached HEAD" notification

    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
    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: Junio C Hamano <>
    authored January 29, 2010

Jan 20, 2010

  1. Junio C Hamano

    Merge branch 'mm/conflict-advice'

    * mm/conflict-advice:
      Be more user-friendly when refusing to do something because of conflict.
    authored January 20, 2010
Something went wrong with that request. Please try again.