* git://git.kernel.org/pub/scm/gitk/gitk:
  gitk: Better workaround for arrows on diagonal line segments
  gitk: Allow top panes to scroll horizontally with mouse button 2
  gitk: Prevent parent link from overwriting commit headline
  gitk: Show diffs for boundary commits
  gitk: Use the new --boundary flag to git-rev-list

Instead of adding extra padding to create a vertical line segment at
the lower end of a line that has an arrow, this now just draws a very
short vertical line segment at the lower end.  This alternative
workaround for the Tk8.4 behaviour (not drawing arrows on diagonal
line segments) doesn't have the problem of making the graph very wide
when people do a lot of merges in a row (hi Junio :).
Signed-off-by: NPaul Mackerras <paulus@samba.org>

We chdir internally, so we need a consistent GIT_DIR variable.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

git-clone without a repo isn't useful at all.  print message and get
out asap.

This patch also move the variable 'local' to where other variables are
initialized.
Signed-off-by: NYasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

git-clone currently take option '-o' to specify origin.  this patch
makes git-clone to take double-dashed option '--origin' and other
abbreviations in addtion to the current single-dashed option.

[jc: with minor fixups]
Signed-off-by: NYasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPaul Mackerras <paulus@samba.org>

When I made drawlineseg responsible for drawing the link to the first
child rather than drawparentlinks, that meant that the right-most X
value computed by drawparentlinks didn't include those first-child
links, and thus the first-child link could go over the top of the
commit headline.  This fixes it.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

With this we run git-diff-tree on a commit even if we think it has
no parents, either because it really has no parents or because it
is a boundary commit.  This means that gitk shows the diff for a
boundary commit when it is selected.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Introduce tree-walk.[ch] and move "struct tree_desc" and
associated functions from various places.

Rename DIFF_FILE_CANON_MODE(mode) macro to canon_mode(mode) and
move it to cache.h.  This macro returns the canonicalized
st_mode value in the host byte order for files, symlinks and
directories -- to be compared with a tree_desc entry.
create_ce_mode(mode) in cache.h is similar but is intended to be
used for index entries (so it does not work for directories) and
returns the value in the network byte order.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When the executable bit is untrustworthy and when we are
comparing the tree with the working tree, we tried to reuse the
mode bits recorded in the index incorrectly (the computation was
bogus on little endian architectures).  Just use mode from index
when it is a regular file.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

With this, we can show the boundary (open-circle) commits immediately
after their last child, which looks much better than putting all the
boundary commits at the bottom of the graph.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The earlier change to make "..B" to mean "HEAD..B" (aka ^HEAD B)
has constness gotcha GCC complains.  Fix it.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

For consistency reasons, we should probably allow that to be written as
just "..branch", the same way we can write "branch.." to mean "everything
in HEAD but not in "branch".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

With the new --boundary flag, the output from rev-list includes
the UNINTERESING commits at the boundary, which are usually not
shown.  Their object names are prefixed with '-'.

For example, with this graph:

              C side
             /
	A---B---D master

You would get something like this:

	$ git rev-list --boundary --header --parents side..master
	D B
        tree D^{tree}
        parent B
        ... log message for commit D here ...
        \0-B A
        tree B^{tree}
        parent A
        ... log message for commit B here ...
        \0
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We do not need to track object refs, neither we need to save commit
unless we are doing verbose header.  A lot of traversal happens
inside prepare_revision_walk() these days so setting things up before
calling that function is necessary.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Acked-by: NLinus Torvalds <torvalds@osdl.org>

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

The speed of the built-in diff generator is nice; but the function names
shown by `diff -p' are /really/ nice.  And I hate having to choose.  So,
we hack xdiff to find the function names and print them.

xdiff has grown a flag to say whether to dig up the function names.  The
builtin_diff function passes this flag unconditionally.  I suppose it
could parse GIT_DIFF_OPTS, but it doesn't at the moment.  I've also
reintroduced the `function name' into the test suite, from which it was
removed in commit 3ce8f089.

