Remove extra whitespace between the change indicators and the
body text.  That is more in line with the uncombined unified
diff output (pointed out by Santi Bejar).

When showing --cc, say so instead of saying just --combined.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

... and use the established pattern of tail initialized to point
at the head pointer for an empty list, and updated to point at
the next pointer field of the item at the tail when appending.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Building on the previous '-c' (combined) option, '--cc' option
squelches the output further by omitting hunks that consist of
difference with solely one parent.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

A new option '-c' to diff-tree changes the way a merge commit is
displayed when generating a patch output.  It shows a "combined
diff" (hence the option letter 'c'), which looks like this:

    $ git-diff-tree --pretty -c -p fec9ebf1 | head -n 18
    diff-tree fec9ebf1... (from parents)
    Merge: 0620db36... 8a263aeb...
    Author: Junio C Hamano <junkio@cox.net>
    Date:   Sun Jan 15 22:25:35 2006 -0800

	Merge fixes up to GIT 1.1.3

    diff --combined describe.c
    @@@ +98,7 @@@
	    return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
       }

    -  static void describe(char *arg)
     - static void describe(struct commit *cmit, int last_one)
    ++ static void describe(char *arg, int last_one)
       {
     +      unsigned char sha1[20];
     +      struct commit *cmit;

There are a few things to note about this feature:

 - The '-c' option implies '-p'.  It also implies '-m' halfway
   in the sense that "interesting" merges are shown, but not all
   merges.

 - When a blob matches one of the parents, we do not show a diff
   for that path at all.  For a merge commit, this option shows
   paths with real file-level merge (aka "interesting things").

 - As a concequence of the above, an "uninteresting" merge is
   not shown at all.  You can use '-m' in addition to '-c' to
   show the commit log for such a merge, but there will be no
   combined diff output.

 - Unlike "gitk", the output is monochrome.

A '-' character in the nth column means the line is from the nth
parent and does not appear in the merge result (i.e. removed
from that parent's version).

A '+' character in the nth column means the line appears in the
merge result, and the nth parent does not have that line
(i.e. added by the merge itself or inherited from another
parent).

The above example output shows that the function signature was
changed from either parents (hence two "-" lines and a "++"
line), and "unsigned char sha1[20]", prefixed by a " +", was
inherited from the first parent.

The code as sent to the list was buggy in few corner cases,
which I have fixed since then.

It does not bother to keep track of and show the line numbers
from parent commits, which it probably should.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The files with conflicts need to be hand resolved, and it is a
good discipline for the committer to explain which branch was
taken and why.  Pre-fill the merge message template with the
list of conflicted paths to encourage it.

This is from Linus.
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>

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

If the index records an insanely long symbolic link, copying
into the temporary would overflow the buffer (noticed by Mark
Wooding).

Because read_sha1_file() terminates the returned buffer with NUL
since late May 2005, there is no reason to copy it anymore.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Needs iconv and third party lib/headers are inside /usr/local
Signed-off-by: NAlecs King <alecsk@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Commit 5c7d3c95 broke that by making the git-describe command part of
a pipe.
Signed-off-by: NUwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NUwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NUwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Johannes noticed the recent addition of this new flag
inadvertently took over existing --update-head-ok (-u).  Require
longer abbreviation to this new option which would be needed in
a rare setup.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This makes read_tree_recursive and read_tree take a struct tree
instead of a buffer. It also move the declaration of read_tree into
tree.h (where struct tree is defined), and updates ls-tree and
diff-index (the only places that presently use read_tree*()) to use
the new versions.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Implement a (slow) unsetenv() for older systems.
Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Alas, not all shells named sh are capable enough to run
GIT-VERSION-GEN.
Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

In the last round of bug fixes the signed-off-by line was still be
generated but it was not including a signed-off-by line :(
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

If we get an error parsing the arguments, exit.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If you pass it a filename without the "--" marker to separate it from
revision information and flags, we now require that the file in question
actually exists. This makes mis-typed revision information not be silently
just considered a strange filename.

With the "--" marker, you can continue to pass in filenames that do not
actually exists - useful for querying what happened to a file that you
no longer have in the repository.

[ All scripts should use the "--" format regardless, to make things
  unambiguous. So this change should not affect any existing tools ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

remove environment variables relating to the current repository
before execing the 'remote' half of a local push or pull operation

[jc: the original from Matt spelled out the environment variable
 names, which I changed to the preprocessor symbols defined in
 cache.h.  Also it missed GRAFT_ENVIRONMENT.]
Signed-off-by: NJunio C Hamano <junkio@cox.net>

git-peek-remote needs to handle a -u|--upload-pack parameter just like
git-fetch (and git-fetch has to pass it on to git-peek-remote).

(This is actually a follow-up to my previous git-fetch patch.)
Signed-off-by: NMichal Ostrowski <mostrows@heater.watson.ibm.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Without this, there is no way to specify a remote executable when
invoking git-pull/git-fetch as there is for git-clone.

[jc: I have a mild suspicion that this is a broken environment (aka
 sysadmin disservice).  It may be legal to configure your sshd to
 spawn named program without involving shell at all, and if your
 sysadmin does so and you have your git programs under your home
 directory, you would need something like this, but then I suspect
 you would need such workaround everywhere, not just git. But we
 have these options we can use to work around the issue, so there
 is no strong reason not to reject this patch, either. ]
Signed-off-by: NMichal Ostrowski <mostrows@watson.ibm.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

It is simply pointless, since no merges will ever happen in such
a repository.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

asciidoc 7.0.4 and newer considers such includes from parent directory
unsafe.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Instead of showing all the history since the beginning of time
leading to the the branch head, show only the changes this new
branch brings to the world.

This originally came from Linus and tested by Andreas Ericsson.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is the update hook we use in all our git-repos.

It has some improvements over the original version, namely:
* Don't send every commit since dawn of time when adding a new tag.
* When updating an annotated tag, just send the diffs since the last tag.
* Add diffstat output for 'normal' commits (top) and annotated tags (bottom).
* Block un-annotated tags in shared repos.

I'm a bit uncertain about that last one, but it demonstrates how to
disallow updates of a ref which we use, so I kept it.

Note that git-describe is needed for the "changes since last annotated tag"
thing to work.
Signed-off-by: NAndreas Ericsson <ae@op5.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We forgot to update the primary link from git.html leading to
the tutorial, and also forgot to build and install the renamed
core-tutorial document.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It is a common mistake to leave an unsed `origin` branch behind
if a shared public repository was created by first cloning from
somewhere else.  Subsequent `git push` into it with the default
"push all the matching ref" would push the `origin` branch from
the developer repository uselessly.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The current Documentation/tutorial.txt concentrates on the lower-level
git interfaces.  So it's useful to people developing alternative
porcelains, to advanced users, etc., but not so much to beginning users.

I think it makes sense for the main tutorial to address those
beginnning users, so with this patch I'm proposing that we move
Documentation/tutorial.txt to Documentation/core-tutorial.txt and
replace it by a new tutorial.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We forgot to make sure that there is no more than one pattern
parameter.  Also when looking for files in a directory called
'--others', it passed that path limiter without preceding the
end-of-options marker '--' to underlying git-ls-files, which
misunderstood it as one of its options instead.

	$ git grep --others -e Meta/Make Meta
	$ git grep -o -e Meta/Make Meta
	$ git grep -o Meta/Make Meta

look for a string "Meta/Make" from untracked files in Meta/
directory.

	$ git grep Meta/Make --others

looks for the same string from tracked files in ./--others
directory.

On the other hand,

	$ git grep -e Meta/Make --others

does not have a freestanding pattern, so everybody is parameter
and there is no path specifier.  It looks for the string in all
the untracked files without any path limiter.

[jc: updated with usability enhancements and documentation
cleanups from Sean.]
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When overriding DT_* macro detection with NO_D_TYPE_IN_DIRENT (recent
Cygwin build problem, which hopefully is already fixed in their CVS
snapshot version), we define DTYPE() macro to return just "we do not
know", but still needed to use DT_* macro to avoid ifdef in the code
we use them.  If the platform defines DT_* macro but with unusable
d_type, this would have resulted in us redefining these preprocessor
symbols.

Admittedly, that would be just a couple of compilation warnings, and
on Cygwin at least this particular problem is transitory (the problem
is already fixed in their CVS snapshot version), so this is a low
priority fix.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This test depended on "sleep 1" to be enough to dirty the index
entry for a symlink.  Alex noticed that on his Cygwin installation
"sleep 1" was sometimes not enough, and after further discussion with
Christopher Faylor, it was brought up that on FAT filesystem timestamp
granularity is 2 seconds so sleeping 1 second is not enough.

For now this patch takes an easy workaround of sleeping for 3 seconds.

Very strictly speaking, POSIX requires lstat to fill only S_IFMT part
of st_mode and st_size for symlinks, and depending on timestamp might
be considered a bug, but we depend on that anyway, so it is better to
test that.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The recent Cygwin defines DT_UNKNOWN although it does not have d_type
in struct dirent.  Give an option to tell us not to use d_type on such
platforms.  Hopefully this problem will be transient.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The d_ino field is only used for performance reasons in
fsck-objects.  On a typical filesystem, i-number tends to have a
strong correlation with where the actual bits sit on the disk
platter, and we sort the entries to allow us scan things that
ought to be close together together.

If the platform lacks support for it, it is not a big deal.
Just do not use d_ino for sorting, and scan them unsorted.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Noticed first by Alex, that the latest Cygwin now properly has
sockaddr_storage.
Signed-off-by: NJunio C Hamano <junkio@cox.net>