Rename remote.c's default_remote_name static variables.

This prepares the code to handle a true remote.default configuration value.

Rename two variables:
  default_remote_name          --> effective_remote_name
  explicit_default_remote_name --> explicit_effective_remote_name

effective_remote_name is the remote name that is currently "in effect".
This is the currently checked-out branch's remote (in which case
explicit_effective_remote_name=1), or "origin" if the branch has no remote
(or the working tree is a detached HEAD).

The next commit re-introduces default_remote_name with its new semantics.

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach remote.c about the remote.default configuration setting.

The code now has a default_remote_name and an effective_remote_name:

 - default_remote_name is set by remote.default in the config, or is "origin"
   if remote.default doesn't exist ("origin" was the fallback value before
   this change).

 - effective_remote_name is the name of the remote tracked by the current
   branch, or is default_remote_name if the current branch doesn't have a
   remote.

This has a minor side effect on the default behavior of "git push".  Consider
the following sequence of commands:

      git config remote.default foo                 # Set default remote
      git checkout somelocalbranch                  # Does not track a remote
      git remote add origin ssh://example.com/repo  # Add a new "origin"
      git push

Prior to this change, the above "git push" would attempt to push to the new
"origin" repository at ssh://example.com/repo.  Now instead that "git push"
will attempt to push to the repository named "foo".

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach "git remote" about remote.default.

The "rename" and "rm" commands now handle the case where the remote being
changed is the default remote.

If the "add" command is used to add the repo's first remote, that remote
becomes the default remote.

Also introduce a "default" sub-command to get or set the default remote:

 - "git remote default" (with no parameter) displays the current default remote.

 - "git remote default <remo>" checks if <remo> is a configured remote and if
   so changes remote.default to <remo>.

These changes needed a couple of new helper functions in remote.c:
 - remote_get_default_name() returns default_remote_name.
 - remote_count() returns the number of remotes.

(The test in t5528 had to be changed because now with push.default=matching
a plain "git push" succeeds with "Everything up-to-date".  It used to
fail with "No configured push destination".)

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach clone to set remote.default.

This makes git-clone consistent with the remote.default support implemented in
git-remote.  Specifically, since "git remote add" sets remote.default if
it's adding the first remote to the repository, when clone itself adds the
first remote it should do the same.

This also makes "git clone -o" work without a special case in the code (so
"git clone /some/repo" and "git clone -o origin /some/repo" produce the same
result).

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test that plain "git fetch" uses remote.default when on a detached HEAD.

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach get_default_remote to respect remote.default.

Use "git remote default" instead of replicating its logic.

The unit test checks a relative-path submodule because the submodule code
is (almost) the only thing that uses get_default_remote.

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git add: notice removal of tracked paths by default

When run without "-u" or "-A" option,

    $ edit subdir/x
    $ create subdir/y
    $ rm subdir/z
    $ git add subdir/

does not notice removal of paths (e.g. subdir/z) from the working tree.
Make "git add" to pretend as if "-A" is given when there is a pathspec on
the command line.  "git add" without any argument continues to be a no-op.

When resolving a conflict to remove a path, the current code tells you to
"git rm $path", but now with this patch you can say "git add $path".  Of
course you can do "git add -A $path" without this patch.

In either case, the operation "git add" is about "adding the state of the
path in the working tree to the index".  The state may happen to be "path
removed", not "path has an updated content".

The semantic change can be seen by a breakage in t2200, test #15.  There,
a merge has conflicts in path4 and path6 (which are removed from the
working tree), and test checks "git add path4" to resolve it must fail,
and makes sure "add -u" needs to be used.  We do not have to do this
anymore.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
name-rev: lose unnecessary typedef

Just spell it "struct rev_name"; it makes it more clear what is
going on.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
name_rev: clarify the logic to assign a new tip-name to a commit

In preparation for later changes, restructure the logic a little bit
to separate how the code decides to use the new "tip" for naming a
particular commit, and what happens based on the decision.

Also re-indent and correct style of this function while we are at it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-generation: compute generation numbers and clock skews

It finds three commits that has older commit timestamp than the
newest commit timestamp among its ancestor in our history; all of
these are a direct child of a commit that is older (i.e. the clock
skew lasts for only one hop).

  commit  gen  timestamp                 skew gen ancestor
  ed19f36 2870 2006-03-04 07:29:56 +0000 (8) 2869 91a6bf4
  7763987 6404 2007-09-02 06:53:47 +0000 (373) 6403 86bab96
  619a644 9982 2009-10-18 19:34:56 +0000 (268948) 9981 46148dd

