When called with "--walk-reflogs", as long as there are reflogs
available, the walker will take this information into account, rather
than the parent information in the commit object.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It used to ignore the return value of the helper function; now, it
expects it to return 0, and stops iteration upon non-zero return
values; this value is then passed on as the return value of
for_each_reflog_ent().
Further, it makes no sense to force the parsing upon the helper
functions; for_each_reflog_ent() now calls the helper function with
old and new sha1, the email, the timestamp & timezone, and the message.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/fsck-reflog:
Add git-reflog to .gitignore
reflog expire: do not punt on tags that point at non commits.
reflog expire: prune commits that are not incomplete
Don't crash during repack of a reflog with pruned commits.
git reflog expire
Move in_merge_bases() to commit.c
reflog: fix warning message.
Teach git-repack to preserve objects referred to by reflog entries.
Protect commits recorded in reflog from pruning.
add for_each_reflog_ent() iterator
If the user has been using reflog for a long time (e.g. since its
introduction) then it is very likely that an existing branch's
reflog may still mention commits which have long since been pruned
out of the repository.
Rather than aborting with a very useless error message during
git-repack, pack as many valid commits as we can get from the
reflog and let the user know that the branch's reflog contains
already pruned commits. A future 'git reflog expire' (or whatever
it finally winds up being called) can then be performed to expunge
those reflog entries.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds a new option --reflog to pack-objects and revision
machinery; do not bother documenting it for now, since this is
only useful for local repacking.
When the option is passed, objects reachable from reflog entries
are marked as interesting while computing the set of objects to
pack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds --skip=<n> option to revision traversal machinery.
Documentation and test were added by Robert Fitzsimons.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a mechanical clean-up of the way *.c files include
system header files.
(1) sources under compat/, platform sha-1 implementations, and
xdelta code are exempt from the following rules;
(2) the first #include must be "git-compat-util.h" or one of
our own header file that includes it first (e.g. config.h,
builtin.h, pkt-line.h);
(3) system headers that are included in "git-compat-util.h"
need not be included in individual C source files.
(4) "git-compat-util.h" does not have to include subsystem
specific header files (e.g. expat.h).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts commit 5761231975.
Feeding symmetric difference to gitk is so useful, and it is the
same for other graphical Porcelains. Rather than forcing them
to pass --no-left-right, making it optional.
Noticed and reported by Jeff King.
When using symmetric differences, I think the user almost always
would want to know which side of the symmetry each commit came
from. So this removes --left-right option from the command
line, and turns it on automatically when a symmetric difference
is used ("git log --merge" counts as a symmetric difference
between HEAD and MERGE_HEAD).
Just in case, a new option --no-left-right is provided to defeat
this, but I do not know if it would be useful.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The output from "symmetric diff", i.e. A...B, does not
distinguish between commits that are reachable from A and the
ones that are reachable from B. In this picture, such a
symmetric diff includes commits marked with a and b.
x---b---b branch B
/ \ /
/ .
/ / \
o---x---a---a branch A
However, you cannot tell which ones are 'a' and which ones are
'b' from the output. Sometimes this is frustrating. This adds
an output option, --left-right, to rev-list.
rev-list --left-right A...B
would show ones reachable from A prefixed with '<' and the ones
reachable from B prefixed with '>'.
When combined with --boundary, boundary commits (the ones marked
with 'x' in the above picture) are shown with prefix '-', so you
would see list that looks like this:
git rev-list --left-right --boundary --pretty=oneline A...B
>bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 3rd on b
>bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2nd on b
<aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 3rd on a
<aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2nd on a
-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on b
-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on a
Signed-off-by: Junio C Hamano <junkio@cox.net>
* lj/refs: (63 commits)
Fix show-ref usagestring
t3200: git-branch testsuite update
sha1_name.c: avoid compilation warnings.
Make git-branch a builtin
ref-log: fix D/F conflict coming from deleted refs.
git-revert with conflicts to behave as git-merge with conflicts
core.logallrefupdates thinko-fix
git-pack-refs --all
core.logallrefupdates create new log file only for branch heads.
Remove bashism from t3210-pack-refs.sh
ref-log: allow ref@{count} syntax.
pack-refs: call fflush before fsync.
pack-refs: use lockfile as everybody else does.
git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
lock_ref_sha1_basic does not remove empty directories on BSD
Do not create tag leading directories since git update-ref does it.
Check that a tag exists using show-ref instead of looking for the ref file.
Use git-update-ref to delete a tag instead of rm()ing the ref file.
Fix refs.c;:repack_without_ref() clean-up path
Clean up "git-branch.sh" and add remove recursive dir test cases.
...
This is a shorthand for "<rev> --not <rev>^@", i.e. "include
this commit but exclude any of its parents".
When a new file $F is introduced by revision $R, this notation
can be used to find a copy-and-paste from existing file in the
parents of that revision without annotating the ancestry of the
lines that were copied from:
git pickaxe -f -C $R^! -- $F
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
revision traversal: --unpacked does not limit commit list anymore.
Continue traversal when rev-list --unpacked finds a packed commit.
Use memmove instead of memcpy for overlapping areas
quote.c: ensure the same quoting across platforms.
Surround "#define DEBUG 0" with "#ifndef DEBUG..#endif"
When getting the list of all unpacked objects by walking the commit history,
we would stop traversal whenever we hit a packed commit. However the fact
that we found a packed commit does not guarantee that all previous commits
are also packed. As a result the commit walkers did not show all reachable
unpacked objects.
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This lets you say:
git log --all-match --author=Linus --committer=Junio --grep=rev-list
to limit commits that was written by Linus, committed by me and
the log message contains word "rev-list".
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master: (72 commits)
runstatus: do not recurse into subdirectories if not needed
grep: fix --fixed-strings combined with expression.
grep: free expressions and patterns when done.
Corrected copy-and-paste thinko in ignore executable bit test case.
An illustration of rev-list --parents --pretty=raw
Allow git-checkout when on a non-existant branch.
gitweb: Decode long title for link tooltips
git-svn: Fix fetch --no-ignore-externals with GIT_SVN_NO_LIB=1
Ignore executable bit when adding files if filemode=0.
Remove empty ref directories that prevent creating a ref.
Use const for interpolate arguments
git-archive: update documentation
Deprecate merge-recursive.py
gitweb: fix over-eager application of esc_html().
Allow '(no author)' in git-svn's authors file.
Allow 'svn fetch' on '(no date)' revisions in Subversion.
git-repack: allow git-repack to run in subdirectory
Remove upload-tar and make git-tar-tree a thin wrapper to git-archive
git-tar-tree: Move code for git-archive --format=tar to archive-tar.c
git-tar-tree: Remove duplicate git_config() call
...
This adds a "int *flag" parameter to resolve_ref() and makes
for_each_ref() family to call callback function with an extra
"int flag" parameter. They are used to give two bits of
information (REF_ISSYMREF and REF_ISPACKED) about the ref.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a long overdue fix to the API for for_each_ref() family
of functions. It allows the callers to specify a callback data
pointer, so that the caller does not have to use static
variables to communicate with the callback funciton.
The updated for_each_ref() family takes a function of type
int (*fn)(const char *, const unsigned char *, void *)
and a void pointer as parameters, and calls the function with
the name of the ref and its SHA-1 with the caller-supplied void
pointer as parameters.
The commit updates two callers, builtin-name-rev.c and
builtin-pack-refs.c as an example.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now we can tell the built-in grep to grep only in head or in
body, use that to update --author, --committer, and --grep.
Unfortunately, to make --and, --not and other grep boolean
expressions useful, as in:
# Things written by Junio committed and by Linus and log
# does not talk about diff.
git log --author=Junio --and --committer=Linus \
--grep-not --grep=diff
we will need to do another round of built-in grep core
enhancement, because grep boolean expressions are designed to
work on one line at a time.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I know that I'd prefer a rule where
"--author=^Junio"
would result in the grep-pattern being "^author Junio", but without the
initial '^' it would be "^author .*Junio".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds three options to setup_revisions(), which lets you
filter resulting commits by the author name, the committer name
and the log message with regexp.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is from a suggestion by Linus, just to mark the locations where we
need to modify to actually implement the filtering.
We do not have any actual filtering code yet.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Incremental repack without -a essentially boils down to:
rev-list --objects --unpacked --all |
pack-objects $new_pack
which picks up all loose objects that are still live and creates
a new pack.
This implements --unpacked=<existing pack> option to tell the
revision walking machinery to pretend as if objects in such a
pack are unpacked for the purpose of object listing. With this,
we could say:
rev-list --objects --unpacked=$active_pack --all |
pack-objects $new_pack
instead, to mean "all live loose objects but pretend as if
objects that are in this pack are also unpacked". The newly
created pack would be perfect for updating $active_pack by
replacing it.
Since pack-objects now knows how to do the rev-list's work
itself internally, you can also write the above example by:
pack-objects --unpacked=$active_pack --all $new_pack </dev/null
Signed-off-by: Junio C Hamano <junkio@cox.net>
setup_revisions() wants to get all the parameters at once and
then postprocesses the resulting revs structure after it is done
with them. This code structure is a bit cumbersome to deal with
efficiently when we want to inject revision parameters from the
side (e.g. read from standard input).
Fortunately, the nature of this postprocessing is not affected by
revision parameters; they are affected only by flags. So it is
Ok to do add_object() after the it returns.
This splits out the code that deals with the revision parameter
out of the main loop of setup_revisions(), so that we can later
call it from elsewhere after it returns.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This abstracts away the size of the hash values when copying them
from memory location to memory location, much as the introduction
of hashcmp abstracted away hash value comparsion.
A few call sites were using char* rather than unsigned char* so
I added the cast rather than open hashcpy to be void*. This is a
reasonable tradeoff as most call sites already use unsigned char*
and the existing hashcmp is also declared to be unsigned char*.
[jc: Splitted the patch to "master" part, to be followed by a
patch for merge-recursive.c which is not in "master" yet.
Fixed the cast in the latter hunk to combine-diff.c which was
wrong in the original.
Also converted ones left-over in combine-diff.c, diff-lib.c and
upload-pack.c ]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Any git command that expects to work in a subdirectory of a project, and
that reads the git config files (which is just about all of them) needs to
make sure that it does the "setup_git_directory()" call before it tries to
read the config file.
This means, among other things, that we need to move the call out of
"init_revisions()", and into the caller.
This does the mostly trivial conversion to do that.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the type-enumeration constants introduced to reduce
the memory footprint of "struct object" to match the type bits
already used in the packfile format, by removing the former
(i.e. TYPE_* constant macros) and using the latter (i.e. enum
object_type) throughout the code for consistency.
Eventually we can stop passing around the "type strings"
entirely, and this will help - no confusion about two different
integer enumeration.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds Linus's wish, "--merge" flag, which makes the above
expand to a rough equivalent to:
git log -p HEAD MERGE_HEAD ^$(git-merge-base HEAD MERGE_HEAD) \
-- $(git-ls-files -u [paths...] | cut -f2 | uniq)
Signed-off-by: Junio C Hamano <junkio@cox.net>
* th/diff:
builtin-diff: turn recursive on when defaulting to --patch format.
t4013: note improvements brought by the new output code.
t4013: add format-patch tests.
format-patch: fix diff format option implementation
combine-diff.c: type sanity.
t4013 test updates for new output code.
Fix some more diff options changes.
Fix diff-tree -s
log --raw: Don't descend into subdirectories by default
diff-tree: Use ---\n as a message separator
Print empty line between raw, stat, summary and patch
t4013: add more tests around -c and --cc
whatchanged: Default to DIFF_FORMAT_RAW
Don't xcalloc() struct diffstat_t
Add msg_sep to diff_options
DIFF_FORMAT_RAW is not default anymore
Set default diff output format after parsing command line
Make --raw option available for all diff commands
Merge with_raw, with_stat and summary variables to output_format
t4013: add tests for diff/log family output options.
Johannes noticed the missing call to free_commit_list() in the
patch from Santi to add ... support to rev-parse. Turns out I
forgot it too in rev-list. This patch is against the next branch
(3b1d06a).
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
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>
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>
'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>
diff_setup() used to initialize output_format to DIFF_FORMAT_RAW. Now
the default is 0 (no output) so don't compare against DIFF_FORMAT_RAW to
see if any diff format command line flags were given.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We've had this notion of a "object_list" for a long time, which eventually
grew a "name" member because some users (notably git-rev-list) wanted to
name each object as it is generated.
That object_list is great for some things, but it isn't all that wonderful
for others, and the "name" member is generally not used by everybody.
This patch splits the users of the object_list array up into two: the
traditional list users, who want the list-like format, and who don't
actually use or want the name. And another class of users that really used
the list as an extensible array, and generally wanted to name the objects.
The patch is fairly straightforward, but it's also biggish. Most of it
really just cleans things up: switching the revision parsing and listing
over to the array makes things like the builtin-diff usage much simpler
(we now see exactly how many members the array has, and we don't get the
objects reversed from the order they were on the command line).
One of the main reasons for doing this at all is that the malloc overhead
of the simple object list was actually pretty high, and the array is just
a lot denser. So this patch brings down memory usage by git-rev-list by
just under 3% (on top of all the other memory use optimizations) on the
mozilla archive.
It does add more lines than it removes, and more importantly, it adds a
whole new infrastructure for maintaining lists of objects, but on the
other hand, the new dynamic array code is pretty obvious. The change to
builtin-diff-tree.c shows a fairly good example of why an array interface
is sometimes more natural, and just much simpler for everybody.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is really the dregs of my effort to not waste memory in git-rev-list,
and makes barely one percent of a difference in the memory footprint, but
hey, it's also a pretty small patch.
It discards the parent lists and the commit buffer after the commit has
been shown by git-rev-list (and "git log" - which already did the commit
buffer part), and frees the commit list entry that was used by the
revision walker.
The big win would be to get rid of the "refs" pointer in the object
structure (another 5%), because it's only used by fsck. That would require
some pretty major surgery to fsck, though, so I'm timid and did the less
interesting but much easier part instead.
This (percentually) makes a bigger difference to "git log" and friends,
since those are walking _just_ commits, and thus the list entries tend to
be a bigger percentage of the memory use. But the "list all objects" case
does improve too.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.
In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.
Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.
This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.
There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.
Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This does:
- add a "rev.simplify_history" flag which defaults to on
- it turns it off for "git whatchanged" (which thus now has real
semantics outside of "git log")
- it adds a command line flag ("--full-history") to turn it off for
others (ie you can make "git log" and "gitk" etc get the semantics if
you want to.
Now, just as an example of _why_ you really really really want to simplify
history by default, apply this patch, install it, and try these two
command lines:
gitk --full-history -- git.c
gitk -- git.c
and compare the output.
So with this, you can also now do
git whatchanged -p -- gitweb.cgi
git log -p --full-history -- gitweb.cgi
and it will show the old history of gitweb.cgi, even though it's not
relevant to the _current_ state of the name "gitweb.cgi"
NOTE NOTE NOTE! It will still actually simplify away merges that didn't
change anything at all into either child. That creates these bogus strange
discontinuities if you look at it with "gitk" (look at the --full-history
gitk output for git.c, and you'll see a few strange cases).
So the whole "--parent" thing ends up somewhat bogus with --full-history
because of this, but I'm not sure it's worth even worrying about. I don't
think you'd ever want to really use "--full-history" with the graphical
representation, I just give it as an example exactly to show _why_ doing
so would be insane.
I think this is trivial enough and useful enough to be worth merging into
the stable branch.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
