Earlier change broke "git describe A B" among other things.
Revert it for now, and clean the commits smudged by
get_merge_bases using clear_object_marks() function. For
complex commit ancestry graph, this is way cheaper as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Actually in this case we would have traversed a lot of commits, so cleaning
things up is even more important.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Although our "git-%$X:" implicit target had dependency on
$(GITLIBS) which included xdiff/lib.a, git-http-{fetch,push} had
their own building rules and with an obsolete dependency on
$(LIB_FILES). Update the rules to depend on $(GITLIBS), to make
parallel build work correctly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Hint taken from Johannes. I've tested this with sed --posix on
my system with GNU sed and it works fine with and also without
it. Further portability testing/review would be good.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Change get_merge_bases() to be able to clean up after itself if
needed by adding a cleanup parameter.
We don't need to save the flags and restore them afterwards anymore;
that was a leftover from before the flags were moved out of the
range used in revision.c. clear_commit_marks() sets them to zero,
which is enough.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It had the wrong test for whether a commit was a merge. What it did was to
say that a non-merge has exactly one parent (which sounds almost right),
but the fact is, initial trees have no parent at all, but they're
obviously not merges.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I got tired of having to configure gitweb for every repository
I work on. I sometimes prefer gitweb to standard GUIs like gitk
or gitview; so this lets me automatically configure gitweb to
browse my working repository and also opens my browser to it.
Updates from the original patch:
Added Apache/mod_perl2 compatibility if Dennis Stosberg's gitweb
has been applied, too: <20060621130708.Gcbc6e5c@leonov.stosberg.net>
General cleanups in shell code usage.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch allows history display of whole trees/directories a la
"git-rev-list HEAD -- <dir or file>". I find this useful especially
when a project lives in its own subdirectory, as opposed to being all
of the GIT repository (i.e. when a sub-project is merged into a
super-project).
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The rev-list command that is recent enough can filter commits
based on paths they touch, so use it instead of generating the
full list and limiting it by passing it with diff-tree --stdin.
[jc: The patch originally came from Luben Tuikov but the it was
corrupt, but it was short enough to be applied by hand. I
added the --full-history to make the output compatible with the
original while doing so.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch allows history display of whole trees/directories a la
"git-rev-list HEAD -- <dir or file>". I find this useful especially
when a project lives in its own subdirectory, as opposed to being all
of the GIT repository (i.e. when a sub-project is merged into a
super-project).
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The rev-list command that is recent enough can filter commits
based on paths they touch, so use it instead of generating the
full list and limiting it by passing it with diff-tree --stdin.
[jc: The patch originally came from Luben Tuikov but the it was
corrupt, but it was short enough to be applied by hand. I
added the --full-history to make the output compatible with the
original while doing so.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
This IMNSHO cleans up the object hashing.
The hash expansion is separated out into a function of its own, the hash
array (and size) names are made more obvious, and the code is generally
made to look a bit more like the object-ref hashing.
It also gets rid of "find_object()" returning an index (or negative
position if no object is found), since that is made redundant by the
simplified object rehashing. The basic operation is now "lookup_object()"
which just returns the object itself.
There's an almost unmeasurable speed increase, but more importantly, I
think the end result is more readable.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With history simplification, we still show merges that are required
to make the history _complete_, i.e. say that you had:
a
|
b
/ \
c d
| |
and neither "a" nor "b" actually changed the file, but both "c" and "d"
did: in this case we have to leave "b" around just because otherwise there
would be no way to show the _relationship_, even if "b" itself doesn't
actually change the tree in any way what-so-ever.
It would make sense to make that further simplification if the
"--parents" flag wasn't present. In that case the user is
literally asking for a list of commits and is not interested in
the relationship between them.
This patch also fixes a real bug. Without this patch, the
"--parents --full-history" combination (which you'd get if you
do something like
gitk --full-history Makefile
or similar) will actually _drop_ merges where all children are identical.
That's wrong in the --full-history case, because it means that the graph
ends up missing lots of entries.
In the process, this also should make
git-rev-list --full-history Makefile
give just the _true_ list of all commits that changed Makefile (and
properly ignore merges that were identical in one parent), because now
we're not asking for "--parent", so we don't need the unnecessary merge
commits to keep the history together.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't care if objects have been parsed or not and don't stop when we
reach a commit that is already clean -- its parents could be dirty.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
'A...B' is a shortcut for 'A B --not $(git-merge-base --all A B)'.
This XOR-like operation is called symmetric difference in set
theory.
The symbol '...' has been chosen because it's rather similar to the
existing '..' operator and the somewhat more natural caret ('^') is
already taken.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add get_merge_bases_clean(), a wrapper for get_merge_bases() that cleans
up after doing its work and make get_merge_bases() NOT clean up.
Single-shot programs like git-merge-base can use the dirty and fast
version.
Also move the object flags used in get_merge_bases() out of the range
defined in revision.h. This fixes the "66ae0c77...ced9456a
89719209...262a6ef7" test of the ... operator which is introduced with
the next patch.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
errno was used after it could've been modified by a subsequent library call.
Spotted by Morten Welinder.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn init url://to/the/repo local-repo
will create the local-repo dirrectory if doesn't exist yet and
populate it as expected.
Original patch by Luca Barbato, cleaned up and made to work for
the current version of git-svn by me (Eric Wong).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If no delta is attempted on some objects then it is useless to load them
in memory, neither create any delta index for them. The best thing to
do is therefore to load and index them only when really needed.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merlyn reports that <sys/poll.h> on OpenBSD 3.8 includes <ctype.h>
and having our custom ctype (done in git-compat-util.h which is
included via cache.h) makes upload-pack.c uncompilable. Try to
work it around by including the system headers first.
Signed-off-by: Junio C Hamano <junkio@cox.net>
There are a few special places where some programs accessed the object
hash array directly, which bothered me because I wanted to play with some
simple re-organizations.
So this patch makes the object hash array data structures all entirely
local to object.c, and the few users who wanted to look at it now get to
use a function to query how many object index entries there can be, and to
actually access the array.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this there would never be a chance to improve packing for
previously undeltified objects.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In the repacking window, if both objects we are looking at already came
from the same (old) pack-file, don't bother delta'ing them against each
other.
That means that we'll still always check for better deltas for (and
against!) _unpacked_ objects, but assuming incremental repacks, you'll
avoid the delta creation 99% of the time.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 29e4d36357 fixed the
underlying update-index races but git-commit was not careful
enough to preserve the index file timestamp when copying the
index file. This caused t3402 test to occasionally fail.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* js/patch:
diff.c: fix get_patch_id()
t4014: fix test commit labels.
format-patch: use clear_commit_marks() instead of some ad-hockery
t4014: fix for whitespace from "wc -l"
t4014: add format-patch --ignore-if-in-upstream test
format-patch: introduce "--ignore-if-in-upstream"
add diff_flush_patch_id() to calculate the patch id
The function internally generated diff to get the patch id but
passed a wrong emit flags to the xdiff layer when it did so.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The commit tag and commit comments used in the test claimed that
the #1 commit was merged upstream where the test actually let the
upstream merge #2 commit. Fix them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fleshes out the code that generates a three-way merge of a set of
blobs.
It still actually does the three-way merge using an external executable
(ie just calling "merge"), but the interfaces have been cleaned up a lot
and are now fully based on the 'mmfile_t' interface, so if libxdiff were
to ever grow a compatible three-way-merge, it could probably be directly
plugged in.
It also uses the previous XDL_EMIT_COMMON functionality extension to
libxdiff to generate a made-up base file for the merge for the case where
no base file previously existed. This should be equivalent to what we
currently do in git-merge-one-file.sh:
diff -u -La/$orig -Lb/$orig $orig $src2 | git-apply --no-add
except it should be much simpler and can be done using the direct libxdiff
interfaces.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes how "git-merge-tree" works in two ways:
- instead of printing things out as we walk the trees, we save the
results in memory.
- when we've walked the tree fully, we print out the results in a more
explicit way, describing the data.
This is basically preparatory work for extending the git-merge-tree
functionality in interesting directions.
In particular, git-merge-tree is also how you would create a diff between
two trees _without_ necessarily creating the merge commit itself. In other
words, if you were to just wonder what another branch adds, you should be
able to (eventually) just do
git merge-tree -p $base HEAD $otherbranch
to generate a diff of what the merge would look like. The current merge
tree already basically has all the smarts for this, and the explanation of
the results just means that hopefully somebody else than me could do the
boring work.
(You'd basically be able to do the above diff by just changing the
printout format for the explanation, and making the "changed in both"
first do a three-way merge before it diffs the result).
The other thing that the in-memory format allows is rename detection
(which the current code does not do). That's the basic reason why we don't
want to just explain the differences as we go along - because we want to
be able to look at the _other_ differences to see whether the reason an
entry got deleted in either branch was perhaps because it got added in
another place..
Rename detection should be a fairly trivial pass in between the tree
diffing and the explanation.
In the meantime, this doesn't actually do anything new, it just outputs
the information in a more verbose manner.
For an example merge, commit 5ab2c0a475 in
the git tree works well and shows renames, along with true removals and
additions and files that got changed in both branches. To see that as a
tree merge, do:
git-merge-tree 64e86c57c5c23745928e47e3
where the two last ones are the tips that got merged, and the first one is
the merge base.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fairly trivial patch adds a new XDL_EMIT_xxx flag to tell libxdiff
that we don't want to generate the _diff_ between two files, we want to
see the lines that are _common_ to two files.
So when you set XDL_EMIT_COMMON, xdl_diff() will do everything exactly
like it used to do, but the output records it generates just contain the
lines that aren't part of the diff.
This is for doing things like generating the common base case for a file
that was added in both branches.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we updated "read-tree -m -u" to be careful about not
removing untracked working tree files, we broke "checkout -m" to
switch between branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano