git-shortlog.txt: remove (-h|--help) from OPTIONS

To be consistent with the documentation of all the other commands,
remove (-h|--help) from the OPTIONS section.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
glossary: a revision is just a commit

The current definition of 'revision' sounds like it is saying that a
revision is a tree object.  In reality it is just a commit.

This should be especially useful for people used to other revision
control systems trying to see how familiar concepts translate into git
terms.

Reported-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
revisions.txt: clarify the .. and ... syntax

In <rev1>..<rev2> and <rev1>...<rev2>, if either <rev1> or <rev2> is
omitted, it defaults to 'HEAD'.  Add this detail to the document.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-log.txt: order OPTIONS properly; move <since>..<until>

The OPTIONS section lists <since>..<until> as the first item, but this
is inconsistent with the ordering in SYNOPSIS.  Move it down until it
appears just before [[--] <path>...].

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-log.txt: generalize <since>..<until>

'<since>..<until>' is misleading, as there are many other forms that
'git log' can accept as an argument.  Replace it with <revision range>,
referring to the section "Specifying Ranges" in revisions.txt, and
rewrite the section appropriately.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-log.txt: rewrite note on why "--" may be required

In its current form, the note talks about separating options from
"branch names" and "refnames" in the same sentence.  This is entirely
inaccurate, as <revision range> need not be a set of branch names or
ref names.  Rewrite it to use the word "revision range", to be
consistent with the SYNOPSIS.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-shortlog.txt: make SYNOPSIS match log, update OPTIONS

There are broadly two problems with the current SYNOPSIS.  First, it
completely omits the detail that paths can be specified.  Second, it
attempts to list all the options: this is futile as, in addition to
the options unique to it, it accepts all the options that git-rev-list
accepts.  In fixing these problems, make the SYNOPSIS consistent with
that in git-log.txt.  Also add the corresponding sections to OPTIONS.
Save adding the options from rev-list-options.txt for a later patch,
as it requires some work to pick out the options that are relevant to
shortlog.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/log.c: make usage string consistent with doc

Replace '<since>..<until>' with '<revision range>', in accordance with
the documentation.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/shortlog.c: make usage string consistent with log

"--" is used to separate pathspecs from the rev specs, and not rev
specs from the options, as the shortlog_usage string currently
indicates.  In correcting this usage string, make it consistent with
the log_usage string.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git add: --ignore-removal is a better named --no-all

In the historical context of "git add --all ." that pays attention
to "all kinds of changes" (implying "without ignoring removals"),
the option to countermand it "--no-all" may have made sense, but
because we will be making "--all" the default when a pathspec is
given, it makes more sense to rename the option to a more explicit
"--ignore-removal".  The "--all" option naturally becomes its
negation, "--no-ignore-removal".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
git add: rephrase -A/--no-all warning

Now we have a synonym --ignore-removal for --no-all, we can rephrase
the Git 2.0 transition warning message in a more natural way.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-helpers: avoid has_key

It is deprecated.

[fc: do the same in remote-bzr]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-hg: safer bookmark pushing

It is possible that the remote has changed the bookmarks, so let's fetch
them before we make any assumptions, just the way mercurial does.

Probably doesn't make a difference, but better be safe than sorry.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-hg: use python urlparse

It's simpler, and we don't need to depend on certain Mercurial versions.

Also, now we don't update the URL if 'file://' is not present.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-hg: properly mark branches up-to-date

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-hg: add branch_tip() helper

Idea from gitifyhg, the backwards compatibility is how Mercurial used to
do it.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-hg: add support for tag objects

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-hg: custom method to write tags

The one from mercurial is meant for users, on top of the latest tip.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-hg: write tags in the appropriate branch

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-hg: add custom local tag write code

There's no point in calling the tag method for such simple action. Not
that we care much about the hg-git compat mode, it's mostly just for
comparison testing purposes.

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