delta/git.git/advice.h, branch fc/mergetools-vimdiff3

Merge branch 'jk/gcc-function-attributes'

2013-07-22T18:23:59+00:00

Use the function attributes extension to catch mistakes in use of
our own variadic functions that use NULL sentinel at the end
(i.e. like execl(3)) and format strings (i.e. like printf(3)).

* jk/gcc-function-attributes:
  Add the LAST_ARG_MUST_BE_NULL macro
  wt-status: use "format" function attribute for status_printf
  use "sentinel" function attribute for variadic lists
  add missing "format" function attributes

add missing "format" function attributes

2013-07-10T05:23:04+00:00

For most of our functions that take printf-like formats, we
use gcc's __attribute__((format)) to get compiler warnings
when the functions are misused. Let's give a few more
functions the same protection.

In most cases, the annotations do not uncover any actual
bugs; the only code change needed is that we passed a size_t
to transfer_debug, which expected an int. Since we expect
the passed-in value to be a relatively small buffer size
(and cast a similar value to int directly below), we can
just cast away the problem.

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

Merge branch 'mm/rm-coalesce-errors'

2013-06-24T20:48:35+00:00

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

rm: introduce advice.rmHints to shorten messages

2013-06-12T23:59:55+00:00

Introduce advice.rmHints to choose whether to display advice or not
when git rm fails. Defaults to true, in order to preserve current behavior.

As an example, the message:
	error: 'foo.txt' has changes staged in the index
	(use --cached to keep the file, or -f to force removal)

would look like, with advice.rmHints=false:
	error: 'foo.txt' has changes staged in the index

Signed-off-by: Mathieu Lienard--Mayor 
Signed-off-by: Jorge Juan Garcia Garcia 
Signed-off-by: Matthieu Moy 
Signed-off-by: Junio C Hamano

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

2013-06-11T20:31:07+00:00

"git cmd ", when  happens to be a 40-hex string,
directly uses the 40-hex string as an object name, even if a ref
"refs//" 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
name.

* nd/warn-ambiguous-object-name:
  get_sha1: warn about full or short object names that look like refs

get_sha1: warn about full or short object names that look like refs

2013-05-29T18:31:36+00:00

When we get 40 hex digits, we immediately assume it's an SHA-1. This
is the right thing to do because we have no way else to specify an
object. If there is a ref with the same object name, it will be
ignored. Warn the user about this case because the ref with full
object name is likely a mistake, for example

    git checkout -b $empty_var $(git rev-parse something)

advice.object_name_warning is not documented because frankly people
should not be aware about it until they encounter this situation.

While at there, warn about ambiguation with abbreviated SHA-1 too.

Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano

branch: give advice when tracking start-point is missing

2013-04-02T23:14:13+00:00

If the user requests to --set-upstream-to a branch that does
not exist, then either:

  1. It was a typo.

  2. They thought the branch should exist.

In case (1), there is not much we can do beyond showing the
name we tried to use. For case (2), though, we can help to
guide them through common workflows.

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

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

2013-03-21T21:02:10+00:00

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

status: advise to consider use of -u when read_directory takes too long

2013-03-17T04:44:58+00:00

Introduce advice.statusUoption to suggest considering use of -u to
strike different trade-off when it took more than 2 seconds to
enumerate untracked/ignored files.

Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano

push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE

2013-01-24T22:37:23+00:00

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: Junio C Hamano