On the other hand, the kernel history is littered with skewed
chains.  I counted 2239 commits that have an ancestor newer than
themselves in total (they tend to cluster, but I haven't counted
clusters), among 322345 commits (0.7%).

For example, a 33-commit chain leading to b4e1b7e builds on top of
422e6c4 that was commited by Linus at Tue Mar 15 15:48:13 2011, but
the tip commit claims to have been committed at Sun Feb 20 19:19:43
2011, which is clearly impossible.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
name-rev: --algorithm option

Instead of naming a rev always after a tip that is topologically
closest, allow the command to use different algorithm when choosing
the tip to base the name on.  A new algorithm "weight" lets you use
the tip that has the smallest number of commits behind it.

The semantics "name-rev --algorithm=weight" would give us is closer
to what people expect from "describe --contains".

Note that this is fairly expensive to compute; a later change in the
series will cache the weight value using notes-cache.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
name-rev --algorithm=weight: trivial optimization

It often happens that immediately after traversing from v1.2.3 to
find out its weight, we are asked to see if another commit v1.2.0
is heavier than that.

Because the commits that are reachable from v1.2.3 are painted with
the SHOWN flag until the next "rev-list" traversal, we can notice
that the new commit v1.2.0 is reachable from v1.2.3 without doing
any traversal.  We cannot learn exactly how much it weighs, but we
can tell it must weigh less than v1.2.3, and that is all that the
caller wants to know.

In the kernel history, "git name-rev --tags 0136db586c" which
started this topic needs 26k calls to tip_weight_cmp().  13k of them
are comparisons between tips based on the same ref and answered
without computing any weight.  Among the remaining 13k, 1.8k
comparisons are answered with this trivial "fast-forward"
optimization.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
name-rev --algorithm=weight: cache the computed weight in notes

With the "weight" assigned to tip of each ref, we can give more
intuitive results from "name-rev" that is more suitable to answer
"what is the oldest tag that contains this commit?"  However, this
number is very expensive to compute.

Use the notes-cache mechanism to cache this value.  The result
becomes usable again.

    (priming the cache from scratch)
    $ rm .git/refs/notes/name-rev-weight
    $ /usr/bin/time git name-rev --algorithm=weight --tags 0136db586c
    0136db586c tags/v3.5-rc1~83^2~81^2~76
    6.06user 0.46system 0:06.54elapsed 99%CPU (0avgtext+0avgdata 1861456maxresident)k
    8inputs+16outputs (0major+128576minor)pagefaults 0swaps

    (with cache already primed)
    $ /usr/bin/time git name-rev --algorithm=weight --tags 0136db586c
    0136db586c tags/v3.5-rc1~83^2~81^2~76
    0.50user 0.22system 0:00.72elapsed 100%CPU (0avgtext+0avgdata 244224maxresident)k
    0inputs+0outputs (0major+16062minor)pagefaults 0swaps

    (the old "shortest path" version)
    $ /usr/bin/time git name-rev --tags 0136db586c
    0136db586c tags/v3.6-rc1~59^2~56^2~76
    0.31user 0.01system 0:00.32elapsed 100%CPU (0avgtext+0avgdata 243488maxresident)k
    0inputs+0outputs (0major+16000minor)pagefaults 0swaps

This version does not invalidate the cache in the presense of
modified grafts and object replacement, but in a later version we
can compute a hash of the grafts and replacement data and pass it as
the validity token to automatically invalidate the cache when these
data that affects the perceived topology change.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
name-rev --algorithm=weight: tests and documentation

We are almost there...

Signed-off-by: Junio C Hamano <gitster@pobox.com>
describe --contains: use "name-rev --algorithm=weight"

And this is the logical conclusion of the series, to
allow 0136db586c in the kernel history to be described
as v3.5-rc1~83^2~81^2~76, not as v3.6-rc1~59^2~56^2~76.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty: make some commit-parsing helpers more public

This is a quick hack to make these functions available for
the lua code. It would be way cleaner to move all of the
incremental parsing bits to format-commit.[ch] and clean up
the names (e.g., "struct chunk" is not nearly descriptive
enough for a global).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
add basic lua infrastructure

This adds a small module for examining parts of a commit
from inside a lua interpreter. Eventually you'll be able to
do grep-like filtering and --pretty formatting.

The most naive presentation would be to parse the whole
commit and put it in a lua table. However, instead we build
upon the incremental parsing used by the --format parser,
and lazily parse bits of the commit as the lua code requests
them.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
add a "lua" pretty format

With this patch, you can do:

  git log --pretty=lua:'
    return abbrev(hash()) .. " (" .. author().email .. ") " .. subject()
  '

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile: make "lua" a bit more configurable

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

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