GIT 1.3.0-rc3

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

Merge branch 'kh/svn'

* kh/svn:
  git-svnimport: Don't assume that copied files haven't changed

Merge branch 'jc/thinpack'

* jc/thinpack:
  Thin pack generation: optimization.

Merge branch 'jc/date'

* jc/date:
  date parsing: be friendlier to our European friends.

Merge branch 'nh/http'

* nh/http:
  Fix compile with expat, but an old curl version
  http-fetch: add optional DAV-based pack list

Merge branch 'ew/rev-abbrev'

* ew/rev-abbrev:
  rev-list --abbrev-commit

Merge branch 'jc/blame'

* jc/blame:
  blame -S <ancestry-file>
  Match ofs/cnt types in diff interface.
  blame: use built-in xdiff
  combine-diff: move the code to parse hunk-header into common library.
  combine-diff: refactor built-in xdiff interface.
  combine-diff: use built-in xdiff.

Merge git://git.kernel.org/pub/scm/gitk/gitk

* git://git.kernel.org/pub/scm/gitk/gitk:
  gitk: Fix incorrect invocation of getmergediffline
  [PATCH] gitk: Fix searching for filenames in gitk

Merge branch 'maint'

* maint:
  count-delta: match get_delta_hdr_size() changes.
  check patch_delta bounds more carefully

count-delta: match get_delta_hdr_size() changes.

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

check patch_delta bounds more carefully

Let's avoid going south with invalid delta data.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-svnimport: Don't assume that copied files haven't changed

Don't assume that a file that SVN claims was copied from somewhere
else is bit-for-bit identical with its parent, since SVN allows
changes to copied files before they are committed.

Without this fix, such copy-modify-commit operations causes the
imported file to lack the "modify" part -- that is, we get subtle data
corruption.

Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

rev-list --abbrev-commit

This should make --pretty=oneline a whole lot more readable for
people using 80-column terminals.  Originally from Eric Wong.

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

Thin pack generation: optimization.

Jens Axboe noticed that recent "git push" has become very slow
since we made --thin transfer the default.

Thin pack generation to push a handful revisions that touch
relatively small number of paths out of huge tree was stupid; it
registered _everything_ from the excluded revisions.  As a
result, "Counting objects" phase was unnecessarily expensive.

This changes the logic to register the blobs and trees from
excluded revisions only for paths we are actually going to send
to the other end.

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

Add Documentation/technical/pack-format.txt

... along with the previous one, pack-heuristics, by popular
demand.

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

Added Packing Heursitics IRC writeup.

Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

blame -S <ancestry-file>

This adds the -S <ancestry-file> option to blame, which is
needed by the CVS server emulation.

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

Match ofs/cnt types in diff interface.

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

Add documentation for git-imap-send.

Signed-off-by: Mike McCormack <mike@codeweavers.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

blame.c: fix completely broken ancestry traversal.

Recent revision.c updates completely broken the assignment of
blames by not rewriting commit->parents field unless explicitly
asked to by the caller.  The caller needs to set revs.parents.

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

gitk: Fix incorrect invocation of getmergediffline

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

[PATCH] gitk: Fix searching for filenames in gitk

findcont should not accept any arguments.

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>

date parsing: be friendlier to our European friends.

This does three things, only applies to cases where the user
manually tries to override the author/commit time by environment
variables, with non-ISO, non-2822 format date-string:

 - Refuses to use the interpretation to put the date in the
   future; recent kernel history has a commit made with
   10/03/2006 which is recorded as October 3rd.

 - Adds '.' as the possible year-month-date separator.  We
   learned from our European friends on the #git channel that
   dd.mm.yyyy is the norm there.

 - When the separator is '.', we prefer dd.mm.yyyy over
   mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over
   dd/mm/yy[yy].

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

Tweaks to make asciidoc play nice.

Once the content has been generated, the formatting elves can reorder
it to be pretty...

Signed-off-by: Francis Daly <francis@daoine.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

blame: use built-in xdiff

This removes the last use of external diff from core git suite.
Also addresses the use of index() -- elsewhere we tend to use
strchr().

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

git-commit: document --amend

The "--amend" option is used to amend the tip of the current branch. This
documentation text was copied straight from the commit that implemented it.

Some minor format tweaks for asciidoc were taken from work by Francis Daly
in commit b0d08a5.. It looks good now also in the html page.