The function names are parsed by a particularly stupid algorithm at the
moment: it just tries to find a line in the `old' file, from before the
start of the hunk, whose first character looks plausible.  Still, it's
most definitely a start.
Signed-off-by: NMark Wooding <mdw@distorted.org.uk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

For some reason, I need ALL_LDFLAGS in the git target only on
AIX.  Once it builds, only one test "fails" on AIX 5.1 with
1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some
odd tool problem in the tester + my setup and not a real bug.
Signed-off-by: NJason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

All of the things that were not in the "master" branch were
either cooked long enough in "next" without causing problems
(e.g. insanely fast rename detector or true built-in diff) or
isolated in a specific subsystem (e.g. tar-tree and svnimport).

So I am clearing the deck to prepare for a 1.3.0.  Remaining
wrinkles, if any, will be ironed in the "master" branch.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* lt/diffgen:
  add clean and ignore rules for xdiff/
  Remove dependency on a file named "-lz"

* master:
  Optionally do not list empty directories in git-ls-files --others
  Document git-rebase behavior on conflicts.
  Fix error handling for nonexistent names

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

Without the --directory flag, git-ls-files wouldn't ever list directories,
producing no output for empty directories, which is good since they cannot
be added and they bear no content, even untracked one (if Git ever starts
tracking directories on their own, this should obviously change since the
content notion will change).

With the --directory flag however, git-ls-files would list even empty
directories. This may be good in some situations but sometimes you want to
prevent that. This patch adds a --no-empty-directory option which makes
git-ls-files omit empty directories.
Signed-off-by: NPetr Baudis <pasky@suse.cz>

By changing the dependency "$(LIB_H)" to "$(LIBS)", at least one version
of make thought that a file named "-lz" would be needed.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When passing in a pathname pattern without the "--" separator on the
command line, we verify that the pathnames in question exist. However,
there were two bugs in that verification:

 - git-rev-parse would only check the first pathname, and silently allow
   any invalid subsequent pathname, whether it existed or not (which
   defeats the purpose of the check, and is also inconsistent with what
   git-rev-list actually does)

 - git-rev-list (and "git log" etc) would check each filename, but if the
   check failed, it would print the error using the first one, i.e.:

	[torvalds@g5 git]$ git log Makefile bad-file
	fatal: 'Makefile': No such file or directory

   instead of saying that it's 'bad-file' that doesn't exist.

This fixes both bugs.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/thin:
  git-push: make --thin pack transfer the default.
  gitk: Fix two bugs reported by users
  gitk: Improve appearance of first child links
  gitk: Make downward-pointing arrows end in vertical line segment
  gitk: Don't change cursor at end of layout if find in progress
  gitk: Make commitdata an array rather than a list
  gitk: Fix display of diff lines beginning with --- or +++
  [PATCH] gitk: Make error_popup react to Return
  gitk: Fix a bug in drawing the selected line as a thick line
  gitk: Further speedups
  gitk: Various speed improvements
  gitk: Fix Update menu item
  gitk: Fix clicks on arrows on line ends
  gitk: New improved gitk
  contrib/git-svn: stabilize memory usage for big fetches

Just in case it has problems, you can say "git push --no-thin".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/clone:
  git-clone: typofix.
  clone: record the remote primary branch with remotes/$origin/HEAD
  revamp git-clone (take #2).
  revamp git-clone.
  fetch,parse-remote,fmt-merge-msg: refs/remotes/* support

* jc/name:
  sha1_name: make core.warnambiguousrefs the default.
  sha1_name: warning ambiguous refs.
  get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
  core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.

* jc/merge:
  git-merge knows some strategies want to skip trivial merges

* lt/diffgen:
  true built-in diff: run everything in-core.

git-svnimport will import the same revision over and over again if a
limit (-l <rev>) has been specified. Instead if that revision has already
been processed, exit with an up-to-date message.
Signed-off-by: NAnand Kumria <wildfire@progsoc.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* git://git.kernel.org/pub/scm/gitk/gitk:
  gitk: Fix two bugs reported by users
  gitk: Improve appearance of first child links
  gitk: Make downward-pointing arrows end in vertical line segment
  gitk: Don't change cursor at end of layout if find in progress
  gitk: Make commitdata an array rather than a list
  gitk: Fix display of diff lines beginning with --- or +++
  [PATCH] gitk: Make error_popup react to Return
  gitk: Fix a bug in drawing the selected line as a thick line
  gitk: Further speedups
  gitk: Various speed improvements
  gitk: Fix Update menu item
  gitk: Fix clicks on arrows on line ends
  gitk: New improved gitk

This stops using temporary files when we are using the built-in
diff (including the complete rewrite).
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We should be safely able to import histories with thousands
of revisions without hogging up lots of memory.

With this, we lose the ability to autocorrect mistakes when
people specify revisions in reverse, but it's probably no longer
a problem since we only have one method of log parsing nowadays.

I've added an extra check to ensure that revision numbers do
increment.

Also, increment the version number to 0.11.0.  I really should
just call it 1.0 soon...
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* ew/email:
  send-email: lazy-load Email::Valid and make it optional
  send-email: try to order messages in email clients more correctly
  send-email: Change from Mail::Sendmail to Net::SMTP
  send-email: use built-in time() instead of /bin/date '+%s'

* lt/diffgen:
  built-in diff: minimum tweaks
  builtin-diff: \No newline at end of file.
  Use a *real* built-in diff generator

* rs/tar-tree:
  tar-tree: Use the prefix field of a tar header
  tar-tree: Remove obsolete code
  tar-tree: Use write_entry() to write the archive contents
  tar-tree: Introduce write_entry()
  tar-tree: Use SHA1 of root tree for the basedir
  git-apply: safety fixes
  Removed bogus "<snap>" identifier.
  Clarify and expand some hook documentation.
  commit-tree: check return value from write_sha1_file()
  send-email: Identify author at the top when sending e-mail
  Format tweaks for asciidoc.

It's not installed on enough machines, and is overkill most of
the time.  We'll fallback to a very basic regexp just in case,
but nothing like the monster regexp Email::Valid has to offer :)

Small cleanup from Merlyn.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>