git-rev-list --merge-order --show-breaks root

Was outputing:

| root

It now outputs:

= root

Which is consistent with the behaviour of other cases.
Signed-off-by: NJon Seymour <jon.seymour@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

1. --merge-order doesn't deal properly with a specified head that has no parent

   * FAIL 11: head has no parent

2. --merge-order doesn't deal properly with arguments of the form
     head ^head

   * FAIL 30: head ^head --merge-order git-rev-list --merge-order
     --show-breaks a3 ^a3

3. if one of the specified heads is reachable from the other, the
   head gets printed twice and this causes problems for upcoming
   versions of gitk. This is true for both --merge-order and non
   --merge-order style of invocations.
    * FAIL 24: one specified head reachable from another a4, c3, --merge-order
    * FAIL 26: one specified head reachable from another a4, c3, no --merge-order
    * FAIL 27: one specified head reachable from another c3, a4, no --merge-order

4. --merge-order aborts with commits that list the same parent twice...it should handle it more gracefully.
    * no longer unit testable

5. broken interaction between --merge-order and --max-age
   previously posted as:

    "[PATCH 1/2] Test case that demonstrates problem with --merge-order, --max-age interaction"
    * FAIL 23: --max-age=c3, --merge-order

Later patches in this patch set fix these problems.
Signed-off-by: NJon Seymour <jon.seymour@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Patch for a completely rewritten file detected by the -B flag
was shown as a pair of creation followed by deletion in earlier
versions.  This was an misguided attempt to make reviewing such
a complete rewrite easier, and unnecessarily ended up confusing
git-apply.  Instead, show the entire contents of old version
prefixed with '-', followed by the entire contents of new
version prefixed with '+'.  This gives the same easy-to-review
for human consumer while keeping it a single, regular
modification patch for machine consumption, something that even
GNU patch can grok.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This updates diff documentation to discuss --find-copies-harder,
and adds descriptions for options that were not described
earlier.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Like diff-tree, this patch makes -C option for diff-* brothers
to use only pre-image of modified files as rename/copy detection
by default.  Give --find-copies-harder to use unmodified files
to find copies from as well.

This also fixes "diff-files -C" problem earlier noticed by
Linus.  It was feeding the null sha1 even when the file in the
work tree was known to match what is in the index file.  This
resulted in diff-files showing everything in the project.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Noted by Jeff.

Otherwise you'll be bitten by a stale MERGE_HEAD like Jeff was..

Add -u option to indicate incremental conversion.

I wanted to be able to track CVS repositories in a GIT repository.  The
cvs2git program worked fine with the initial import but needed a tiny
modification to enable me to resync the GIT repository with the updated
CVS tree.

[ The original version of this patch failed to track the correct
  branch on the first new commit. Fixed and tested by Sven. ]
Signed-off-by: NPanagiotis Issaris <takis@lumumba.luc.ac.be>
Signed-off-by: NSven Verdoolaege <skimo@kotnet.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Previous patch to fix host:path notation broke
handling of ssh://host/path notation.
Signed-off-by: NSven Verdoolaege <skimo@liacs.nl>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

But warn about them.  If somebody really ends up later wanting to
explicitly add a note that something has the same parent twice (who
knows, there are strange people around), we can add a flag to say that
it's expected and ok.

This was brought on by a commit in the kernel tree, where a repeated
merge caused a duplicate parent.

Parent duplicates aren't "wrong" per se, they're just in practice not
something you are ever interested in.

As suggested by Junio

Pointed out by Junio, part of my debugging of the rewrite of the
file/dir conflict handling.

This is (imho) more readable, and is also a lot faster.  The expense of
looking up sub-directory beginnings was killing us on things like
"git-diff-cache", even though that one didn't even care at all about the
file vs directory conflicts.

We really only care when somebody tries to add a conflicting name to
stage 0.

We should go through the conflict rules more carefully some day.

Strangely, this warning only shows up when not compiling with "-O2",
which is why I didn't see it originally.

git-cvs2git: propagate mode information

Let cvs checkout in a temporary directory rather than
using the pipe option to avoid loss of mode information.
Signed-off-by: NSven Verdoolaege <skimo@liacs.nl>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Otherwise the "git log" information doesn't tell enough to make sense of
a merge.

I'll need to add some parent information for regular entries too, I
think, but the merge is more important.

This is useful for doing binary searching for problems.  You start with
a known good and known bad point, and you then test the "halfway" point
in between:

	git-rev-list --bisect bad ^good

