2005-04-18 20:39:48 +02:00
|
|
|
#ifndef COMMIT_H
|
|
|
|
|
#define COMMIT_H
|
|
|
|
|
|
|
|
|
|
#include "object.h"
|
|
|
|
|
#include "tree.h"
|
2007-09-10 12:35:06 +02:00
|
|
|
#include "strbuf.h"
|
2007-04-17 01:05:10 +02:00
|
|
|
#include "decorate.h"
|
2013-03-31 18:00:14 +02:00
|
|
|
#include "gpg-interface.h"
|
teach format-patch to place other authors into in-body "From"
Format-patch generates emails with the "From" address set to the
author of each patch. If you are going to send the emails, however,
you would want to replace the author identity with yours (if they
are not the same), and bump the author identity to an in-body
header.
Normally this is handled by git-send-email, which does the
transformation before sending out the emails. However, some
workflows may not use send-email (e.g., imap-send, or a custom
script which feeds the mbox to a non-git MUA). They could each
implement this feature themselves, but getting it right is
non-trivial (one must canonicalize the identities by reversing any
RFC2047 encoding or RFC822 quoting of the headers, which has caused
many bugs in send-email over the years).
This patch takes a different approach: it teaches format-patch a
"--from" option which handles the ident check and in-body header
while it is writing out the email. It's much simpler to do at this
level (because we haven't done any quoting yet), and any workflow
based on format-patch can easily turn it on.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-03 09:08:22 +02:00
|
|
|
#include "string-list.h"
|
2005-04-18 20:39:48 +02:00
|
|
|
|
|
|
|
|
struct commit_list {
|
|
|
|
|
struct commit *item;
|
|
|
|
|
struct commit_list *next;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct commit {
|
|
|
|
|
struct object object;
|
2006-06-18 03:26:18 +02:00
|
|
|
void *util;
|
2013-04-09 08:52:56 +02:00
|
|
|
unsigned int index;
|
2005-04-18 20:39:48 +02:00
|
|
|
unsigned long date;
|
|
|
|
|
struct commit_list *parents;
|
|
|
|
|
struct tree *tree;
|
|
|
|
|
};
|
|
|
|
|
|
[PATCH] Avoid wasting memory in git-rev-list
As pointed out on the list, git-rev-list can use a lot of memory.
One low-hanging fruit is to free the commit buffer for commits that we
parse. By default, parse_commit() will save away the buffer, since a lot
of cases do want it, and re-reading it continually would be unnecessary.
However, in many cases the buffer isn't actually necessary and saving it
just wastes memory.
We could just free the buffer ourselves, but especially in git-rev-list,
we actually end up using the helper functions that automatically add
parent commits to the commit lists, so we don't actually control the
commit parsing directly.
Instead, just make this behaviour of "parse_commit()" a global flag.
Maybe this is a bit tasteless, but it's very simple, and it makes a
noticable difference in memory usage.
Before the change:
[torvalds@g5 linux]$ /usr/bin/time git-rev-list v2.6.12..HEAD > /dev/null
0.26user 0.02system 0:00.28elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3714minor)pagefaults 0swaps
after the change:
[torvalds@g5 linux]$ /usr/bin/time git-rev-list v2.6.12..HEAD > /dev/null
0.26user 0.00system 0:00.27elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2433minor)pagefaults 0swaps
note how the minor faults have decreased from 3714 pages to 2433 pages.
That's all due to the fewer anonymous pages allocated to hold the comment
buffers and their metadata.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-15 23:43:17 +02:00
|
|
|
extern int save_commit_buffer;
|
2005-04-18 20:39:48 +02:00
|
|
|
extern const char *commit_type;
|
|
|
|
|
|
2007-04-17 01:05:10 +02:00
|
|
|
/* While we can decorate any object with a name, it's only used for commits.. */
|
|
|
|
|
struct name_decoration {
|
|
|
|
|
struct name_decoration *next;
|
2010-06-19 03:37:33 +02:00
|
|
|
int type;
|
2014-08-26 12:24:20 +02:00
|
|
|
char name[FLEX_ARRAY];
|
2007-04-17 01:05:10 +02:00
|
|
|
};
|
|
|
|
|
|
2014-08-26 12:23:36 +02:00
|
|
|
enum decoration_type {
|
|
|
|
|
DECORATION_NONE = 0,
|
|
|
|
|
DECORATION_REF_LOCAL,
|
|
|
|
|
DECORATION_REF_REMOTE,
|
|
|
|
|
DECORATION_REF_TAG,
|
|
|
|
|
DECORATION_REF_STASH,
|
|
|
|
|
DECORATION_REF_HEAD,
|
|
|
|
|
DECORATION_GRAFTED,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void add_name_decoration(enum decoration_type type, const char *name, struct object *obj);
|
2014-08-26 12:23:54 +02:00
|
|
|
const struct name_decoration *get_name_decoration(const struct object *obj);
|
2014-08-26 12:23:36 +02:00
|
|
|
|
2005-06-03 17:05:39 +02:00
|
|
|
struct commit *lookup_commit(const unsigned char *sha1);
|
|
|
|
|
struct commit *lookup_commit_reference(const unsigned char *sha1);
|
2005-08-21 11:51:10 +02:00
|
|
|
struct commit *lookup_commit_reference_gently(const unsigned char *sha1,
|
|
|
|
|
int quiet);
|
2010-11-02 20:59:07 +01:00
|
|
|
struct commit *lookup_commit_reference_by_name(const char *name);
|
2005-04-18 20:39:48 +02:00
|
|
|
|
2011-09-17 13:57:45 +02:00
|
|
|
/*
|
|
|
|
|
* Look up object named by "sha1", dereference tag as necessary,
|
|
|
|
|
* get a commit and return it. If "sha1" does not dereference to
|
|
|
|
|
* a commit, use ref_name to report an error and die.
|
|
|
|
|
*/
|
|
|
|
|
struct commit *lookup_commit_or_die(const unsigned char *sha1, const char *ref_name);
|
|
|
|
|
|
2011-02-05 11:52:20 +01:00
|
|
|
int parse_commit_buffer(struct commit *item, const void *buffer, unsigned long size);
|
add quieter versions of parse_{tree,commit}
When we call parse_commit, it will complain to stderr if the
object does not exist or cannot be read. This means that we
may produce useless error messages if this situation is
expected (e.g., because the object is marked UNINTERESTING,
or because revs->ignore_missing_links is set).
We can fix this by adding a new "parse_X_gently" form that
takes a flag to suppress the messages. The existing
"parse_X" form is already gentle in the sense that it
returns an error rather than dying, and we could in theory
just add a "quiet" flag to it (with existing callers passing
"0"). But doing it this way means we do not have to disturb
existing callers.
Note also that the new flag is "quiet_on_missing", and not
just "quiet". We could add a flag to suppress _all_ errors,
but besides being a more invasive change (we would have to
pass the flag down to sub-functions, too), there is a good
reason not to: we would never want to use it. Missing a
linked object is expected in some circumstances, but it is
never expected to have a malformed commit, or to get a tree
when we wanted a commit. We should always complain about
these corruptions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01 11:56:26 +02:00
|
|
|
int parse_commit_gently(struct commit *item, int quiet_on_missing);
|
|
|
|
|
static inline int parse_commit(struct commit *item)
|
|
|
|
|
{
|
|
|
|
|
return parse_commit_gently(item, 0);
|
|
|
|
|
}
|
2013-10-24 10:52:36 +02:00
|
|
|
void parse_commit_or_die(struct commit *item);
|
2005-04-18 20:39:48 +02:00
|
|
|
|
2014-06-10 23:40:14 +02:00
|
|
|
/*
|
|
|
|
|
* Associate an object buffer with the commit. The ownership of the
|
|
|
|
|
* memory is handed over to the commit, and must be free()-able.
|
|
|
|
|
*/
|
2014-06-10 23:44:13 +02:00
|
|
|
void set_commit_buffer(struct commit *, void *buffer, unsigned long size);
|
2014-06-10 23:40:14 +02:00
|
|
|
|
2014-06-10 23:40:39 +02:00
|
|
|
/*
|
|
|
|
|
* Get any cached object buffer associated with the commit. Returns NULL
|
|
|
|
|
* if none. The resulting memory should not be freed.
|
|
|
|
|
*/
|
2014-06-10 23:44:13 +02:00
|
|
|
const void *get_cached_commit_buffer(const struct commit *, unsigned long *size);
|
2014-06-10 23:40:39 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Get the commit's object contents, either from cache or by reading the object
|
|
|
|
|
* from disk. The resulting memory should not be modified, and must be given
|
|
|
|
|
* to unuse_commit_buffer when the caller is done.
|
|
|
|
|
*/
|
2014-06-10 23:44:13 +02:00
|
|
|
const void *get_commit_buffer(const struct commit *, unsigned long *size);
|
2014-06-10 23:40:39 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Tell the commit subsytem that we are done with a particular commit buffer.
|
|
|
|
|
* The commit and buffer should be the input and return value, respectively,
|
|
|
|
|
* from an earlier call to get_commit_buffer. The buffer may or may not be
|
|
|
|
|
* freed by this call; callers should not access the memory afterwards.
|
|
|
|
|
*/
|
|
|
|
|
void unuse_commit_buffer(const struct commit *, const void *buffer);
|
|
|
|
|
|
provide a helper to free commit buffer
This converts two lines into one at each caller. But more
importantly, it abstracts the concept of freeing the buffer,
which will make it easier to change later.
Note that we also need to provide a "detach" mechanism for a
tricky case in index-pack. We are passed a buffer for the
object generated by processing the incoming pack. If we are
not using --strict, we just calculate the sha1 on that
buffer and return, leaving the caller to free it. But if we
are using --strict, we actually attach that buffer to an
object, pass the object to the fsck functions, and then
detach the buffer from the object again (so that the caller
can free it as usual). In this case, we don't want to free
the buffer ourselves, but just make sure it is no longer
associated with the commit.
Note that we are making the assumption here that the
attach/detach process does not impact the buffer at all
(e.g., it is never reallocated or modified). That holds true
now, and we have no plans to change that. However, as we
abstract the commit_buffer code, this dependency becomes
less obvious. So when we detach, let's also make sure that
we get back the same buffer that we gave to the
commit_buffer code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13 00:05:37 +02:00
|
|
|
/*
|
|
|
|
|
* Free any cached object buffer associated with the commit.
|
|
|
|
|
*/
|
|
|
|
|
void free_commit_buffer(struct commit *);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Disassociate any cached object buffer from the commit, but do not free it.
|
|
|
|
|
* The buffer (or NULL, if none) is returned.
|
|
|
|
|
*/
|
2014-06-10 23:44:13 +02:00
|
|
|
const void *detach_commit_buffer(struct commit *, unsigned long *sizep);
|
provide a helper to free commit buffer
This converts two lines into one at each caller. But more
importantly, it abstracts the concept of freeing the buffer,
which will make it easier to change later.
Note that we also need to provide a "detach" mechanism for a
tricky case in index-pack. We are passed a buffer for the
object generated by processing the incoming pack. If we are
not using --strict, we just calculate the sha1 on that
buffer and return, leaving the caller to free it. But if we
are using --strict, we actually attach that buffer to an
object, pass the object to the fsck functions, and then
detach the buffer from the object again (so that the caller
can free it as usual). In this case, we don't want to free
the buffer ourselves, but just make sure it is no longer
associated with the commit.
Note that we are making the assumption here that the
attach/detach process does not impact the buffer at all
(e.g., it is never reallocated or modified). That holds true
now, and we have no plans to change that. However, as we
abstract the commit_buffer code, this dependency becomes
less obvious. So when we detach, let's also make sure that
we get back the same buffer that we gave to the
commit_buffer code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13 00:05:37 +02:00
|
|
|
|
2010-07-22 15:18:30 +02:00
|
|
|
/* Find beginning and length of commit subject. */
|
|
|
|
|
int find_commit_subject(const char *commit_buffer, const char **subject);
|
|
|
|
|
|
2010-11-27 02:58:14 +01:00
|
|
|
struct commit_list *commit_list_insert(struct commit *item,
|
|
|
|
|
struct commit_list **list);
|
2012-04-25 22:35:27 +02:00
|
|
|
struct commit_list **commit_list_append(struct commit *commit,
|
|
|
|
|
struct commit_list **next);
|
2008-06-27 18:21:55 +02:00
|
|
|
unsigned commit_list_count(const struct commit_list *l);
|
2010-11-27 02:58:14 +01:00
|
|
|
struct commit_list *commit_list_insert_by_date(struct commit *item,
|
|
|
|
|
struct commit_list **list);
|
|
|
|
|
void commit_list_sort_by_date(struct commit_list **list);
|
2005-04-24 03:47:23 +02:00
|
|
|
|
log: use true parents for diff even when rewriting
When using pathspec filtering in combination with diff-based log
output, parent simplification happens before the diff is computed.
The diff is therefore against the *simplified* parents.
This works okay, arguably by accident, in the normal case:
simplification reduces to one parent as long as the commit is TREESAME
to it. So the simplified parent of any given commit must have the
same tree contents on the filtered paths as its true (unfiltered)
parent.
However, --full-diff breaks this guarantee, and indeed gives pretty
spectacular results when comparing the output of
git log --graph --stat ...
git log --graph --full-diff --stat ...
(--graph internally kicks in parent simplification, much like
--parents).
To fix it, store a copy of the parent list before simplification (in a
slab) whenever --full-diff is in effect. Then use the stored parents
instead of the simplified ones in the commit display code paths. The
latter do not actually check for --full-diff to avoid duplicated code;
they just grab the original parents if save_parents() has not been
called for this revision walk.
For ordinary commits it should be obvious that this is the right thing
to do.
Merge commits are a bit subtle. Observe that with default
simplification, merge simplification is an all-or-nothing decision:
either the merge is TREESAME to one parent and disappears, or it is
different from all parents and the parent list remains intact.
Redundant parents are not pruned, so the existing code also shows them
as a merge.
So if we do show a merge commit, the parent list just consists of the
rewrite result on each parent. Running, e.g., --cc on this in
--full-diff mode is not very useful: if any commits were skipped, some
hunks will disagree with all sides of the merge (with one side,
because commits were skipped; with the others, because they didn't
have those changes in the first place). This triggers --cc showing
these hunks spuriously.
Therefore I believe that even for merge commits it is better to show
the diffs wrt. the original parents.
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-31 22:13:20 +02:00
|
|
|
/* Shallow copy of the input list */
|
|
|
|
|
struct commit_list *copy_commit_list(struct commit_list *list);
|
|
|
|
|
|
2005-04-18 20:39:48 +02:00
|
|
|
void free_commit_list(struct commit_list *list);
|
|
|
|
|
|
2005-06-05 18:02:03 +02:00
|
|
|
/* Commit formats */
|
|
|
|
|
enum cmit_fmt {
|
|
|
|
|
CMIT_FMT_RAW,
|
|
|
|
|
CMIT_FMT_MEDIUM,
|
|
|
|
|
CMIT_FMT_DEFAULT = CMIT_FMT_MEDIUM,
|
2005-06-27 02:50:46 +02:00
|
|
|
CMIT_FMT_SHORT,
|
|
|
|
|
CMIT_FMT_FULL,
|
2005-11-10 07:15:27 +01:00
|
|
|
CMIT_FMT_FULLER,
|
2005-08-09 07:15:40 +02:00
|
|
|
CMIT_FMT_ONELINE,
|
2006-04-19 01:45:27 +02:00
|
|
|
CMIT_FMT_EMAIL,
|
2016-06-05 06:46:39 +02:00
|
|
|
CMIT_FMT_MBOXRD,
|
2007-02-23 01:35:03 +01:00
|
|
|
CMIT_FMT_USERFORMAT,
|
2006-04-16 08:46:36 +02:00
|
|
|
|
2010-05-14 11:31:35 +02:00
|
|
|
CMIT_FMT_UNSPECIFIED
|
2005-06-05 18:02:03 +02:00
|
|
|
};
|
|
|
|
|
|
2016-06-05 06:46:39 +02:00
|
|
|
static inline int cmit_fmt_is_mail(enum cmit_fmt fmt)
|
|
|
|
|
{
|
|
|
|
|
return (fmt == CMIT_FMT_EMAIL || fmt == CMIT_FMT_MBOXRD);
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-01 12:37:07 +01:00
|
|
|
struct rev_info; /* in revision.h, it circularly uses enum cmit_fmt */
|
|
|
|
|
|
2011-03-16 08:08:34 +01:00
|
|
|
struct pretty_print_context {
|
2013-07-03 09:07:48 +02:00
|
|
|
/*
|
|
|
|
|
* Callers should tweak these to change the behavior of pp_* functions.
|
|
|
|
|
*/
|
2011-05-27 00:27:49 +02:00
|
|
|
enum cmit_fmt fmt;
|
2009-10-19 17:48:08 +02:00
|
|
|
int abbrev;
|
|
|
|
|
const char *after_subject;
|
2011-05-27 00:28:17 +02:00
|
|
|
int preserve_subject;
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 18:55:02 +02:00
|
|
|
struct date_mode date_mode;
|
log: respect date_mode_explicit with --format:%gd
When we show a reflog selector (e.g., via "git log -g"), we
perform some DWIM magic: while we normally show the entry's
index (e.g., HEAD@{1}), if the user has given us a date
with "--date", then we show a date-based select (e.g.,
HEAD@{yesterday}).
However, we don't want to trigger this magic if the
alternate date format we got was from the "log.date"
configuration; that is not sufficiently strong context for
us to invoke this particular magic. To fix this, commit
f4ea32f (improve reflog date/number heuristic, 2009-09-24)
introduced a "date_mode_explicit" flag in rev_info. This
flag is set only when we see a "--date" option on the
command line, and we a vanilla date to the reflog code if
the date was not explicit.
Later, commit 8f8f547 (Introduce new pretty formats %g[sdD]
for reflog information, 2009-10-19) added another way to
show selectors, and it did not respect the date_mode_explicit
flag from f4ea32f.
This patch propagates the date_mode_explicit flag to the
pretty-print code, which can then use it to pass the
appropriate date field to the reflog code. This brings the
behavior of "%gd" in line with the other formats, and means
that its output is independent of any user configuration.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-04 07:25:18 +02:00
|
|
|
unsigned date_mode_explicit:1;
|
2017-03-01 12:37:07 +01:00
|
|
|
int print_email_subject;
|
2016-03-30 01:05:39 +02:00
|
|
|
int expand_tabs_in_log;
|
2009-10-19 17:48:08 +02:00
|
|
|
int need_8bit_cte;
|
2012-10-18 03:51:47 +02:00
|
|
|
char *notes_message;
|
2009-10-19 17:48:10 +02:00
|
|
|
struct reflog_walk_info *reflog_info;
|
2017-03-01 12:37:07 +01:00
|
|
|
struct rev_info *rev;
|
2010-11-02 20:59:08 +01:00
|
|
|
const char *output_encoding;
|
2013-01-05 22:26:41 +01:00
|
|
|
struct string_list *mailmap;
|
2012-12-17 23:56:49 +01:00
|
|
|
int color;
|
teach format-patch to place other authors into in-body "From"
Format-patch generates emails with the "From" address set to the
author of each patch. If you are going to send the emails, however,
you would want to replace the author identity with yours (if they
are not the same), and bump the author identity to an in-body
header.
Normally this is handled by git-send-email, which does the
transformation before sending out the emails. However, some
workflows may not use send-email (e.g., imap-send, or a custom
script which feeds the mbox to a non-git MUA). They could each
implement this feature themselves, but getting it right is
non-trivial (one must canonicalize the identities by reversing any
RFC2047 encoding or RFC822 quoting of the headers, which has caused
many bugs in send-email over the years).
This patch takes a different approach: it teaches format-patch a
"--from" option which handles the ident check and in-body header
while it is writing out the email. It's much simpler to do at this
level (because we haven't done any quoting yet), and any workflow
based on format-patch can easily turn it on.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-03 09:08:22 +02:00
|
|
|
struct ident_split *from_ident;
|
2013-07-03 09:07:48 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Fields below here are manipulated internally by pp_* functions and
|
|
|
|
|
* should not be counted on by callers.
|
|
|
|
|
*/
|
teach format-patch to place other authors into in-body "From"
Format-patch generates emails with the "From" address set to the
author of each patch. If you are going to send the emails, however,
you would want to replace the author identity with yours (if they
are not the same), and bump the author identity to an in-body
header.
Normally this is handled by git-send-email, which does the
transformation before sending out the emails. However, some
workflows may not use send-email (e.g., imap-send, or a custom
script which feeds the mbox to a non-git MUA). They could each
implement this feature themselves, but getting it right is
non-trivial (one must canonicalize the identities by reversing any
RFC2047 encoding or RFC822 quoting of the headers, which has caused
many bugs in send-email over the years).
This patch takes a different approach: it teaches format-patch a
"--from" option which handles the ident check and in-body header
while it is writing out the email. It's much simpler to do at this
level (because we haven't done any quoting yet), and any workflow
based on format-patch can easily turn it on.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-03 09:08:22 +02:00
|
|
|
struct string_list in_body_headers;
|
2016-06-16 15:18:37 +02:00
|
|
|
int graph_width;
|
2009-10-19 17:48:08 +02:00
|
|
|
};
|
|
|
|
|
|
2010-04-13 22:31:12 +02:00
|
|
|
struct userformat_want {
|
|
|
|
|
unsigned notes:1;
|
|
|
|
|
};
|
|
|
|
|
|
2009-08-10 18:22:18 +02:00
|
|
|
extern int has_non_ascii(const char *text);
|
2014-06-10 23:39:30 +02:00
|
|
|
extern const char *logmsg_reencode(const struct commit *commit,
|
|
|
|
|
char **commit_encoding,
|
|
|
|
|
const char *output_encoding);
|
2008-04-08 02:11:34 +02:00
|
|
|
extern void get_commit_format(const char *arg, struct rev_info *);
|
2011-04-07 20:26:23 +02:00
|
|
|
extern const char *format_subject(struct strbuf *sb, const char *msg,
|
|
|
|
|
const char *line_separator);
|
2010-04-13 22:31:12 +02:00
|
|
|
extern void userformat_find_requirements(const char *fmt, struct userformat_want *w);
|
2014-07-29 19:56:48 +02:00
|
|
|
extern int commit_format_is_empty(enum cmit_fmt);
|
2016-06-22 22:20:16 +02:00
|
|
|
extern const char *skip_blank_lines(const char *msg);
|
2007-09-10 12:35:06 +02:00
|
|
|
extern void format_commit_message(const struct commit *commit,
|
2009-10-16 07:59:41 +02:00
|
|
|
const char *format, struct strbuf *sb,
|
2009-10-19 17:48:08 +02:00
|
|
|
const struct pretty_print_context *context);
|
2013-07-03 09:07:48 +02:00
|
|
|
extern void pretty_print_commit(struct pretty_print_context *pp,
|
2011-05-27 00:27:49 +02:00
|
|
|
const struct commit *commit,
|
|
|
|
|
struct strbuf *sb);
|
2011-05-27 00:27:24 +02:00
|
|
|
extern void pp_commit_easy(enum cmit_fmt fmt, const struct commit *commit,
|
|
|
|
|
struct strbuf *sb);
|
2013-07-03 09:07:48 +02:00
|
|
|
void pp_user_info(struct pretty_print_context *pp,
|
2011-05-27 00:27:49 +02:00
|
|
|
const char *what, struct strbuf *sb,
|
|
|
|
|
const char *line, const char *encoding);
|
2013-07-03 09:07:48 +02:00
|
|
|
void pp_title_line(struct pretty_print_context *pp,
|
2008-02-19 04:56:08 +01:00
|
|
|
const char **msg_p,
|
|
|
|
|
struct strbuf *sb,
|
|
|
|
|
const char *encoding,
|
2008-03-15 08:09:20 +01:00
|
|
|
int need_8bit_cte);
|
2013-07-03 09:07:48 +02:00
|
|
|
void pp_remainder(struct pretty_print_context *pp,
|
2008-02-19 04:56:08 +01:00
|
|
|
const char **msg_p,
|
|
|
|
|
struct strbuf *sb,
|
|
|
|
|
int indent);
|
|
|
|
|
|
2005-06-01 17:34:23 +02:00
|
|
|
|
2005-04-24 03:47:23 +02:00
|
|
|
/** Removes the first commit from a list sorted by date, and adds all
|
|
|
|
|
* of its parents.
|
|
|
|
|
**/
|
2007-06-07 09:04:01 +02:00
|
|
|
struct commit *pop_most_recent_commit(struct commit_list **list,
|
2005-04-24 05:29:22 +02:00
|
|
|
unsigned int mark);
|
2005-04-24 03:47:23 +02:00
|
|
|
|
2005-06-06 17:39:40 +02:00
|
|
|
struct commit *pop_commit(struct commit_list **stack);
|
|
|
|
|
|
2006-01-08 03:52:42 +01:00
|
|
|
void clear_commit_marks(struct commit *commit, unsigned int mark);
|
2013-03-05 20:42:20 +01:00
|
|
|
void clear_commit_marks_many(int nr, struct commit **commit, unsigned int mark);
|
2011-10-01 18:16:08 +02:00
|
|
|
void clear_commit_marks_for_object_array(struct object_array *a, unsigned mark);
|
2006-01-08 03:52:42 +01:00
|
|
|
|
toposort: rename "lifo" field
The primary invariant of sort_in_topological_order() is that a
parent commit is not emitted until all children of it are. When
traversing a forked history like this with "git log C E":
A----B----C
\
D----E
we ensure that A is emitted after all of B, C, D, and E are done, B
has to wait until C is done, and D has to wait until E is done.
In some applications, however, we would further want to control how
these child commits B, C, D and E on two parallel ancestry chains
are shown.
Most of the time, we would want to see C and B emitted together, and
then E and D, and finally A (i.e. the --topo-order output). The
"lifo" parameter of the sort_in_topological_order() function is used
to control this behaviour. We start the traversal by knowing two
commits, C and E. While keeping in mind that we also need to
inspect E later, we pick C first to inspect, and we notice and
record that B needs to be inspected. By structuring the "work to be
done" set as a LIFO stack, we ensure that B is inspected next,
before other in-flight commits we had known that we will need to
inspect, e.g. E.
When showing in --date-order, we would want to see commits ordered
by timestamps, i.e. show C, E, B and D in this order before showing
A, possibly mixing commits from two parallel histories together.
When "lifo" parameter is set to false, the function keeps the "work
to be done" set sorted in the date order to realize this semantics.
After inspecting C, we add B to the "work to be done" set, but the
next commit we inspect from the set is E which is newer than B.
The name "lifo", however, is too strongly tied to the way how the
function implements its behaviour, and does not describe what the
behaviour _means_.
Replace this field with an enum rev_sort_order, with two possible
values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE, and
update the existing code. The mechanical replacement rule is:
"lifo == 0" is equivalent to "sort_order == REV_SORT_BY_COMMIT_DATE"
"lifo == 1" is equivalent to "sort_order == REV_SORT_IN_GRAPH_ORDER"
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 01:07:14 +02:00
|
|
|
|
|
|
|
|
enum rev_sort_order {
|
|
|
|
|
REV_SORT_IN_GRAPH_ORDER = 0,
|
2013-06-07 19:35:54 +02:00
|
|
|
REV_SORT_BY_COMMIT_DATE,
|
|
|
|
|
REV_SORT_BY_AUTHOR_DATE
|
toposort: rename "lifo" field
The primary invariant of sort_in_topological_order() is that a
parent commit is not emitted until all children of it are. When
traversing a forked history like this with "git log C E":
A----B----C
\
D----E
we ensure that A is emitted after all of B, C, D, and E are done, B
has to wait until C is done, and D has to wait until E is done.
In some applications, however, we would further want to control how
these child commits B, C, D and E on two parallel ancestry chains
are shown.
Most of the time, we would want to see C and B emitted together, and
then E and D, and finally A (i.e. the --topo-order output). The
"lifo" parameter of the sort_in_topological_order() function is used
to control this behaviour. We start the traversal by knowing two
commits, C and E. While keeping in mind that we also need to
inspect E later, we pick C first to inspect, and we notice and
record that B needs to be inspected. By structuring the "work to be
done" set as a LIFO stack, we ensure that B is inspected next,
before other in-flight commits we had known that we will need to
inspect, e.g. E.
When showing in --date-order, we would want to see commits ordered
by timestamps, i.e. show C, E, B and D in this order before showing
A, possibly mixing commits from two parallel histories together.
When "lifo" parameter is set to false, the function keeps the "work
to be done" set sorted in the date order to realize this semantics.
After inspecting C, we add B to the "work to be done" set, but the
next commit we inspect from the set is E which is newer than B.
The name "lifo", however, is too strongly tied to the way how the
function implements its behaviour, and does not describe what the
behaviour _means_.
Replace this field with an enum rev_sort_order, with two possible
values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE, and
update the existing code. The mechanical replacement rule is:
"lifo == 0" is equivalent to "sort_order == REV_SORT_BY_COMMIT_DATE"
"lifo == 1" is equivalent to "sort_order == REV_SORT_IN_GRAPH_ORDER"
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 01:07:14 +02:00
|
|
|
};
|
|
|
|
|
|
2005-07-06 18:39:34 +02:00
|
|
|
/*
|
|
|
|
|
* Performs an in-place topological sort of list supplied.
|
|
|
|
|
*
|
|
|
|
|
* invariant of resulting list is:
|
|
|
|
|
* a reachable from b => ord(b) < ord(a)
|
toposort: rename "lifo" field
The primary invariant of sort_in_topological_order() is that a
parent commit is not emitted until all children of it are. When
traversing a forked history like this with "git log C E":
A----B----C
\
D----E
we ensure that A is emitted after all of B, C, D, and E are done, B
has to wait until C is done, and D has to wait until E is done.
In some applications, however, we would further want to control how
these child commits B, C, D and E on two parallel ancestry chains
are shown.
Most of the time, we would want to see C and B emitted together, and
then E and D, and finally A (i.e. the --topo-order output). The
"lifo" parameter of the sort_in_topological_order() function is used
to control this behaviour. We start the traversal by knowing two
commits, C and E. While keeping in mind that we also need to
inspect E later, we pick C first to inspect, and we notice and
record that B needs to be inspected. By structuring the "work to be
done" set as a LIFO stack, we ensure that B is inspected next,
before other in-flight commits we had known that we will need to
inspect, e.g. E.
When showing in --date-order, we would want to see commits ordered
by timestamps, i.e. show C, E, B and D in this order before showing
A, possibly mixing commits from two parallel histories together.
When "lifo" parameter is set to false, the function keeps the "work
to be done" set sorted in the date order to realize this semantics.
After inspecting C, we add B to the "work to be done" set, but the
next commit we inspect from the set is E which is newer than B.
The name "lifo", however, is too strongly tied to the way how the
function implements its behaviour, and does not describe what the
behaviour _means_.
Replace this field with an enum rev_sort_order, with two possible
values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE, and
update the existing code. The mechanical replacement rule is:
"lifo == 0" is equivalent to "sort_order == REV_SORT_BY_COMMIT_DATE"
"lifo == 1" is equivalent to "sort_order == REV_SORT_IN_GRAPH_ORDER"
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 01:07:14 +02:00
|
|
|
* sort_order further specifies:
|
|
|
|
|
* REV_SORT_IN_GRAPH_ORDER: try to show a commit on a single-parent
|
|
|
|
|
* chain together.
|
|
|
|
|
* REV_SORT_BY_COMMIT_DATE: show eligible commits in committer-date order.
|
2005-07-06 18:39:34 +02:00
|
|
|
*/
|
toposort: rename "lifo" field
The primary invariant of sort_in_topological_order() is that a
parent commit is not emitted until all children of it are. When
traversing a forked history like this with "git log C E":
A----B----C
\
D----E
we ensure that A is emitted after all of B, C, D, and E are done, B
has to wait until C is done, and D has to wait until E is done.
In some applications, however, we would further want to control how
these child commits B, C, D and E on two parallel ancestry chains
are shown.
Most of the time, we would want to see C and B emitted together, and
then E and D, and finally A (i.e. the --topo-order output). The
"lifo" parameter of the sort_in_topological_order() function is used
to control this behaviour. We start the traversal by knowing two
commits, C and E. While keeping in mind that we also need to
inspect E later, we pick C first to inspect, and we notice and
record that B needs to be inspected. By structuring the "work to be
done" set as a LIFO stack, we ensure that B is inspected next,
before other in-flight commits we had known that we will need to
inspect, e.g. E.
When showing in --date-order, we would want to see commits ordered
by timestamps, i.e. show C, E, B and D in this order before showing
A, possibly mixing commits from two parallel histories together.
When "lifo" parameter is set to false, the function keeps the "work
to be done" set sorted in the date order to realize this semantics.
After inspecting C, we add B to the "work to be done" set, but the
next commit we inspect from the set is E which is newer than B.
The name "lifo", however, is too strongly tied to the way how the
function implements its behaviour, and does not describe what the
behaviour _means_.
Replace this field with an enum rev_sort_order, with two possible
values: REV_SORT_IN_GRAPH_ORDER and REV_SORT_BY_COMMIT_DATE, and
update the existing code. The mechanical replacement rule is:
"lifo == 0" is equivalent to "sort_order == REV_SORT_BY_COMMIT_DATE"
"lifo == 1" is equivalent to "sort_order == REV_SORT_IN_GRAPH_ORDER"
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07 01:07:14 +02:00
|
|
|
void sort_in_topological_order(struct commit_list **, enum rev_sort_order);
|
2006-04-07 08:58:51 +02:00
|
|
|
|
|
|
|
|
struct commit_graft {
|
2015-03-14 00:39:34 +01:00
|
|
|
struct object_id oid;
|
2006-10-30 20:09:06 +01:00
|
|
|
int nr_parent; /* < 0 if shallow commit */
|
2015-03-14 00:39:34 +01:00
|
|
|
struct object_id parent[FLEX_ARRAY]; /* more */
|
2006-04-07 08:58:51 +02:00
|
|
|
};
|
2011-08-18 14:29:35 +02:00
|
|
|
typedef int (*each_commit_graft_fn)(const struct commit_graft *, void *);
|
2006-04-07 08:58:51 +02:00
|
|
|
|
|
|
|
|
struct commit_graft *read_graft_line(char *buf, int len);
|
|
|
|
|
int register_commit_graft(struct commit_graft *, int);
|
2008-02-25 22:46:07 +01:00
|
|
|
struct commit_graft *lookup_commit_graft(const unsigned char *sha1);
|
2006-04-07 08:58:51 +02:00
|
|
|
|
2014-10-30 20:20:44 +01:00
|
|
|
extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2);
|
|
|
|
|
extern struct commit_list *get_merge_bases_many(struct commit *one, int n, struct commit **twos);
|
2008-06-27 18:22:00 +02:00
|
|
|
extern struct commit_list *get_octopus_merge_bases(struct commit_list *in);
|
2006-06-29 15:17:32 +02:00
|
|
|
|
2014-10-30 20:20:44 +01:00
|
|
|
/* To be used only when object flags after this call no longer matter */
|
|
|
|
|
extern struct commit_list *get_merge_bases_many_dirty(struct commit *one, int n, struct commit **twos);
|
|
|
|
|
|
2013-04-12 00:36:10 +02:00
|
|
|
/* largest positive number a signed 32-bit integer can contain */
|
2013-01-11 10:05:46 +01:00
|
|
|
#define INFINITE_DEPTH 0x7fffffff
|
|
|
|
|
|
2017-03-31 03:40:00 +02:00
|
|
|
struct oid_array;
|
shallow.c: the 8 steps to select new commits for .git/shallow
Suppose a fetch or push is requested between two shallow repositories
(with no history deepening or shortening). A pack that contains
necessary objects is transferred over together with .git/shallow of
the sender. The receiver has to determine whether it needs to update
.git/shallow if new refs needs new shallow comits.
The rule here is avoid updating .git/shallow by default. But we don't
want to waste the received pack. If the pack contains two refs, one
needs new shallow commits installed in .git/shallow and one does not,
we keep the latter and reject/warn about the former.
Even if .git/shallow update is allowed, we only add shallow commits
strictly necessary for the former ref (remember the sender can send
more shallow commits than necessary) and pay attention not to
accidentally cut the receiver history short (no history shortening is
asked for)
So the steps to figure out what ref need what new shallow commits are:
1. Split the sender shallow commit list into "ours" and "theirs" list
by has_sha1_file. Those that exist in current repo in "ours", the
remaining in "theirs".
2. Check the receiver .git/shallow, remove from "ours" the ones that
also exist in .git/shallow.
3. Fetch the new pack. Either install or unpack it.
4. Do has_sha1_file on "theirs" list again. Drop the ones that fail
has_sha1_file. Obviously the new pack does not need them.
5. If the pack is kept, remove from "ours" the ones that do not exist
in the new pack.
6. Walk the new refs to answer the question "what shallow commits,
both ours and theirs, are required in .git/shallow in order to add
this ref?". Shallow commits not associated to any refs are removed
from their respective list.
7. (*) Check reachability (from the current refs) of all remaining
commits in "ours". Those reachable are removed. We do not want to
cut any part of our (reachable) history. We only check up
commits. True reachability test is done by
check_everything_connected() at the end as usual.
8. Combine the final "ours" and "theirs" and add them all to
.git/shallow. Install new refs. The case where some hook rejects
some refs on a push is explained in more detail in the push
patches.
Of these steps, #6 and #7 are expensive. Both require walking through
some commits, or in the worst case all commits. And we rather avoid
them in at least common case, where the transferred pack does not
contain any shallow commits that the sender advertises. Let's look at
each scenario:
1) the sender has longer history than the receiver
All shallow commits from the sender will be put into "theirs" list
at step 1 because none of them exists in current repo. In the
common case, "theirs" becomes empty at step 4 and exit early.
2) the sender has shorter history than the receiver
All shallow commits from the sender are likely in "ours" list at
step 1. In the common case, if the new pack is kept, we could empty
"ours" and exit early at step 5.
If the pack is not kept, we hit the expensive step 6 then exit
after "ours" is emptied. There'll be only a handful of objects to
walk in fast-forward case. If it's forced update, we may need to
walk to the bottom.
3) the sender has same .git/shallow as the receiver
This is similar to case 2 except that "ours" should be emptied at
step 2 and exit early.
A fetch after "clone --depth=X" is case 1. A fetch after "clone" (from
a shallow repo) is case 3. Luckily they're cheap for the common case.
A push from "clone --depth=X" falls into case 2, which is expensive.
Some more work may be done at the sender/client side to avoid more
work on the server side: if the transferred pack does not contain any
shallow commits, send-pack should not send any shallow commits to the
receive-pack, effectively turning it into a normal push and avoid all
steps.
This patch implements all steps except #3, already handled by
fetch-pack and receive-pack, #6 and #7, which has their own patch due
to their size.
(*) in previous versions step 7 was put before step 3. I reorder it so
that the common case that keeps the pack does not need to walk
commits at all. In future if we implement faster commit
reachability check (maybe with the help of pack bitmaps or commit
cache), step 7 could become cheap and be moved up before 6 again.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05 14:02:35 +01:00
|
|
|
struct ref;
|
2006-10-30 20:09:06 +01:00
|
|
|
extern int register_shallow(const unsigned char *sha1);
|
2006-10-30 20:09:53 +01:00
|
|
|
extern int unregister_shallow(const unsigned char *sha1);
|
2011-08-18 14:29:35 +02:00
|
|
|
extern int for_each_commit_graft(each_commit_graft_fn, void *);
|
2007-01-22 07:22:23 +01:00
|
|
|
extern int is_repository_shallow(void);
|
2006-10-30 20:09:06 +01:00
|
|
|
extern struct commit_list *get_shallow_commits(struct object_array *heads,
|
2006-10-30 20:09:53 +01:00
|
|
|
int depth, int shallow_flag, int not_shallow_flag);
|
shallow.c: implement a generic shallow boundary finder based on rev-list
Instead of a custom commit walker like get_shallow_commits(), this new
function uses rev-list to mark NOT_SHALLOW to all reachable commits,
except borders. The definition of reachable is to be defined by the
protocol later. This makes it more flexible to define shallow boundary.
The way we find border is paint all reachable commits NOT_SHALLOW. Any
of them that "touches" commits without NOT_SHALLOW flag are considered
shallow (e.g. zero parents via grafting mechanism). Shallow commits and
their true parents are all marked SHALLOW. Then NOT_SHALLOW is removed
from shallow commits at the end.
There is an interesting observation. With a generic walker, we can
produce all kinds of shallow cutting. In the following graph, every
commit but "x" is reachable. "b" is a parent of "a".
x -- a -- o
/ /
x -- c -- b -- o
After this function is run, "a" and "c" are both considered shallow
commits. After grafting occurs at the client side, what we see is
a -- o
/
c -- b -- o
Notice that because of grafting, "a" has zero parents, so "b" is no
longer a parent of "a".
This is unfortunate and may be solved in two ways. The first is change
the way shallow grafting works and keep "a -- b" connection if "b"
exists and always ends at shallow commits (iow, no loose ends). This is
hard to detect, or at least not cheap to do.
The second way is mark one "x" as shallow commit instead of "a" and
produce this graph at client side:
x -- a -- o
/ /
c -- b -- o
More commits, but simpler grafting rules.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-12 12:53:57 +02:00
|
|
|
extern struct commit_list *get_shallow_commits_by_rev_list(
|
|
|
|
|
int ac, const char **av, int shallow_flag, int not_shallow_flag);
|
2013-12-05 14:02:45 +01:00
|
|
|
extern void set_alternate_shallow_file(const char *path, int override);
|
2013-12-05 14:02:34 +01:00
|
|
|
extern int write_shallow_commits(struct strbuf *out, int use_pack_protocol,
|
2017-03-31 03:40:00 +02:00
|
|
|
const struct oid_array *extra);
|
2013-08-16 11:52:02 +02:00
|
|
|
extern void setup_alternate_shallow(struct lock_file *shallow_lock,
|
2013-12-05 14:02:34 +01:00
|
|
|
const char **alternate_shallow_file,
|
2017-03-31 03:40:00 +02:00
|
|
|
const struct oid_array *extra);
|
|
|
|
|
extern const char *setup_temporary_shallow(const struct oid_array *extra);
|
2013-12-05 14:02:32 +01:00
|
|
|
extern void advertise_shallow_grafts(int);
|
2006-10-30 20:09:06 +01:00
|
|
|
|
shallow.c: the 8 steps to select new commits for .git/shallow
Suppose a fetch or push is requested between two shallow repositories
(with no history deepening or shortening). A pack that contains
necessary objects is transferred over together with .git/shallow of
the sender. The receiver has to determine whether it needs to update
.git/shallow if new refs needs new shallow comits.
The rule here is avoid updating .git/shallow by default. But we don't
want to waste the received pack. If the pack contains two refs, one
needs new shallow commits installed in .git/shallow and one does not,
we keep the latter and reject/warn about the former.
Even if .git/shallow update is allowed, we only add shallow commits
strictly necessary for the former ref (remember the sender can send
more shallow commits than necessary) and pay attention not to
accidentally cut the receiver history short (no history shortening is
asked for)
So the steps to figure out what ref need what new shallow commits are:
1. Split the sender shallow commit list into "ours" and "theirs" list
by has_sha1_file. Those that exist in current repo in "ours", the
remaining in "theirs".
2. Check the receiver .git/shallow, remove from "ours" the ones that
also exist in .git/shallow.
3. Fetch the new pack. Either install or unpack it.
4. Do has_sha1_file on "theirs" list again. Drop the ones that fail
has_sha1_file. Obviously the new pack does not need them.
5. If the pack is kept, remove from "ours" the ones that do not exist
in the new pack.
6. Walk the new refs to answer the question "what shallow commits,
both ours and theirs, are required in .git/shallow in order to add
this ref?". Shallow commits not associated to any refs are removed
from their respective list.
7. (*) Check reachability (from the current refs) of all remaining
commits in "ours". Those reachable are removed. We do not want to
cut any part of our (reachable) history. We only check up
commits. True reachability test is done by
check_everything_connected() at the end as usual.
8. Combine the final "ours" and "theirs" and add them all to
.git/shallow. Install new refs. The case where some hook rejects
some refs on a push is explained in more detail in the push
patches.
Of these steps, #6 and #7 are expensive. Both require walking through
some commits, or in the worst case all commits. And we rather avoid
them in at least common case, where the transferred pack does not
contain any shallow commits that the sender advertises. Let's look at
each scenario:
1) the sender has longer history than the receiver
All shallow commits from the sender will be put into "theirs" list
at step 1 because none of them exists in current repo. In the
common case, "theirs" becomes empty at step 4 and exit early.
2) the sender has shorter history than the receiver
All shallow commits from the sender are likely in "ours" list at
step 1. In the common case, if the new pack is kept, we could empty
"ours" and exit early at step 5.
If the pack is not kept, we hit the expensive step 6 then exit
after "ours" is emptied. There'll be only a handful of objects to
walk in fast-forward case. If it's forced update, we may need to
walk to the bottom.
3) the sender has same .git/shallow as the receiver
This is similar to case 2 except that "ours" should be emptied at
step 2 and exit early.
A fetch after "clone --depth=X" is case 1. A fetch after "clone" (from
a shallow repo) is case 3. Luckily they're cheap for the common case.
A push from "clone --depth=X" falls into case 2, which is expensive.
Some more work may be done at the sender/client side to avoid more
work on the server side: if the transferred pack does not contain any
shallow commits, send-pack should not send any shallow commits to the
receive-pack, effectively turning it into a normal push and avoid all
steps.
This patch implements all steps except #3, already handled by
fetch-pack and receive-pack, #6 and #7, which has their own patch due
to their size.
(*) in previous versions step 7 was put before step 3. I reorder it so
that the common case that keeps the pack does not need to walk
commits at all. In future if we implement faster commit
reachability check (maybe with the help of pack bitmaps or commit
cache), step 7 could become cheap and be moved up before 6 again.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05 14:02:35 +01:00
|
|
|
struct shallow_info {
|
2017-03-31 03:40:00 +02:00
|
|
|
struct oid_array *shallow;
|
shallow.c: the 8 steps to select new commits for .git/shallow
Suppose a fetch or push is requested between two shallow repositories
(with no history deepening or shortening). A pack that contains
necessary objects is transferred over together with .git/shallow of
the sender. The receiver has to determine whether it needs to update
.git/shallow if new refs needs new shallow comits.
The rule here is avoid updating .git/shallow by default. But we don't
want to waste the received pack. If the pack contains two refs, one
needs new shallow commits installed in .git/shallow and one does not,
we keep the latter and reject/warn about the former.
Even if .git/shallow update is allowed, we only add shallow commits
strictly necessary for the former ref (remember the sender can send
more shallow commits than necessary) and pay attention not to
accidentally cut the receiver history short (no history shortening is
asked for)
So the steps to figure out what ref need what new shallow commits are:
1. Split the sender shallow commit list into "ours" and "theirs" list
by has_sha1_file. Those that exist in current repo in "ours", the
remaining in "theirs".
2. Check the receiver .git/shallow, remove from "ours" the ones that
also exist in .git/shallow.
3. Fetch the new pack. Either install or unpack it.
4. Do has_sha1_file on "theirs" list again. Drop the ones that fail
has_sha1_file. Obviously the new pack does not need them.
5. If the pack is kept, remove from "ours" the ones that do not exist
in the new pack.
6. Walk the new refs to answer the question "what shallow commits,
both ours and theirs, are required in .git/shallow in order to add
this ref?". Shallow commits not associated to any refs are removed
from their respective list.
7. (*) Check reachability (from the current refs) of all remaining
commits in "ours". Those reachable are removed. We do not want to
cut any part of our (reachable) history. We only check up
commits. True reachability test is done by
check_everything_connected() at the end as usual.
8. Combine the final "ours" and "theirs" and add them all to
.git/shallow. Install new refs. The case where some hook rejects
some refs on a push is explained in more detail in the push
patches.
Of these steps, #6 and #7 are expensive. Both require walking through
some commits, or in the worst case all commits. And we rather avoid
them in at least common case, where the transferred pack does not
contain any shallow commits that the sender advertises. Let's look at
each scenario:
1) the sender has longer history than the receiver
All shallow commits from the sender will be put into "theirs" list
at step 1 because none of them exists in current repo. In the
common case, "theirs" becomes empty at step 4 and exit early.
2) the sender has shorter history than the receiver
All shallow commits from the sender are likely in "ours" list at
step 1. In the common case, if the new pack is kept, we could empty
"ours" and exit early at step 5.
If the pack is not kept, we hit the expensive step 6 then exit
after "ours" is emptied. There'll be only a handful of objects to
walk in fast-forward case. If it's forced update, we may need to
walk to the bottom.
3) the sender has same .git/shallow as the receiver
This is similar to case 2 except that "ours" should be emptied at
step 2 and exit early.
A fetch after "clone --depth=X" is case 1. A fetch after "clone" (from
a shallow repo) is case 3. Luckily they're cheap for the common case.
A push from "clone --depth=X" falls into case 2, which is expensive.
Some more work may be done at the sender/client side to avoid more
work on the server side: if the transferred pack does not contain any
shallow commits, send-pack should not send any shallow commits to the
receive-pack, effectively turning it into a normal push and avoid all
steps.
This patch implements all steps except #3, already handled by
fetch-pack and receive-pack, #6 and #7, which has their own patch due
to their size.
(*) in previous versions step 7 was put before step 3. I reorder it so
that the common case that keeps the pack does not need to walk
commits at all. In future if we implement faster commit
reachability check (maybe with the help of pack bitmaps or commit
cache), step 7 could become cheap and be moved up before 6 again.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05 14:02:35 +01:00
|
|
|
int *ours, nr_ours;
|
|
|
|
|
int *theirs, nr_theirs;
|
2017-03-31 03:40:00 +02:00
|
|
|
struct oid_array *ref;
|
2013-12-05 14:02:47 +01:00
|
|
|
|
|
|
|
|
/* for receive-pack */
|
|
|
|
|
uint32_t **used_shallow;
|
|
|
|
|
int *need_reachability_test;
|
|
|
|
|
int *reachable;
|
|
|
|
|
int *shallow_ref;
|
|
|
|
|
struct commit **commits;
|
|
|
|
|
int nr_commits;
|
shallow.c: the 8 steps to select new commits for .git/shallow
Suppose a fetch or push is requested between two shallow repositories
(with no history deepening or shortening). A pack that contains
necessary objects is transferred over together with .git/shallow of
the sender. The receiver has to determine whether it needs to update
.git/shallow if new refs needs new shallow comits.
The rule here is avoid updating .git/shallow by default. But we don't
want to waste the received pack. If the pack contains two refs, one
needs new shallow commits installed in .git/shallow and one does not,
we keep the latter and reject/warn about the former.
Even if .git/shallow update is allowed, we only add shallow commits
strictly necessary for the former ref (remember the sender can send
more shallow commits than necessary) and pay attention not to
accidentally cut the receiver history short (no history shortening is
asked for)
So the steps to figure out what ref need what new shallow commits are:
1. Split the sender shallow commit list into "ours" and "theirs" list
by has_sha1_file. Those that exist in current repo in "ours", the
remaining in "theirs".
2. Check the receiver .git/shallow, remove from "ours" the ones that
also exist in .git/shallow.
3. Fetch the new pack. Either install or unpack it.
4. Do has_sha1_file on "theirs" list again. Drop the ones that fail
has_sha1_file. Obviously the new pack does not need them.
5. If the pack is kept, remove from "ours" the ones that do not exist
in the new pack.
6. Walk the new refs to answer the question "what shallow commits,
both ours and theirs, are required in .git/shallow in order to add
this ref?". Shallow commits not associated to any refs are removed
from their respective list.
7. (*) Check reachability (from the current refs) of all remaining
commits in "ours". Those reachable are removed. We do not want to
cut any part of our (reachable) history. We only check up
commits. True reachability test is done by
check_everything_connected() at the end as usual.
8. Combine the final "ours" and "theirs" and add them all to
.git/shallow. Install new refs. The case where some hook rejects
some refs on a push is explained in more detail in the push
patches.
Of these steps, #6 and #7 are expensive. Both require walking through
some commits, or in the worst case all commits. And we rather avoid
them in at least common case, where the transferred pack does not
contain any shallow commits that the sender advertises. Let's look at
each scenario:
1) the sender has longer history than the receiver
All shallow commits from the sender will be put into "theirs" list
at step 1 because none of them exists in current repo. In the
common case, "theirs" becomes empty at step 4 and exit early.
2) the sender has shorter history than the receiver
All shallow commits from the sender are likely in "ours" list at
step 1. In the common case, if the new pack is kept, we could empty
"ours" and exit early at step 5.
If the pack is not kept, we hit the expensive step 6 then exit
after "ours" is emptied. There'll be only a handful of objects to
walk in fast-forward case. If it's forced update, we may need to
walk to the bottom.
3) the sender has same .git/shallow as the receiver
This is similar to case 2 except that "ours" should be emptied at
step 2 and exit early.
A fetch after "clone --depth=X" is case 1. A fetch after "clone" (from
a shallow repo) is case 3. Luckily they're cheap for the common case.
A push from "clone --depth=X" falls into case 2, which is expensive.
Some more work may be done at the sender/client side to avoid more
work on the server side: if the transferred pack does not contain any
shallow commits, send-pack should not send any shallow commits to the
receive-pack, effectively turning it into a normal push and avoid all
steps.
This patch implements all steps except #3, already handled by
fetch-pack and receive-pack, #6 and #7, which has their own patch due
to their size.
(*) in previous versions step 7 was put before step 3. I reorder it so
that the common case that keeps the pack does not need to walk
commits at all. In future if we implement faster commit
reachability check (maybe with the help of pack bitmaps or commit
cache), step 7 could become cheap and be moved up before 6 again.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05 14:02:35 +01:00
|
|
|
};
|
|
|
|
|
|
2017-03-31 03:40:00 +02:00
|
|
|
extern void prepare_shallow_info(struct shallow_info *, struct oid_array *);
|
shallow.c: the 8 steps to select new commits for .git/shallow
Suppose a fetch or push is requested between two shallow repositories
(with no history deepening or shortening). A pack that contains
necessary objects is transferred over together with .git/shallow of
the sender. The receiver has to determine whether it needs to update
.git/shallow if new refs needs new shallow comits.
The rule here is avoid updating .git/shallow by default. But we don't
want to waste the received pack. If the pack contains two refs, one
needs new shallow commits installed in .git/shallow and one does not,
we keep the latter and reject/warn about the former.
Even if .git/shallow update is allowed, we only add shallow commits
strictly necessary for the former ref (remember the sender can send
more shallow commits than necessary) and pay attention not to
accidentally cut the receiver history short (no history shortening is
asked for)
So the steps to figure out what ref need what new shallow commits are:
1. Split the sender shallow commit list into "ours" and "theirs" list
by has_sha1_file. Those that exist in current repo in "ours", the
remaining in "theirs".
2. Check the receiver .git/shallow, remove from "ours" the ones that
also exist in .git/shallow.
3. Fetch the new pack. Either install or unpack it.
4. Do has_sha1_file on "theirs" list again. Drop the ones that fail
has_sha1_file. Obviously the new pack does not need them.
5. If the pack is kept, remove from "ours" the ones that do not exist
in the new pack.
6. Walk the new refs to answer the question "what shallow commits,
both ours and theirs, are required in .git/shallow in order to add
this ref?". Shallow commits not associated to any refs are removed
from their respective list.
7. (*) Check reachability (from the current refs) of all remaining
commits in "ours". Those reachable are removed. We do not want to
cut any part of our (reachable) history. We only check up
commits. True reachability test is done by
check_everything_connected() at the end as usual.
8. Combine the final "ours" and "theirs" and add them all to
.git/shallow. Install new refs. The case where some hook rejects
some refs on a push is explained in more detail in the push
patches.
Of these steps, #6 and #7 are expensive. Both require walking through
some commits, or in the worst case all commits. And we rather avoid
them in at least common case, where the transferred pack does not
contain any shallow commits that the sender advertises. Let's look at
each scenario:
1) the sender has longer history than the receiver
All shallow commits from the sender will be put into "theirs" list
at step 1 because none of them exists in current repo. In the
common case, "theirs" becomes empty at step 4 and exit early.
2) the sender has shorter history than the receiver
All shallow commits from the sender are likely in "ours" list at
step 1. In the common case, if the new pack is kept, we could empty
"ours" and exit early at step 5.
If the pack is not kept, we hit the expensive step 6 then exit
after "ours" is emptied. There'll be only a handful of objects to
walk in fast-forward case. If it's forced update, we may need to
walk to the bottom.
3) the sender has same .git/shallow as the receiver
This is similar to case 2 except that "ours" should be emptied at
step 2 and exit early.
A fetch after "clone --depth=X" is case 1. A fetch after "clone" (from
a shallow repo) is case 3. Luckily they're cheap for the common case.
A push from "clone --depth=X" falls into case 2, which is expensive.
Some more work may be done at the sender/client side to avoid more
work on the server side: if the transferred pack does not contain any
shallow commits, send-pack should not send any shallow commits to the
receive-pack, effectively turning it into a normal push and avoid all
steps.
This patch implements all steps except #3, already handled by
fetch-pack and receive-pack, #6 and #7, which has their own patch due
to their size.
(*) in previous versions step 7 was put before step 3. I reorder it so
that the common case that keeps the pack does not need to walk
commits at all. In future if we implement faster commit
reachability check (maybe with the help of pack bitmaps or commit
cache), step 7 could become cheap and be moved up before 6 again.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05 14:02:35 +01:00
|
|
|
extern void clear_shallow_info(struct shallow_info *);
|
|
|
|
|
extern void remove_nonexistent_theirs_shallow(struct shallow_info *);
|
2013-12-05 14:02:36 +01:00
|
|
|
extern void assign_shallow_commits_to_refs(struct shallow_info *info,
|
|
|
|
|
uint32_t **used,
|
|
|
|
|
int *ref_status);
|
2013-12-05 14:02:47 +01:00
|
|
|
extern int delayed_reachability_test(struct shallow_info *si, int c);
|
2013-12-05 14:02:54 +01:00
|
|
|
extern void prune_shallow(int show_only);
|
2014-07-12 02:00:06 +02:00
|
|
|
extern struct trace_key trace_shallow;
|
2006-10-30 20:09:06 +01:00
|
|
|
|
2009-01-26 15:13:24 +01:00
|
|
|
int is_descendant_of(struct commit *, struct commit_list *);
|
2012-08-27 23:46:01 +02:00
|
|
|
int in_merge_bases(struct commit *, struct commit *);
|
2013-03-04 19:16:42 +01:00
|
|
|
int in_merge_bases_many(struct commit *, int, struct commit **);
|
2007-09-18 02:06:44 +02:00
|
|
|
|
2011-05-07 19:58:07 +02:00
|
|
|
extern int interactive_add(int argc, const char **argv, const char *prefix, int patch);
|
2009-08-13 14:29:41 +02:00
|
|
|
extern int run_add_interactive(const char *revision, const char *patch_mode,
|
2013-07-14 10:35:50 +02:00
|
|
|
const struct pathspec *pathspec);
|
2007-09-18 02:06:44 +02:00
|
|
|
|
2007-11-05 22:22:34 +01:00
|
|
|
static inline int single_parent(struct commit *commit)
|
|
|
|
|
{
|
|
|
|
|
return commit->parents && !commit->parents->next;
|
|
|
|
|
}
|
|
|
|
|
|
2008-06-27 18:22:03 +02:00
|
|
|
struct commit_list *reduce_heads(struct commit_list *heads);
|
|
|
|
|
|
2011-11-08 01:21:32 +01:00
|
|
|
struct commit_extra_header {
|
|
|
|
|
struct commit_extra_header *next;
|
|
|
|
|
char *key;
|
|
|
|
|
char *value;
|
|
|
|
|
size_t len;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
extern void append_merge_tag_headers(struct commit_list *parents,
|
|
|
|
|
struct commit_extra_header ***tail);
|
|
|
|
|
|
2014-06-10 23:36:52 +02:00
|
|
|
extern int commit_tree(const char *msg, size_t msg_len,
|
|
|
|
|
const unsigned char *tree,
|
2011-11-08 01:21:32 +01:00
|
|
|
struct commit_list *parents, unsigned char *ret,
|
commit: teach --gpg-sign option
This uses the gpg-interface.[ch] to allow signing the commit, i.e.
$ git commit --gpg-sign -m foo
You need a passphrase to unlock the secret key for
user: "Junio C Hamano <gitster@pobox.com>"
4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
[master 8457d13] foo
1 files changed, 1 insertions(+), 0 deletions(-)
The lines of GPG detached signature are placed in a new multi-line header
field, instead of tucking the signature block at the end of the commit log
message text (similar to how signed tag is done), for multiple reasons:
- The signature won't clutter output from "git log" and friends if it is
in the extra header. If we place it at the end of the log message, we
would need to teach "git log" and friends to strip the signature block
with an option.
- Teaching new versions of "git log" and "gitk" to optionally verify and
show signatures is cleaner if we structurally know where the signature
block is (instead of scanning in the commit log message).
- The signature needs to be stripped upon various commit rewriting
operations, e.g. rebase, filter-branch, etc. They all already ignore
unknown headers, but if we place signature in the log message, all of
these tools (and third-party tools) also need to learn how a signature
block would look like.
- When we added the optional encoding header, all the tools (both in tree
and third-party) that acts on the raw commit object should have been
fixed to ignore headers they do not understand, so it is not like that
new header would be more likely to break than extra text in the commit.
A commit made with the above sample sequence would look like this:
$ git cat-file commit HEAD
tree 3cd71d90e3db4136e5260ab54599791c4f883b9d
parent b87755351a47b09cb27d6913e6e0e17e6254a4d4
author Junio C Hamano <gitster@pobox.com> 1317862251 -0700
committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG
...
=dt98
-----END PGP SIGNATURE-----
foo
but "git log" (unless you ask for it with --pretty=raw) output is not
cluttered with the signature information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 02:23:20 +02:00
|
|
|
const char *author, const char *sign_commit);
|
2011-11-08 01:21:32 +01:00
|
|
|
|
2014-06-10 23:36:52 +02:00
|
|
|
extern int commit_tree_extended(const char *msg, size_t msg_len,
|
|
|
|
|
const unsigned char *tree,
|
2011-11-08 01:21:32 +01:00
|
|
|
struct commit_list *parents, unsigned char *ret,
|
commit: teach --gpg-sign option
This uses the gpg-interface.[ch] to allow signing the commit, i.e.
$ git commit --gpg-sign -m foo
You need a passphrase to unlock the secret key for
user: "Junio C Hamano <gitster@pobox.com>"
4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
[master 8457d13] foo
1 files changed, 1 insertions(+), 0 deletions(-)
The lines of GPG detached signature are placed in a new multi-line header
field, instead of tucking the signature block at the end of the commit log
message text (similar to how signed tag is done), for multiple reasons:
- The signature won't clutter output from "git log" and friends if it is
in the extra header. If we place it at the end of the log message, we
would need to teach "git log" and friends to strip the signature block
with an option.
- Teaching new versions of "git log" and "gitk" to optionally verify and
show signatures is cleaner if we structurally know where the signature
block is (instead of scanning in the commit log message).
- The signature needs to be stripped upon various commit rewriting
operations, e.g. rebase, filter-branch, etc. They all already ignore
unknown headers, but if we place signature in the log message, all of
these tools (and third-party tools) also need to learn how a signature
block would look like.
- When we added the optional encoding header, all the tools (both in tree
and third-party) that acts on the raw commit object should have been
fixed to ignore headers they do not understand, so it is not like that
new header would be more likely to break than extra text in the commit.
A commit made with the above sample sequence would look like this:
$ git cat-file commit HEAD
tree 3cd71d90e3db4136e5260ab54599791c4f883b9d
parent b87755351a47b09cb27d6913e6e0e17e6254a4d4
author Junio C Hamano <gitster@pobox.com> 1317862251 -0700
committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG
...
=dt98
-----END PGP SIGNATURE-----
foo
but "git log" (unless you ask for it with --pretty=raw) output is not
cluttered with the signature information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 02:23:20 +02:00
|
|
|
const char *author, const char *sign_commit,
|
2011-11-08 01:21:32 +01:00
|
|
|
struct commit_extra_header *);
|
|
|
|
|
|
2012-01-05 19:54:14 +01:00
|
|
|
extern struct commit_extra_header *read_commit_extra_headers(struct commit *, const char **);
|
2011-11-09 00:38:07 +01:00
|
|
|
|
2011-11-08 01:21:32 +01:00
|
|
|
extern void free_commit_extra_headers(struct commit_extra_header *extra);
|
make commit_tree a library function
Until now, this has been part of the commit-tree builtin.
However, it is already used by other builtins (like commit,
merge, and notes), and it would be useful to access it from
library code.
The check_valid helper has to come along, too, but is given
a more library-ish name of "assert_sha1_type".
Otherwise, the code is unchanged. There are still a few
rough edges for a library function, like printing the utf8
warning to stderr, but we can address those if and when they
come up as inappropriate.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-02 02:05:23 +02:00
|
|
|
|
commit: provide a function to find a header in a buffer
Usually when we parse a commit, we read it line by line and
handle each individual line (e.g., parse_commit and
parse_commit_header). Sometimes, however, we only care
about extracting a single header. Code in this situation is
stuck doing an ad-hoc parse of the commit buffer.
Let's provide a reusable function to locate a header within
the commit. The code is modeled after pretty.c's
get_header, which is used to extract the encoding.
Since some callers may not have the "struct commit" to go
along with the buffer, we drop that parameter. The only
thing lost is a warning for truncated commits, but that's
OK. This shouldn't happen in practice, and even if it does,
there's no particular reason that this function needs to
complain about it. It either finds the header it was asked
for, or it doesn't (and in the latter case, the caller will
typically complain).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-27 09:56:01 +02:00
|
|
|
/*
|
|
|
|
|
* Search the commit object contents given by "msg" for the header "key".
|
|
|
|
|
* Returns a pointer to the start of the header contents, or NULL. The length
|
|
|
|
|
* of the header, up to the first newline, is returned via out_len.
|
|
|
|
|
*
|
|
|
|
|
* Note that some headers (like mergetag) may be multi-line. It is the caller's
|
|
|
|
|
* responsibility to parse further in this case!
|
|
|
|
|
*/
|
|
|
|
|
extern const char *find_commit_header(const char *msg, const char *key,
|
|
|
|
|
size_t *out_len);
|
|
|
|
|
|
2014-11-09 10:23:41 +01:00
|
|
|
/* Find the end of the log message, the right place for a new trailer. */
|
2016-11-02 18:29:17 +01:00
|
|
|
extern int ignore_non_trailer(const char *buf, size_t len);
|
2014-11-09 10:23:41 +01:00
|
|
|
|
2014-07-07 08:35:37 +02:00
|
|
|
typedef void (*each_mergetag_fn)(struct commit *commit, struct commit_extra_header *extra,
|
|
|
|
|
void *cb_data);
|
|
|
|
|
|
|
|
|
|
extern void for_each_mergetag(each_mergetag_fn fn, struct commit *commit, void *data);
|
|
|
|
|
|
2011-11-07 22:26:22 +01:00
|
|
|
struct merge_remote_desc {
|
|
|
|
|
struct object *obj; /* the named object, could be a tag */
|
2016-08-13 14:21:27 +02:00
|
|
|
char name[FLEX_ARRAY];
|
2011-11-07 22:26:22 +01:00
|
|
|
};
|
|
|
|
|
#define merge_remote_util(commit) ((struct merge_remote_desc *)((commit)->util))
|
2016-08-13 14:11:27 +02:00
|
|
|
extern void set_merge_remote_desc(struct commit *commit,
|
|
|
|
|
const char *name, struct object *obj);
|
2011-11-07 22:26:22 +01:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Given "name" from the command line to merge, find the commit object
|
|
|
|
|
* and return it, while storing merge_remote_desc in its ->util field,
|
|
|
|
|
* to allow callers to tell if we are told to merge a tag.
|
|
|
|
|
*/
|
|
|
|
|
struct commit *get_merge_parent(const char *name);
|
|
|
|
|
|
reuse cached commit buffer when parsing signatures
When we call show_signature or show_mergetag, we read the
commit object fresh via read_sha1_file and reparse its
headers. However, in most cases we already have the object
data available, attached to the "struct commit". This is
partially laziness in dealing with the memory allocation
issues, but partially defensive programming, in that we
would always want to verify a clean version of the buffer
(not one that might have been munged by other users of the
commit).
However, we do not currently ever munge the commit buffer,
and not using the already-available buffer carries a fairly
big performance penalty when we are looking at a large
number of commits. Here are timings on linux.git:
[baseline, no signatures]
$ time git log >/dev/null
real 0m4.902s
user 0m4.784s
sys 0m0.120s
[before]
$ time git log --show-signature >/dev/null
real 0m14.735s
user 0m9.964s
sys 0m0.944s
[after]
$ time git log --show-signature >/dev/null
real 0m9.981s
user 0m5.260s
sys 0m0.936s
Note that our user CPU time drops almost in half, close to
the non-signature case, but we do still spend more
wall-clock and system time, presumably from dealing with
gpg.
An alternative to this is to note that most commits do not
have signatures (less than 1% in this repo), yet we pay the
re-parsing cost for every commit just to find out if it has
a mergetag or signature. If we checked that when parsing the
commit initially, we could avoid re-examining most commits
later on. Even if we did pursue that direction, however,
this would still speed up the cases where we _do_ have
signatures. So it's probably worth doing either way.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13 08:32:11 +02:00
|
|
|
extern int parse_signed_commit(const struct commit *commit,
|
2011-10-19 00:53:23 +02:00
|
|
|
struct strbuf *message, struct strbuf *signature);
|
2014-07-19 17:01:12 +02:00
|
|
|
extern int remove_signature(struct strbuf *buf);
|
|
|
|
|
|
2013-03-31 18:00:14 +02:00
|
|
|
/*
|
2013-03-31 18:02:46 +02:00
|
|
|
* Check the signature of the given commit. The result of the check is stored
|
|
|
|
|
* in sig->check_result, 'G' for a good signature, 'U' for a good signature
|
|
|
|
|
* from an untrusted signer, 'B' for a bad signature and 'N' for no signature
|
|
|
|
|
* at all. This may allocate memory for sig->gpg_output, sig->gpg_status,
|
|
|
|
|
* sig->signer and sig->key.
|
2013-03-31 18:00:14 +02:00
|
|
|
*/
|
2015-06-22 01:14:40 +02:00
|
|
|
extern int check_commit_signature(const struct commit *commit, struct signature_check *sigc);
|
2013-03-31 18:00:14 +02:00
|
|
|
|
2013-07-02 08:21:48 +02:00
|
|
|
int compare_commits_by_commit_date(const void *a_, const void *b_, void *unused);
|
|
|
|
|
|
2014-03-18 11:00:53 +01:00
|
|
|
LAST_ARG_MUST_BE_NULL
|
|
|
|
|
extern int run_commit_hook(int editor_is_used, const char *index_file, const char *name, ...);
|
|
|
|
|
|
2005-04-18 20:39:48 +02:00
|
|
|
#endif /* COMMIT_H */
|