branch: trivial cleanup

No functional changes.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
branch: reorganize verbose options

Showing the upstream tracking branch is more important than how many
commits are ahead/behind, so now 'git branch -v' shows the upstream, but
not the tracking info, and 'git branch -vv' shows all information (as
before).

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
push: trivial reorganization

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Add concept of 'publish' branch

The upstream branch is:

  branch.$name.remote
  branch.$name.merge

The publish branch is:

  branch.$name.pushremote
  branch.$name.push

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
branch: allow configuring the publish branch

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
t: branch add publish branch tests

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
push: add --set-publish option

To setup publish tracking branch, like 'git branch --set-publish'.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
branch: display publish branch

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
sha1-name: pass len argument to interpret_branch_name()

This is useful to make sure we don't step outside the boundaries of what
we are interpreting at the moment. For example while interpreting
foobar@{u}~1, the job of interpret_branch_name() ends right before ~1,
but there's no way to figure that out inside the function, unless the
len argument is passed.

So let's do that.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add new @ shortcut for HEAD

Typing 'HEAD' is tedious, especially when we can use '@' instead.

The reason for choosing '@' is that it follows naturally from the
ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no
operation, and when we don't have those, it makes sens to assume
'HEAD'.

So now we can use 'git show @~1', and all that goody goodness.

Until now '@' was a valid name, but it conflicts with this idea, so
let's make it invalid. Probably very few people, if any, used this name.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pull: rename pull.rename to pull.mode

Also 'branch.<name>.rebase' to 'branch.<name>.pullmode'.

This way 'pull.mode' can be set to 'merge', and the default can be
something else.

The old configurations still work, but get deprecated.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
pull: refactor $rebase variable into $mode

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
pull: add --merge option

Also, deprecate --no-rebase since there's no need for it any more.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
pull: add merge-ff-only option

It is very typical for Git newcomers to inadvertently create merges and
worst; inadvertently pushing them. This is one of the reasons many
experienced users prefer to avoid 'git pull', and recommend newcomers to
avoid it as well.

To avoid these problems and keep 'git pull' useful, it has been
suggested that 'git pull' barfs by default if the merge is
non-fast-forward, which unfortunately would break backwards
compatibility.

This patch leaves everything in place to enable this new mode, but it
only gets enabled if the user specifically configures it; pull.mode =
merge-ff-only.

Later on this mode can be enabled by default (e.g. in v2.0).

For the full discussion you can read:

http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225305

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Add core.mode configuration

So that we can specify general modes of operation, specifically, add the
'next' mode, which makes Git pre v2.0 behave as Git v2.0.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
pull: add warning on non-ff merges

To prepare our uses for the upcoming changes we should warn them and let
them know that they will need to specify a merge or a rebase in the
future (when a non-fast-forward situation arises). Also, let them know
we fallback to 'git pull --merge', so when the obsoletion of this mode
comes, they know what to type without interrupting or changing their
workflow.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
pull: cleanup documentation

'origin/master' is very clear, no need to specify the 'remotes/' prefix,
or babysit the user.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
pull: add documentation about non-ff merges

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Add proper 'stage' command

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
stage: add edit command

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>