tokkee.org

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>

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>

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>

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>

Merge branch ak/svn

Merge branch 'lt/diffgen' into next

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

Merge branch 'master' into next

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

add clean and ignore rules for xdiff/

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

Optionally do not list empty directories in git-ls-files --others

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: Petr Baudis <pasky@suse.cz>

Document git-rebase behavior on conflicts.

Remove dependency on a file named "-lz"

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: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fix error handling for nonexistent names

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

Merge branch 'jc/thin' into next

* 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

git-push: make --thin pack transfer the default.

Just in case it has problems, you can say "git push --no-thin".

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

Merge branches 'jc/clone' and 'jc/name'

* 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.

Merge branch 'jc/merge'

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

Merge branch 'lt/diffgen' into next

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

git-svnimport: if a limit is specified, respect it

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: Anand Kumria <wildfire@progsoc.org>
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: 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

true built-in diff: run everything in-core.

This stops using temporary files when we are using the built-in
diff (including the complete rewrite).

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

contrib/git-svn: stabilize memory usage for big fetches

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: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'ew/email' into next

* 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'

Merge branch 'lt/diffgen' into next

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

Merge branch 'rs/tar-tree' into next

* 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.

send-email: lazy-load Email::Valid and make it optional

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: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

send-email: try to order messages in email clients more correctly

If --no-chain-reply-to is set, patches may not always be ordered
correctly in email clients.  This patch makes sure each email
sent from a different second.

I chose to start with a time (slightly) in the past because
those are probably more likely in real-world usage and spam
filters might be more tolerant of them.

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

send-email: Change from Mail::Sendmail to Net::SMTP

Net::SMTP is in the base Perl distribution, so users are more
likely to have it.  Net::SMTP also allows reusing the SMTP
connection, so sending multiple emails is faster.

[jc: tweaked X-Mailer further while we are at it.]

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

send-email: use built-in time() instead of /bin/date '+%s'

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

built-in diff: minimum tweaks

This fixes up a couple of minor issues with the real built-in
diff to be more usable:

 - Omit ---/+++ header unless we emit diff output;

 - Detect and punt binary diff like GNU does;

 - Honor GIT_DIFF_OPTS minimally (only -u<number> and
   --unified=<number> are currently supported);

 - Omit line count of 1 from "@@ -l,k +m,n @@" hunk header
   (i.e. when k == 1 or n == 1)

 - Adjust testsuite for the lack of -p support.

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

builtin-diff: \No newline at end of file.

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

Use a *real* built-in diff generator

This uses a simplified libxdiff setup to generate unified diffs _without_
doing  fork/execve of GNU "diff".

This has several huge advantages, for example:

Before:

[torvalds@g5 linux]$ time git diff v2.6.16.. > /dev/null

real    0m24.818s
user    0m13.332s
sys     0m8.664s

After:

[torvalds@g5 linux]$ time git diff v2.6.16.. > /dev/null

real    0m4.563s
user    0m2.944s
sys     0m1.580s

and the fact that this should be a lot more portable (ie we can ignore all
the issues with doing fork/execve under Windows).

Perhaps even more importantly, this allows us to do diffs without actually
ever writing out the git file contents to a temporary file (and without
any of the shell quoting issues on filenames etc etc).

NOTE! THIS PATCH DOES NOT DO THAT OPTIMIZATION YET! I was lazy, and the
current "diff-core" code actually will always write the temp-files,
because it used to be something that you simply had to do. So this current
one actually writes a temp-file like before, and then reads it into memory
again just to do the diff. Stupid.

But if this basic infrastructure is accepted, we can start switching over
diff-core to not write temp-files, which should speed things up even
further, especially when doing big tree-to-tree diffs.

Now, in the interest of full disclosure, I should also point out a few
downsides:

 - the libxdiff algorithm is different, and I bet GNU diff has gotten a
   lot more testing. And the thing is, generating a diff is not an exact
   science - you can get two different diffs (and you will), and they can
   both be perfectly valid. So it's not possible to "validate" the
   libxdiff output by just comparing it against GNU diff.

 - GNU diff does some nice eye-candy, like trying to figure out what the
   last function was, and adding that information to the "@@ .." line.
   libxdiff doesn't do that.

 - The libxdiff thing has some known deficiencies. In particular, it gets
   the "\No newline at end of file" case wrong. So this is currently for
   the experimental branch only. I hope Davide will help fix it.

