Several people have suggested that its always better to describe
a commit using an annotated tag, and to only use a lightweight tag
if absolutely no annotated tag matches the input commit.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

1) talk about "git merge" instead of "git pull ."

2) suggest "git repo-config" instead of directly editing config files

3) echo "URL: blah" > .git/remotes/foo is obsolete and should be
   "git repo-config remote.foo.url blah"

4) support for partial URL prefix has been removed (see commit
   ea560e6d) so drop mention of it.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We say "this shows only the most often used ones"; so instead of
teaching --max-number=<n> form, list -<n> form which is much
easier to type.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Now that we are showing the output messages for verbosity levels
<5 after all actions have been performed (due to the progress meter
running during the actions) it can be confusing to see messages in
the present tense when the user is looking at a '100% done' message
right above them.  Converting the messages to past tense will appear
more correct in this case, and shouldn't affect a developer who is
debugging the application and running it at a verbosity level >=5.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Because large merges on slow systems can take up to a minute to
execute we should try to keep the user entertained with a progress
meter to let them know how far we have progressed through the
current merge.

The progress meter considers each entry in the in-memory index to
be a unit, which means a single recursive merge will double the
number of units in the progress meter.  Files which are unmerged
after the 3-way tree merge are also considered a unit within the
progress meter.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Buffering all message output until a merge invocation is complete is
necessary to prevent intereferring with a progress meter that would
indicate the number of files completely merged, and how many remain.
This change does not introduce a progress meter, but merely lays
the groundwork to buffer the output.

To aid debugging output buffering is only enabled if verbosity
is lower than 5.  When using verbosity levels above 5 the user is
probably debugging the merge program itself and does not want to
see the output delayed, especially if they are stepping through
portions of the code in a debugger.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Junio C Hamano <junkio@cox.net> writes:
>
> I think the output from merge-recursive can be categorized into 5
> verbosity levels:
>
> 1. "CONFLICT", "Rename", "Adding here instead due to D/F conflict"
> (outermost)
>
> 2. "Auto-merged successfully" (outermost)
>
> 3. The first "Merging X with Y".
>
> 4. outermost "Merging:\ntitle1\ntitle2".
>
> 5. outermost "found N common ancestors\nancestor1\nancestor2\n..."
> and anything from inner merge.
>
> I would prefer the default verbosity level to be 2 (that is, show
> both 1 and 2).

and this change makes it so.  I think level 3 is probably pointless
as its only one line of output above level 2, but I can see how some
users may want to view it but not view the slightly more verbose
output of level 4.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Because the output_indent always matches the call_depth value
there is no reason to pass around the call_depth to the merge
function during each recursive invocation.

This is a simple refactoring that will make the code easier to
follow later on as I start to add output verbosity controls.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/int:
  More tests in t3901.
  Consistent message encoding while reusing log from an existing commit.
  t3901: test "format-patch | am" pipe with i18n
  Use log output encoding in --pretty=email headers.

* 'sp/merge' (early part):
  Improve merge performance by avoiding in-index merges.

* jc/subdir:
  Allow whole-tree operations to be started from a subdirectory
  Use cd_to_toplevel in scripts that implement it by hand.
  Define cd_to_toplevel shell function in git-sh-setup

Originally I introduced read_or_die for the purpose of reading
the pack header and trailer, and I was too lazy to print proper
error messages.

Linus Torvalds <torvalds@osdl.org>:
> For a read error, at the very least you have to say WHICH FILE
> couldn't be read, because it's usually a matter of some file just
> being too short, not some system-wide problem.

