t7512: test "detached from" as well

b397ea4863a1 (status: show more info than "currently not on any
branch", 2013-03-13) wanted to make sure that after a checkout to
detach HEAD, the user can see where the HEAD was originally detached
from.  The last test added by that commit to t7512 shows one
example, immediately after HEAD is detached.  Enhance that test to
show "detached HEAD from" form that should be shown when the user
further resetted to another commit.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
wt-status: remove unused field in grab_1st_switch_cbdata

The struct grab_1st_switch_cbdata has the field "found", which is
set in grab_1st_switch() when a match is found.  This information is
redundant and unused by any code.  The return value of the function
serves to communicate this information anyway.

Remove the field.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t2021-checkout-last: "checkout -" should work after a rebase finishes

  $ git checkout -

does not work as expected after a rebase.  This is because the
reflog records "checkout" made by "rebase" as its implementation
detail the same way as end-user initiated "checkout", and makes it
count as the branch that was previously checked out.

Add four failing tests documenting this bug: two for a normal rebase,
and another two for an interactive rebase.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
status: do not depend on rebase reflog messages

b397ea4 (status: show more info than "currently not on any branch",
2013-03-13) attempted to make the output of 'git status' richer in
the case of a detached HEAD.  Before this patch, with a detached
HEAD, we saw:

  $ git status
  # Not currently on any branch.

But after the patch, we see:

  $ git checkout v1.8.2
  $ git status
  # HEAD detached at v1.8.2.

It works by digging the reflog for the most recent message of the
form "checkout: moving from xxxx to yyyy".  It then asserts that
HEAD and "yyyy" are the same, and displays this message.  When they
aren't equal, it displays:

  $ git status
  # HEAD detached from fe11db.

so that the user can see where the HEAD was first detached.

In case of a rebase [-i] operation in progress, this message depends
on the implementation of rebase writing "checkout: " messages to the
reflog, but that is an implementation detail of "rebase".  To remove
this dependency so that rebase can be updated to write better reflog
messages, replace this "HEAD detached from" message with:

  # rebase in progress; onto $ONTO

Changes to the commit object name in the expected output for some of
the tests shows that what the test expected "status" to show during
"rebase -i" was not consistent with the output during a vanilla
"rebase", which showed on top of what commit the series is being
replayed.  Now we consistently expect something meaningful to the
end user.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
checkout: respect GIT_REFLOG_ACTION

GIT_REFLOG_ACTION is an environment variable specifying the reflog
message to write after an action is completed.  Several other commands
including merge, reset, and commit respect it.

Fix the failing tests in t/checkout-last by making checkout respect it
too.  You can now expect

  $ git checkout -

to work as expected after any operation that internally uses "checkout"
as its implementation detail, e.g. "rebase".

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t5528-push-default: remove redundant test_config lines

The line

  test_config push.default upstream

appears unnecessarily in two tests, as the final test_push_failure sets
push.default before pushing anyway.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
config doc: rewrite push.default section

4d35924e (Merge branch 'rr/triangle', 2013-04-07) introduced support
for triangular workflows, but the push.default values still assume
central workflows.

Rewrite the descriptions of `nothing`, `current`, `upstream` and
`matching` for greater clarity, and explicitly explain how they
should behave in triangular workflows.

Leave `simple` as it is for the moment, as we plan to change its
meaning to accommodate triangular workflows in a later patch.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
push: change `simple` to accommodate triangular workflows

When remote.pushdefault or branch.<name>.pushremote is set to a
remote that is different from where you usually fetch from (i.e. a
triangular workflow), master@{u} != origin, and push.default is set
to `upstream` or `simple` would fail with this error:

  $ git push
  fatal: You are pushing to remote 'origin', which is not the upstream of
  your current branch 'master', without telling me what to push
  to update which remote branch.

The very name of "upstream" indicates that it is only suitable for
use in central workflows; let us not even attempt to give it a new
meaning in triangular workflows, and error out as before.

However, the `simple` does not have to share this error.  It is
poised to be the default for Git 2.0, and we would like it to do
something sensible in triangular workflows.

Redefine "simple" as "safer upstream" for centralized workflow as
before, but work as "current" for triangular workflow.

We may want to make it "safer current", but that is a separate
issue.

Reported-by: Leandro Lucarella <leandro.lucarella@sociomantic.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t5528-push-default: generalize test_push_*

The setup creates two bare repositories: repo1 and repo2, but
test_push_commit() hard-codes checking in repo1 for the actual output.
Generalize it and its caller, test_push_success(), to optionally accept
a third argument to specify the name of the repository to check for
actual output.  We will use this in the next patch.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t5528-push-default: test pushdefault workflows

Introduce test_pushdefault_workflows(), and test that all push.default
modes work with central and triangular workflows as expected.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
status: introduce status.short to enable --short by default

Some people always run 'git status -s'.
The configuration variable status.short allows to set it by default.

Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>
Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
status: introduce status.branch to enable --branch by default

Some people often run 'git status -b'.
The config variable status.branch allows to set it by default.

Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>
Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit: make it work with status.short

With "status.short" set, it is now impossible to commit with
status.short set, because it acts like "git commit --short", and it
is impossible to differentiate between a status_format set by the
command-line option parser versus that set by the config parser.

To alleviate this problem, clear status_format as soon as the config
parser has finished its work.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
status/commit: make sure --porcelain is not affected by user-facing config

The recent addition of status.branch started affecting what is shown
when "git status --porcelain" is run by mistake.  Identify the
configuration items that should be ignored under "--porcelain"
option, introduce a "deferred config" mechanism to keep the values
read from the configuration, and decide what value to use only after
we read both from configuration and command line.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff: demote core.safecrlf=true to core.safecrlf=warn

Otherwise the user will not be able to start to guess where in the
contents in the working tree the offending unsafe CR lies.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: handle unstuck form of base git options

git-completion.bash's parsing of the command name relies on everything
preceding it starting with '-' unless it is the "-c" option.  This
allows users to use the stuck form of "--work-tree=<path>" and
"--namespace=<path>" but not the unstuck forms "--work-tree <path>" and
"--namespace <path>".  Fix this.

Similarly, the completion only handles the stuck form "--git-dir=<path>"
and not "--git-dir <path>", so fix this as well.

Signed-off-by: John Keeping <john@keeping.me.uk>
Acked-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: learn about --man-path

Signed-off-by: John Keeping <john@keeping.me.uk>
Acked-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
treat_directory(): do not declare submodules to be untracked

When the working tree walker encounters a directory, it asks the
function treat_directory() if it should descend into it, show it as
an untracked directory, or do something else.  When the directory is
the top of the submodule working tree, we used to say "That is an
untracked directory", which was bogus.

It is an entity that is tracked in the index of the repository we
are looking at, and that is not to be descended into it.  Return
path_none, not path_untracked, to report that.

The existing case that path_untracked is returned for a newly
discovered submodule that is not tracked in the index (this only
happens when DIR_NO_GITLINKS option is not used) is unchanged, but
that is exactly because the submodule is not tracked in the index.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
git stash: avoid data loss when "git stash save" kills a directory

"stash save" is about saving the local change to the working tree,
but also about restoring the state of the last commit to the working
tree.  When a local change is to turn a non-directory to a directory,
in order to restore the non-directory, everything in the directory
needs to be removed.

Which is fine when running "git stash save --include-untracked",
but without that option, untracked, newly created files in the
directory will have to be discarded, if the state you are restoring
to has a non-directory at the same path as the directory.

Introduce a safety valve to fail the operation in such case, using
the "ls-files --killed" which was designed for this exact purpose.

The "stash save" is stopped when untracked files need to be
discarded because their leading path ceased to be a directory, and
the user is required to pass --force to really have the data
removed.

Signed-off-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t1512: correct leftover constants from earlier edition

The earliest iteration of this test script used a magic string
110282 as the common prefix for ambiguous object names, but the
final edition switched the common prefix to 0000000000 (10 "0"s).

Unfortunately, instances of the original prefix were left in the
comments and a few tests.  Replace them with the correct constants.

Signed-off-by: Junio C Hamano <gitster@pobox.com>