That said, I think the huge performance advantage, and the fact that it
integrates better is definitely worth it. But it should go into a
development branch at least due to the missing newline issue.

Technical note: this is based on libxdiff-0.17, but I did some surgery to
get rid of the extraneous fat - stuff that git doesn't need, and seriously
cutting down on mmfile_t, which had much more capabilities than the diff
algorithm either needed or used. In this version, "mmfile_t" is just a
trivial <pointer,length> tuple.

That said, I tried to keep the differences to simple removals, so that you
can do a diff between this and the libxdiff origin, and you'll basically
see just things getting deleted. Even the mmfile_t simplifications are
left in a state where the diffs should be readable.

Apologies to Davide, whom I'd love to get feedback on this all from (I
wrote my own "fill_mmfile()" for the new simpler mmfile_t format: the old
complex format had a helper function for that, but I did my surgery with
the goal in mind that eventually we _should_ just do

mmfile_t mf;

buf = read_sha1_file(sha1, type, &size);
mf->ptr = buf;
mf->size = size;
.. use "mf" directly ..

which was really a nightmare with the old "helpful" mmfile_t, and really
is that easy with the new cut-down interfaces).

[ Btw, as any hawk-eye can see from the diff, this was actually generated
  with itself, so it is "self-hosting". That's about all the testing it
  has gotten, along with the above kernel diff, which eye-balls correctly,
  but shows the newline issue when you double-check it with "git-apply" ]

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

tar-tree: Use the prefix field of a tar header

... to store parts of the path, if possible.  This allows us to avoid
writing extended headers in certain cases (long pathes can only be
split at '/' chars).

Also adds a file to the test repo with a 100 chars long directory name.
Even old versions of tar that don't understand POSIX extended headers
should be able to handle this testcase.

Btw.: The longest path in the kernel tree currently has 70 chars.
Together with a 30 chars long prefix this would already cross the
field limit of 100 chars.

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

tar-tree: Remove obsolete code

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

tar-tree: Use write_entry() to write the archive contents

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

tar-tree: Introduce write_entry()

... and use it initially to write global extended header records.
Improvements compared to the old write_header():

  - Uses a struct ustar_header instead of hardcoded offsets.
  - Takes one struct strbuf as path argument instead of a (basedir,
    prefix, name) tuple.
  - Not only writes the tar header, but also the contents of the
    file, if any.
  - Does not write directly into the ring buffer.  This allows the
    code to be layed out more naturally, because there is no more
    ordering constraint.  Before we had to first finish writing the
    extended header, now we can construct the extended and normal
    headers in parallel.
  - The typeflag parameter has been replaced by (reasonable) magic
    values.  path == NULL indicates an extended header, additionally
    sha1 == NULL means it is a global extended header.

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

tar-tree: Use SHA1 of root tree for the basedir

... instead of the made-up "0".

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

git-apply: safety fixes

This was triggered by me testing the "@@" numbering shorthand by GNU
patch, which not only showed that git-apply thought it meant the number
was duplicated (when it means that the second number is 1), but my tests
showed than when git-apply mis-understood the number, it would then not
raise an alarm about it if the patch ended early.

Now, this doesn't actually _matter_, since with a three-line context, the
only case that "x,1" will be shorthanded to "x" is when x itself is 1 (in
which case git-apply got it right), but the fact that git-apply would also
silently accept truncated patches was a missed opportunity for additional
sanity-checking.

So make git-apply refuse to look at a patch fragment that ends early.

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

Removed bogus "<snap>" identifier.

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

Clarify and expand some hook documentation.

Clarify update and post-update hooks.
Made a few references to the hooks documentation.

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

commit-tree: check return value from write_sha1_file()

... found by Matthias Kestenholz.

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

Merge branch 'jc/name' into next

* jc/name:
  sha1_name: make core.warnambiguousrefs the default.
  sha1_name: warning ambiguous refs.

Merge branch 'jc/cvsimport'

* jc/cvsimport:
  cvsimport: fix reading from rev-parse
  cvsimport: honor -i and non -i upon subsequent imports

Merge branch 'jc/pull'

* jc/pull:
  git-pull: reword "impossible to fast-forward" message.
  git-pull: further safety while on tracking branch.

Merge branch 'jc/fetch'