and of course Linus is right. Make it so.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If the user doesn't have SVN::Core installed or working then the
SVN tests properly turn themselves off.  But the user doesn't need
to know that SVN::Core isn't loadable as a Perl module.  Unless of
course they are trying to debug the test, so lets relegate the Perl
failures to --verbose only.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Suggesting the use of [-a|-i|-o] with git-commit is unnecessarily
complex and confusing.  In this context -o is totally useless and -i
requires extra arguments which are not mentioned.  The only sensible
hint (besides reading the man page but let's not go there) is
"commit -a".
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds tests for "cherry-pick" and "rebase --merge" (and
indirectly "commit -C" since it is used in the latter) to make
sure they create a new commit with correct encoding.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The following commands can reuse log message from an existing
commit while creating a new commit:

	git-cherry-pick
	git-rebase (both with and without --merge)
	git-commit (-c and -C)

When the original commit was made in a different encoding from
the current i18n.commitencoding, "cat-file commit" would give a
string that is inconsistent with what the resulting commit will
claim to be in.  Replace them with "git show -s --encoding".

"git-rebase" without --merge is "git format-patch" piped to "git
am" in essence, and has been taken care of before this commit.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

This checks combinations of i18n.commitencoding (declares what
encoding you are feeding commit-tree to make commits) and
i18n.logoutputencoding (instructs what encoding to emit the
commit message out to log output, including e-mail format) to
make sure the "format-patch | am" pipe used in git-rebase works
correctly.

I suspect "git cherry-pick" and "git rebase --merge" may fail
similar tests.  We'll see.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Private functions add_rfc2047() and pretty_print_commit() assumed
they are only emitting UTF-8.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NQuy Tonthat <qtonthat@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Some of the recent changes and shortcuts to the tests broke
things for people using older versions of svn:

t9104-git-svn-follow-parent.sh:
  v1.2.3 (from SuSE 10.0 as reported by riddochc on #git
  (thanks!)) required an extra 'svn up'.  I was also able to
  reproduce this with v1.1.4 (Debian Sarge).

lib-git-svn.sh:
  SVN::Repos bindings in versions up to and including 1.1.4
  (Sarge again) do not pass fs-config options to the underlying
  library.  BerkeleyDB repositories also seem completely broken
  on all my Sarge machines; so not using FSFS does not seem to
  be an option for most people.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This updates five commands (merge, pull, rebase, revert and cherry-pick)
so that they can be started from a subdirectory.

This may not actually be what we want to do.  These commands are
inherently whole-tree operations, and an inexperienced user may
mistakenly expect a "git pull" from a subdirectory would merge
only the subdirectory the command started from.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This converts scripts that do "cd $(rev-parse --show-cdup)" by
hand to use cd_to_toplevel.

I think git-fetch does not have to go to the toplevel, but that
should be dealt with in a separate patch.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Steven Grimm noticed that git-repack's verbosity is inconsistent
because pack-objects is chatty and prune-packed is not.  This
makes the latter a bit more chatty and gives -q option to
squelch it.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Pointed out by Paul Witt <paul.witt@oxix.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

While 'init-db' still is and probably will always remain a valid git
command for obvious backward compatibility reasons, it would be a good
idea to move shipped tools and docs to using 'init' instead.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Andy Parkins noticed that the error message some "whole tree"
oriented commands emit is stated misleadingly when they refused
to run from a subdirectory.

We could probably allow some of them to work from a subdirectory
but that is a semantic change that could have unintended side
effects, so let's start at first by rewording the error message
to be easier to read without doing anything else to be safe.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It is not available in the outermost merge, and it is only
useful for debugging merge-recursive in the inner merges.

Sergey Vlasov noticed that the old code accesses an
uninitialized location.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The code previously checked it's own name and called 'die' upon
an error.  However 'die' was not yet defined because git-sh-setup
had not been sourced yet.  Instead simply write the error message
to stderr and exit with an error as was originally desired.
Signed-off-by: NBob Proulx <bob@proulx.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Despite what the documentation claims, git-commit does not check commit
for suspicious lines: all hooks are disabled by default,
and the pre-comit hook could be changed to do something else.
Signed-off-by: NMichael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The "read_or_die()" function would silently NOT die for a partial read,
and since it was of type "void" it obviously couldn't even return the
partial number of bytes read.

IOW, it was totally broken. This hopefully fixes it up.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

With the new-and-improved write_in_full() semantics, where a partial write
simply always returns a real error (and always sets 'errno' when that
happens, including for the disk full case), a lot of the callers of
write_in_full() were just unnecessarily complex.

In particular, there's no reason to ever check for a zero length or
return: if the length was zero, we'll return zero, otherwise, if a disk
full resulted in the actual write() system call returning zero the
write_in_full() logic would have correctly turned that into a negative
return value, with 'errno' set to ENOSPC.

I really wish every "write_in_full()" user would just check against "<0"
now, but this fixes the nasty and stupid ones.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When --stale-fix is not passed, the code did not initialize the
two commit objects properly.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Recently git.git itself encountered a situation on its master and
next branches where git-describe stopped reporting 'v1.5.0-rc0-gN'
and instead started reporting 'v1.4.4.4-gN'.  This appeared to be
a backward jump in version numbering.

  maint     o-------------------4
            \                    \
  master     o-o-o-o-o-o-o-5-o-C-o-W

The issue is that commit C in the diagram claims it is version
1.5.0, as the tag v1.5.0 is placed on commit 5.  Yet commit W
claims it is version 1.4.4.4 as the tag v1.5.0 has an older tag
date than the v1.4.4.4 tag.

As it turns out this situation is very common.  A bug fix applied
to maint and later merged into master occurs frequently enough that
it should Just Work Right(tm).

Rather than taking the first tag that gets found git-describe will
now generate a list of all possible tags and select the one which
has the most number of commits in common with HEAD (or whatever
revision the user requested the description of).

This rule is based on the principle shown in the diagram above.
There are a large number of commits on the primary development branch
'master' which do not appear in the 'maint' branch, and many of
these are already tagged as part of v1.5.0-rc0.  Additionally these
commits are not in v1.4.4.4, as they are part of the v1.5.0 release
still being developed.  The v1.5.0-rc0 tag is more descriptive of
W than v1.4.4.4 is, and therefore should be used.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/bare:
  Disallow working directory commands in a bare repository.
  git-fetch: allow updating the current branch in a bare repository.
  Introduce is_bare_repository() and core.bare configuration variable
  Move initialization of log_all_ref_updates

* ar/merge-recursive:
  merge-recursive: do not use on-file index when not needed.
  Speed-up recursive by flushing index only once for all entries

* jc/detached-head:
  git-checkout: handle local changes sanely when detaching HEAD
  git-checkout: safety check for detached HEAD checks existing refs
  git-checkout: fix branch name output from the command
  git-checkout: safety when coming back from the detached HEAD state.
  git-checkout: rewording comments regarding detached HEAD.
  git-checkout: do not warn detaching HEAD when it is already detached.
  Detached HEAD (experimental)
  git-branch: show detached HEAD
  git-status: show detached HEAD