[jc: amended further to follow the recommendation by Francis in
commit 3070b60].

Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'jc/clone'

* jc/clone:
  git-clone: fix handling of upsteram whose HEAD does not point at master.

Merge branch 'pb/regex'

* pb/regex:
  On some platforms, certain headers need to be included before regex.h
  Support for pickaxe matching regular expressions

Avoid a crash if realloc returns a different pointer.

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

Avoid a divide by zero if there's no messages to send.

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

Fix compile with expat, but an old curl version

With an old curl version, git-http-push is not compiled. But git-http-fetch
still needs to be linked with expat if NO_EXPAT is not defined.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge git://git.kernel.org/pub/scm/gitk/gitk

* git://git.kernel.org/pub/scm/gitk/gitk:
  [PATCH] Provide configurable UI font for gitk
  [PATCH] gitk: Use git wrapper to run git-ls-remote.
  [PATCH] gitk: add key bindings for selecting first and last commit
  gitk: Add a help menu item to display key bindings
  [PATCH] gitk: allow goto heads
  gitk: replace parent and children arrays with lists

combine-diff: move the code to parse hunk-header into common library.

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

Add git-clean command

This command removes untracked files from the working tree.  This
implementation is based on cg-clean with some simplifications.  The
documentation is included.

[jc: with trivial documentation fix, noticed by Jakub Narebski]

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'fix'

* fix:
  diff_flush(): leakfix.
  parse_date(): fix parsing 03/10/2006

diff_flush(): leakfix.

We were leaking filepairs when output-format was set to
NO_OUTPUT.

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

combine-diff: refactor built-in xdiff interface.

This refactors the line-by-line callback mechanism used in
combine-diff so that other programs can reuse it more easily.

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

parse_date(): fix parsing 03/10/2006

The comment associated with the date parsing code for three
numbers separated with slashes or dashes implied we wanted to
interpret using this order:

yyyy-mm-dd
yyyy-dd-mm
mm-dd-yy
dd-mm-yy

However, the actual code had the last two wrong, and making it
prefer dd-mm-yy format over mm-dd-yy.

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

http-fetch: add optional DAV-based pack list

If git is not built with NO_EXPAT, this patch changes git-http-fetch to
attempt using DAV to get a list of remote packs and fall back to using
objects/info/packs if the DAV request fails.

Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

[PATCH] Provide configurable UI font for gitk

This makes the font used in the UI elements of gitk configurable in the
same way the other fonts are. The default fonts used in the Xft build of
tk8.5 are particularily horrific, making this change more important
there.

Signed-off-by: Keith Packard <keithp@neko.keithp.com>
Acked-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>

[PATCH] gitk: Use git wrapper to run git-ls-remote.

