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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus 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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus 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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Linus 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: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Linus 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: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Linus 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.
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: Mika Kukkonen <mikukkon@iki.fi>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Nicolas Pitre <nico@cam.org>
Signed-off-by: Linus 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: Linus 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.
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).
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.
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: Dan Holmsand <holmsand@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
If b is reachable from a, then:
git-rev-list a b
argument would print one of the commits twice.
This patch fixes that problem. A previous problem fixed it for the
--merge-order switch.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
If a is reachable from b, then git-rev-list --merge-order b a would
produce a duplicate output of b.
This causes a problem for an upcoming version of gitk since it
breaks the --merge-order ordering invariant.
This patch fixes the problem for the --merge-order switch. A subsequent
patch will fix the problem for the non --merge-order switch.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Given that real trees in the wild include parents with duplicate parents, I have relaxed
over-zealous error checking in epoch.c and dealt with the problem a different way - duplicate
parents are now silently ignored.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
git-rev-list --merge-order HEAD ^HEAD was faulting rather than generating an empty output.
This patch fixes that problem.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus 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: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus 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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus 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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus 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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Panagiotis Issaris <takis@lumumba.luc.ac.be>
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Linus 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.