and you test that.  If that one tests good, you now still have a known
bad case, but two known good points, and you can bisect again:

	git-rev-list --bisect bad ^good1 ^good2

and test that point.  If that point is bad, you now use that as your
known-bad starting point:

	git-rev-list --bisect newbad ^good1 ^good2

and basically at every iteration you shrink your list of commits by
half: you're binary searching for the point where the troubles started,
even though there isn't a nice linear ordering.

The "C" in "-C" may stand for "Cool", but it's also pretty slow, since
right now it leaves all unmodified files to be tested even if there are
no new files at all.  That just ends up being unacceptably slow for big
projects, especially if it's not all in the cache.

Pure mode changes won't have the file-name in the extended header lines,
so make sure we pick it up from the default name from the "diff --git"
line.

Right now it confuses at least git-diff-files, since it leaves
all the files (whether changed or not) in the diff queue.

Jens was the second person who hadn't heard of the "merge" program, and
didn't have it installed.  So document as many dependency and install
issues as I can think of.

Fix permissions, and add trivial "reset" and "add" scripts.

The "reset" script just resets the index back to head, while the "add"
script is just a crutch for people used to do "cvs add".

Paths in the host:path notation are usually interpreted
relative to the login directory rather than relative to
the root directory.
Signed-off-by: NSven Verdoolaege <skimo@liacs.nl>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Unset TZ to force GMT in test #4 and add a set of parens around
the length function in the awk script.
Signed-off-by: NMark Allen <mrallen1@yahoo.com>
Acked-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

No need to confuse ex-CVS users with a complex initial commit sequence.

Sine git only saves the 'x' bit, we shouldn't compare the stat contents
directly.

It's a simple helper that depending on the arguments will either
use git-diff-files, git-diff-cache or git-diff-tree.

Things like "--max-count=xxx" are "rev-only".

So now you can say

	git-whatchanged -p v2.6.12-rc5.. drivers/usb

and it will show you what changed (as a patch) in drivers/usb since the
v2.6.12-rc5 release.

Sometimes we only want to output revisions, and sometimes we want to
only see the stuff that wasn't revisions.  Teach git-rev-parse to
understand the "--revs-only" and "--no-revs" flags.

See the previous commit for explanations.

It's an incredibly cheesy helper that changes human-readable revision
arguments into the git-rev-list argument format.

You can use it to do something like this:

	git-rev-list --pretty $(git-rev-parse --default HEAD "$@")

which is what git-log-script will become. Here git-rev-parse will
then allow you to use arguments like "v2.6.12-rc5.." or similar
human-readable ranges.

It's really quite stupid: "a..b" will be converted into "a" and "^b" if
"a" and "b" are valid object pointers.  And the "--default" case will be
used if nothing but flags have been seen, so that you can default to a
certain argument if there are no other ranges.

Missing argument for error() function. We should really use the
gcc printf format checking capabilities.

Add "-z fuzz" argument, passed to cvsps, and clean up argument
processing.  Also, use "cvsps --cvs-direct", which is is somewhat
faster.

Give the user the option of specifying the timestamp fuzz passed to
cvsps.  Looking at the other arguments to it, I can't see anything else
that would be sane to play with.  Also, use --cvs-direct, which speeds
up cvsps for remote repositories and doesn't seem to do anything bad to
local repositories.
Signed-off-by: NTommy McGuire <mcguire@crsr.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Slightly expand the cvsimport description, and make a couple of syntax
edits.

The way I figure it, telling someone why cvsimport is taking so long
will improve their overall user experience.  :-)
Signed-off-by: NTommy McGuire <mcguire@crsr.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch adds some sanity checking to git-cvsimport-script,
specifically forcing the use of cvsps -x (to get the latest information
from the repository, rather than whatever is in the cache) and aborting
early if cvsps does not produce any output.

I debated removing the $MODULE directory following an abort, but I
eventually decided leaving stuff behind would make debugging easier.  On
the other hand, this patch should help with the "cvsimport left me with
an empty repository" complaints.

Call cvsps with the -x flag, to get the current state of the repository,
and abort the cvs import early if cvsps does not produce any output.
Signed-off-by: NTommy McGuire <mcguire@crsr.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Remove unneeded sanity tests.  Remote repositories do, indeed, just
work.
Signed-off-by: NTommy McGuire <mcguire@crsr.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>