git-rev-list --merge-order is omitting one of the roots when
displaying a merge containing two distinct roots.

A subsequent patch will fix the problem.
Signed-off-by: NJon Seymour <jon.seymour@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We used to ignore unreachable tags, which just causes problems: it makes
"git prune" leave them around, but since we'll have prune everything
that tag points to, the tag object really should be removed too.

So remove the code that made us think tags were always reachable.

It's just a trivial wrapper, but it should make Jeff's kernel developer
guide to git look a bit less intimidating.

The sensible cleanup of the in-memory storage order of commit parents broke the --merge-order
code which was dependent on the previous behaviour of parse_commit().

This patch restores the correctness --merge-order behaviour by taking account of the
new behaviour of parse_commit.
Signed-off-by: NJon Seymour <jon.seymour@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Btw, it's fun just looking at the merged git repository itself with
gitk, now that it has two "roots".

gitk is really quite incredibly cool, and is great for visualizing what
is going on in a git repository.  It's especially useful when you are
looking at what has changed since a particular version, since it
gracefully handles partial trees (and this also avoids the expense of
looking at _all_ changes in a big project).

For example, to see what changed in a merge after a "git pull", do

	gitk ORIG_HEAD..

to see only the new things.  Or you can simply do "gitk v2.6.12.." to
see what has changed since the v2.6.12 tag etc.

This merge itself is pretty interesting too, since it shows off a
feature of git itself that is incredibly cool: you can merge a
_separate_ git project into another git project.  Not only does this
keep all the history of the original project, it also makes it possible
to continue to merge with the original project and the union of the two
projects.

I don't think anybody else can do that.

This adds tests (which also serves demonstration) for the --stat
and --summary flags to the git-apply command.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add missing documentation for git-apply.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Typical expected usage is "git-apply --stat --summary" to show
diffstat plus dense description of information available in git
extended headers, such as creations, renames, and mode changes.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When a patch is a git extended rename/copy patch, "git-apply
--stat" showed the old filename.  Change it to show the new
filename, because most of the time we are interested in looking
at the resulting tree.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This makes "-w ref" usable for git-local-pull.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In particular try hard to give different colors to lines that cross
at a corner in one of the lines.

This involves adding indentation when we read a commit with
git-cat-file and trimming the whitespace from the headline.

Applying Andrew's latest patch-bomb showed us failing miserably if a new
subdirectory needed to be created..  That said, it's uncommon enough
that it's worth optimistically assuming it won't be needed, and then
creating the subdirectories only on failure.

This adds support for refs to http-pull, both the -w option and reading
the target from a served file.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Make pull fetch whatever is specified, parse it to figure out what it is, and
then process it appropriately. This also supports getting tag objects, and
getting whatever they tag.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Handle parsing a tag for a non-present object. This adds a function to lookup
an object with lookup_* for * in a string, so that it can get the right storage
based on the "type" line in the tag.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

With --header, git-rev-list gives us the contents of the commit
in-line, so we don't need to exec a git-cat-file to get it, and we
don't need the readobj command either.
Also fixed a residual problem with handling the commit that
has a parent listed twice.

The confusion between "revs" vs "refs" caused us to not find the branch
name, which in turn meant that we never switched the HEAD over to it.

Both of these scripts will end up resetting the index to some specific
head, and any unresolved merge will be forgotten.

We codify the following different heads (in addition to the main "HEAD",
which points to the current branch, of course):

 - FETCH_HEAD

   Populated by "git fetch"

 - ORIG_HEAD

   The old HEAD before a "git pull/resolve" (successful or not)

 - LAST_MERGE

   The HEAD we're currently merging in "git pull/resolve"

 - MERGE_HEAD

   The previous head of a unresolved "git pull", which gets committed by
   a "git commit" after manually resolving the result

We used to have "MERGE_HEAD" be populated directly by the fetch, and we
removed ORIG_HEAD and LAST_MERGE too aggressively.

Here is a patch that fixes several gcc4 warnings about different signedness,
all between char and unsigned char. I tried to keep the patch minimal
so resertod to casts in three places.
Signed-off-by: NMika Kukkonen <mikukkon@iki.fi>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The "${new=$old}" syntax only works for an undefined 'new', not for an
empty one. I knew that. Really. I'm not stupid.

Now "git checkout xyzzy" will check out branch "xyzzy" and
switch the HEAD to it.

And fix braino on testing "-f".

It is careful by default and refuses to overwrite old info, but if you
want to force everything to be re-read, use the "-f" flag.

Some day I'll make it take individual filenames too. Right now
it's all-or-nothing.

Current version would spin forever and exhaust memory while attempting
to sort all files from all revisions at once, until it dies before even
doing any real work.  This is especially noticeable when used on a big
repository like the imported bkcvs repo for the Linux kernel.

This patch allows for batching the sort to put a bound on needed
resources and making progress early, as well as including some small
cleanups.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Diffs with only mode changes didn't pass through git-apply --stat.

[ Linus' note: they did for me, on my ppc64, where division by zero just
  silently returns zero.  Duh.  ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

It does a "git-update-cache" on the arguments, meaning that you can
commit files without doing a separate "git-update-cache".  This commit
was done with

	git commit git-commit-script

for example.

It suppresses the "needs update" message for subsequent "--refresh"
cases (but not other errors).

Will be useful for "git commit". Stay tuned.

The ".pN" thing might be a common ending of a tag, and in
contrast, ^ already is a special character for revisions
so use that instead.

You can say "HEAD.p" for the "parent of HEAD". It nests, so

	HEAD.p2.p

means parent of second parent of HEAD (which obviously depends
on HEAD being a merge).

We used to keep the parents in reverse order in the commit_list.  Most
users don't care, but it's wrong, and the next commit does care.

This allows the user to specify ranges more flexibly; for instance
the user can now do "gitk v2.6.12.." and see all the changes since
2.6.12.

This happens in the linux-2.6 tree.  We draw the graph line
double-thick to show that this happened.

Also fix a bug where we got a bogus "No commit information available"
line at the end on simple repositories like this one.

The unexpected thing is likely a pathname, we need the default for that
too.

Make git-resolve-script only write MERGE_HEAD if a merge actually
occurred. All merge failures leave ORIG_HEAD and LAST_MERGE
behind (instead of ORIG_HEAD and MERGE_HEAD).

Use git-rev-parse to expand arguments (and check for bad ones).
Signed-off-by: NDan Holmsand <holmsand@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This fixes "<hexsha1>..*", since get_sha1() will happily ignore any
garbage at the end and thus we never got to the ".." check before.

Put explicit parentheses around && in ||-expression.

This patch fixes a problem reported by Paul Mackerras regarding the interaction
of the --merge-order and --max-age switches of git-rev-list.

This patch applies to the current Linus HEAD. A cleaner fix for the same problem
in my current HEAD will follow later.

With this change, --merge-order produces the same result as no --merge-order
on the linux-2.6 git repository, to wit:

$> git-rev-list --max-age=1116330140 bcfff0b471a60df350338bcd727fc9b8a6aa54b2 | wc -l
655
$> git-rev-list --merge-order --max-age=1116330140 bcfff0b471a60df350338bcd727fc9b8a6aa54b2 | wc -l
655
Signed-off-by: NJon Seymour <jon.seymour@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>