For some reason, the Cygwin Tcl's `exec' command has trouble running
scripts.  Fix this by using the C `git' wrapper.  Other GIT programs run
by gitk are written in C already, so we don't need to incur a
performance hit of going via the wrapper (which I'll bet isn't pretty
under Cygwin).

Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Acked-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>

[PATCH] gitk: add key bindings for selecting first and last commit

For a keyboard addict like me some keys are still missing from
gitk. Especially a key to select a commit when no commit is selected,
like just after startup. While we're at it, complete the bindings for
moving the view seperately from the selected line. Currently, the up
and down keys act on the selected line while pageup and pagedown act
on the commits viewed.

The idea is to have to normal keys change the selected line:
  - Home selects first commit
  - End selects last commit
  - Up selects previous commit
  - Down selects next commit
  - PageUp moves selected line one page up
  - PageDown moves selected line one page down
...and together with the Control key, it moves the commits view:
  - Control-Home views first page of commits
  - Control-End views last page of commits
  - Control-Up moves commit view one line up
  - Control-Down moves commit view one line down
  - Control-PageUp moves commit view one page up
  - Control-PageDown moves commit view one page down

Signed-off-By: Rutger Nijlunsing <gitk@tux.tmfweb.nl>
and with some cleanups and simplifications...
Signed-off-by: Paul Mackerras <paulus@samba.org>

On some platforms, certain headers need to be included before regex.h

Happily, these are already included in cache.h, which is included anyway...
so: change the order of includes.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

cvsimport: use git-update-ref when updating

This simplifies code, and also fixes a subtle bug: when importing in a
shared repository, where another user last imported from CVS, cvsimport
used to complain that it could not open <branch> for update.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitk: Add a help menu item to display key bindings

Suggested by Paul Schulz.  I made it a separate entry under the Help
menu rather than putting it in the About box, though.

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

[PATCH] gitk: allow goto heads

This patch allows you to enter a head name in the SHA1 id: field.

It also removes some unnecessary global declarations.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>

combine-diff: use built-in xdiff.

Now there is no GNU diff invocations, except the one from
blame.c

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

GIT 1.3.0-rc2

Bunch of cleanups with a few notable enhancements since
1.3.0-rc1:

 - revision traversal infrastructure is updated so that
   existence of paths limiters and/or --max-age does not cause
   it to call limit_list().  This helps the latency working with
   the command quite a bit.

 - comes with updated gitk.

One notable fix is to make sure that the IO is restarted upon
signal even on platforms whose default signal semantics is not
to do so.  This is the fix for the notorious "clone is broken
since 1.2.2 on Solaris" problem.

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

Merge in xdiff cleanup pieces

Set HTTP user agent to git/GIT_VERSION

Useful for diagnostics/troubleshooting to know which client versions are
hitting your server.

Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-ls-remote: send no-cache header when fetching info/refs

Proxies should not cache this file as it can cause a client to end up with
a stale version, as reported here:

http://marc.theaimsgroup.com/?l=git&m=114407944125389

Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Support for pickaxe matching regular expressions

git-diff-* --pickaxe-regex will change the -S pickaxe to match
POSIX extended regular expressions instead of fixed strings.

The regex.h library is a rather stupid interface and I like pcre too, but
with any luck it will be everywhere we will want to run Git on, it being
POSIX.2 and all. I'm not sure if we can expect platforms like AIX to
conform to POSIX.2 or if win32 has regex.h. We might add a flag to
Makefile if there is a portability trouble potential.

Signed-off-by: Petr Baudis <pasky@suse.cz>

Merge branch 'pe/cleanup'

* pe/cleanup:
  Replace xmalloc+memset(0) with xcalloc.
  Use blob_, commit_, tag_, and tree_type throughout.

Merge branch 'lt/fix-sol-pack'

* lt/fix-sol-pack:
  Use sigaction and SA_RESTART in read-tree.c; add option in Makefile.
  safe_fgets() - even more anal fgets()
  pack-objects: be incredibly anal about stdio semantics
  Fix Solaris stdio signal handling stupidities

Replace xmalloc+memset(0) with xcalloc.

Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Use blob_, commit_, tag_, and tree_type throughout.

This replaces occurences of "blob", "commit", "tag", and "tree",
where they're really used as type specifiers, which we already
have defined global constants for.

Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Clean-up trivially redundant diff.

Also corrects the line numbers in unified output when using
zero lines context.

contrib/git-svn: handle array values correctly

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

contrib/git-svn: make sure our git-svn is up-to-date for test

Bugs like the last one could've been avoided if it weren't for
this...

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

contrib/git-svn: ensure repo-config returns a value before using it

fetching from repos without an authors-file defined was broken.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Use sigaction and SA_RESTART in read-tree.c; add option in Makefile.

Might as well ape the sigaction change in read-tree.c to avoid
the same potential problems.  The fprintf status output will
be overwritten in a second, so don't bother guarding it.  Do
move the fputc after disabling SIGALRM to ensure we go to the
next line, though.

Also add a NO_SA_RESTART option in the Makefile in case someone
doesn't have SA_RESTART but does restart (maybe older HP/UX?).
We want the builder to chose this specifically in case the
system both lacks SA_RESTART and does not restart stdio calls;
a compat #define in git-compat-utils.h would silently allow
broken systems.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>

safe_fgets() - even more anal fgets()

This is from Linus -- the previous round forgot to clear error
after EINTR case.

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

git-clone: fix handling of upsteram whose HEAD does not point at 

When cloning from a remote repository that has master, main, and
origin branches _and_ with the HEAD pointing at main branch, we
did quite confused things during clone.  So this cleans things
up.  The behaviour is a bit different between separate remotes/
layout and the mixed branches layout.

The newer layout with $GIT_DIR/refs/remotes/$origin/, things are
simpler and more transparent:

 - remote branches are copied to refs/remotes/$origin/.

 - HEAD points at the branch with the same name as the remote
   HEAD points at, and starts at where the remote HEAD points at.

 - $GIT_DIR/remotes/$origin file is set up to fetch all remote
   branches, and merge the branch HEAD pointed at at the time of
   the cloning.

Everything-in-refs/heads layout was the more confused one, but
cleaned up like this:

 - remote branches are copied to refs/heads, but the branch
   "$origin" is not copied, instead a copy of the branch the
   remote HEAD points at is created there.

 - HEAD points at the branch with the same name as the remote
   HEAD points at, and starts at where the remote HEAD points at.

 - $GIT_DIR/remotes/$origin file is set up to fetch all remote
   branches except "$origin", and merge the branch HEAD pointed
   at at the time of the cloning.

With this, the remote has master, main and origin, and its HEAD
points at main, you could:

git clone $URL --origin upstream

to use refs/heads/upstream as the tracking branch for remote
"main", and your primary working branch will also be "main".
"master" and "origin" are used to track the corresponding remote
branches and with this setup they do not have any special meaning.

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

fix repacking with lots of tags

Use git-rev-list's --all instead of git-rev-parse's to keep from
hitting the shell's argument list length limits when repacking
with lots of tags.

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

Documentation: revise top of git man page

I'm afraid I'll be accused of trying to suck all the jokes and the
personality out of the git documentation.  I'm not!  Really!

That said, "man git" is one of the first things a new user is likely try,
and it seems a little cruel to start off with a somewhat obscure joke
about the architecture of git.

So instead I'm trying for a relatively straightforward description of what
git does, and what features distinguish it from other systems, together
with immediate links to introductory documentation.

I also did some minor reorganization in an attempt to clarify the
classification of commands.  And revised a bit for conciseness (as is
obvious from the diffstat--hopefully I didn't cut anything important).

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>

pack-objects: be incredibly anal about stdio semantics

This is the "letter of the law" version of using fgets() properly in the
face of incredibly broken stdio implementations.  We can work around the
Solaris breakage with SA_RESTART, but in case anybody else is ever that
stupid, here's the "safe" (read: "insanely anal") way to use fgets.

It probably goes without saying that I'm not terribly impressed by
Solaris libc.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix Solaris stdio signal handling stupidities

This uses sigaction() to install the SIGALRM handler with SA_RESTART, so
that Solaris stdio doesn't break completely when a signal interrupts a
read.

Thanks to Jason Riedy for confirming the silly Solaris signal behaviour.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix sparse warnings about non-ANSI function prototypes

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix sparse warnings about usage of 0 instead of NULL

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Remove useless pointer update

buf is not used afterwards.  The compiler optimized the dead store out
anyway, but let's clean the source, too.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitk: replace parent and children arrays with lists

This will make it easier to switch between views efficiently, and
turns out to be slightly faster as well.

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

contrib/git-svn: documentation updates

contrib/git-svn/git-svn.txt:
added git-repo-config key names for options
fixed quoting of "git-svn-HEAD" in the manpage
use preformatted text for examples

contrib/git-svn/Makefile:
add target to generate HTML:
http://git-svn.yhbt.net/git-svn.html

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

contrib/git-svn: accept configuration via repo-config

repo-config keys are any of the long option names minus the '-'
characters

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

revision: --max-age alone does not need limit_list() anymore.

This makes git log --since=7.days to be streamable.

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

revision: simplify argument parsing.

This just moves code around to consolidate the part that sets
revs->limited to one place based on various flags.

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

revision: --topo-order and --unpacked

Now, using --unpacked without limit_list() does not make much
sense, but this is parallel to the earlier --max-age fix.

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

revision: Fix --topo-order and --max-age with reachability limiting.

What ends up not working very well at all is the combination of
"--topo-order" and the output filter in get_revision. It will
return NULL when we see the first commit out of date-order, even
if we have other commits coming.

So we really should do the "past the date order" thing in
get_revision() only if we have _not_ done it already in
limit_list().

Something like this.

The easiest way to test this is with just

gitk --since=3.days.ago

on the kernel tree. Without this patch, it tends to be pretty obviously
broken.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Make path-limiting be incremental when possible.

This makes git-rev-list able to do path-limiting without having to parse
all of history before it starts showing the results.

This makes things like "git log -- pathname" much more pleasant to use.

This is actually a pretty small patch, and the biggest part of it is
purely cleanups (turning the "goto next" statements into "continue"), but
it's conceptually a lot bigger than it looks.

What it does is that if you do a path-limited revision list, and you do
_not_ ask for pseudo-parenthood information, it won't do all the
path-limiting up-front, but instead do it incrementally in
"get_revision()".

This is an absolutely huge deal for anything like "git log -- <pathname>",
but also for some things that we don't do yet - like the "find where
things changed" logic I've described elsewhere, where we want to find the
previous revision that changed a file.

The reason I put "RFC" in the subject line is that while I've validated it
various ways, like doing

git-rev-list HEAD -- drivers/char/ | md5sum

before-and-after on the kernel archive, it's "git-rev-list" after all. In
other words, it's that really really subtle and complex central piece of
software. So while I think this is important and should go in asap, I also
think it should get lots of testing and eyeballs looking at the code.

Btw, don't even bother testing this with the git archive. git itself is so
small that parsing the whole revision history for it takes about a second
even with path limiting. The thing that _really_ shows this off is doing

git log drivers/

on the kernel archive, or even better, on the _historic_ kernel archive.

With this change, the response is instantaneous (although seeking to the
end of the result will obviously take as long as it ever did). Before this
change, the command would think about the result for tens of seconds - or
even minutes, in the case of the bigger old kernel archive - before
starting to output the results.

NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
the "--parents" flag to actually generate a pseudo-history of the
resulting commits won't actually see the improvement in interactivity,
since that forces git-rev-list to do the whole-history thing after all.

MAYBE we can fix that too at some point, but I won't promise anything.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Move "--parent" parsing into generic revision.c library code

Not only do we do it in both rev-list.c and git.c, the revision walking
code will soon want to know whether we should rewrite parenthood
information or not.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Makefile: many programs now depend on xdiff/lib.a having been built.

The dependency was not properly updated when we added this
library, breaking parallel build with $(MAKE) -j.

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

rev-list --boundary: fix re-injecting boundary commits.

Marco reported that

$ git rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d

misses these two boundary commits.

        c649657501bada28794a30102d9c13cc28ca0e5e
        eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4

Indeed, we can see that gitk shows these two commits at the
bottom, because the --boundary code failed to output them.

The code did not check to avoid pushing the same uninteresting
commit twice to the result list.  I am not sure why this fixes
the reported problem, but this seems to fix it.

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

Merge git://git.kernel.org/pub/scm/gitk/gitk

* 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

gitk: Better workaround for arrows on diagonal line segments

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: Paul Mackerras <paulus@samba.org>

contrib/git-svn: force GIT_DIR to an absolute path

We chdir internally, so we need a consistent GIT_DIR variable.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-clone: exit early if repo isn't specified

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: Yasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Make git-clone to take long double-dashed origin option (--origin)

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: Yasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitk: Allow top panes to scroll horizontally with mouse button 2

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

gitk: Prevent parent link from overwriting commit headline

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: Paul Mackerras <paulus@samba.org>

gitk: Show diffs for boundary commits

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: Paul Mackerras <paulus@samba.org>

tree/diff header cleanup.

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: Junio C Hamano <junkio@cox.net>

assume unchanged git: diff-index fix.

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: Junio C Hamano <junkio@cox.net>

gitk: Use the new --boundary flag to git-rev-list

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: Paul Mackerras <paulus@samba.org>

revision.c "..B" syntax: constness fix

The earlier change to make "..B" to mean "HEAD..B" (aka ^HEAD B)
has constness gotcha GCC complains.  Fix it.

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

revision arguments: ..B means HEAD..B, just like A.. means A..HEAD

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: Junio C Hamano <junkio@cox.net>

rev-list --boundary

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: Junio C Hamano <junkio@cox.net>

rev-list: memory usage reduction.

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: Junio C Hamano <junkio@cox.net>
Acked-by: Linus Torvalds <torvalds@osdl.org>

rev-list --no-merges: argument parsing fix.

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

xdiff: Show function names in hunk headers.

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: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Add ALL_LDFLAGS to the git target.

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: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>

GIT 1.3.0 rc1

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: Junio C Hamano <junkio@cox.net>