* jc/fetch:
  fetch: exit non-zero when fast-forward check fails.

send-email: Identify author at the top when sending e-mail

git-send-email did not check if the sender is the same as the
patch author.  Follow the "From: at the beginning" convention to
propagate the patch author correctly.

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

sha1_name: make core.warnambiguousrefs the default.

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

sha1_name: warning ambiguous refs.

This makes sure that many commands that take refs on the command
line to honor core.warnambiguousrefs configuration.  Earlier,
the commands affected by this patch did not read the
configuration file.

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

Format tweaks for asciidoc.

Some documentation "options" were followed by independent preformatted
paragraphs. Now they are associated plain text paragraphs. The
difference is clear in the generated html.

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

Merge branch 'jc/pull' into next

* jc/pull:
  git-pull: reword "impossible to fast-forward" message.
  git-pull: further safety while on tracking branch.

git-pull: reword "impossible to fast-forward" message.

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

git-pull: further safety while on tracking branch.

Running 'git pull' while on the tracking branch has a built-in
safety valve to fast-forward the index and working tree to match
the branch head, but it errs on the safe side too cautiously.

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

Merge branch 'jc/revlist' into next

* jc/revlist:
  rev-list --timestamp
  git-apply: do not barf when updating an originally empty file.
  http-push.c: squelch C90 warnings.
  fix field width/precision warnings in blame.c

Merge branch 'jc/clone' into next

* jc/clone:
  git-clone: typofix.

git-clone: typofix.

The traditional one created refs/origin by mistake, not
refs/heads/origin.  Also it mistakenly failed to prevent
$origin from being listed twice in remotes/origin file.

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

rev-list --timestamp

This prefixes the raw commit timestamp to the output.

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

git-apply: do not barf when updating an originally empty file.

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

http-push.c: squelch C90 warnings.

If you write code after declarations in a block, gcc scolds you
with "warning: ISO C90 forbids mixed declarations and code".

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

fix field width/precision warnings in blame.c

Using "size_t" values for printf field width/precision upsets gcc, it
wants to see an "int".

Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitk: Fix two bugs reported by users

The first was a simple typo where I put $yc instead of [yc $row].
The second was that I broke the logic for keeping up with fast
movement through the commits, e.g. when you select a commit and then
press down-arrow and let it autorepeat.  That got broken when I
changed the merge diff display to use git-diff-tree --cc.

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

Merge branch 'jc/clone' into next

* jc/clone:
  clone: record the remote primary branch with remotes/$origin/HEAD

Merge branch 'jc/name' into next

* jc/name:
  get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD

clone: record the remote primary branch with remotes/$origin/HEAD

This matches c51d13692d4e451c755dd7da3521c5db395df192 commit to
record the primary branch of the remote with a symbolic ref
remotes/$origin/HEAD.  The user can later change it to point at
different branch to change the meaning of "$origin" shorthand.

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

get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD

This implements the suggestion by Jeff King to use
refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean
the primary branch head of a tracked remote.  clone needs to be
told about this convention as well.

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

Merge branch 'jc/name' into next

* jc/name:
  core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.
  contrib/git-svn: allow rebuild to work on non-linear remote heads
  http-push: don't assume char is signed
  http-push: add support for deleting remote branches
  Be verbose when !initial commit
  Fix multi-paragraph list items in OPTIONS section
  http-fetch: nicer warning for a server with unreliable 404 status

Merge branch 'jc/clone' into next

* jc/clone:
  revamp git-clone (take #2).

revamp git-clone (take #2).

This builds on top of the previous one.

 * --use-separate-remote uses .git/refs/remotes/$origin/
   directory to keep track of the upstream branches.

 * The $origin above defaults to "origin" as usual, but the
   existing "-o $origin" option can be used to override it.

I am not yet convinced if we should make "$origin" the synonym to
"refs/remotes/$origin/$name" where $name is the primary branch
name of $origin upstream, nor if so how we should decide which
upstream branch is the primary one, but that is more or less
orthogonal to what the clone does here.

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

core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.

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

contrib/git-svn: allow rebuild to work on non-linear remote heads

Because committing back to an SVN repository from different
machines can result in different lineages, two different
repositories running git-svn can result in different commit
SHA1s (but of the same tree).  Sometimes trees that are tracked
independently are merged together (usually via children),
resulting in non-unique git-svn-id: lines in rev-list.

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