[PATCH] Added get sendmail from .mailrc
Signed-off-by: Brilliantov Kirill Vladimirovich brillian...@inbox.ru
---
git-send-email.perl | 18 ++
1 file changed, 18 insertions(+)
diff --git a/git-send-email.perl b/git-send-email.perl
index 2016d9c..5345fdb 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -28,6 +28,7 @@ use File::Temp qw/ tempdir tempfile /;
use File::Spec::Functions qw(catfile);
use Error qw(:try);
use Git;
+use File::HomeDir;
Getopt::Long::Configure qw/ pass_through /;
@@ -804,6 +805,23 @@ if (!defined $smtp_server) {
last;
}
}
+
+ if (!defined $smtp_server) {
+ my $mailrc = File::HomeDir-my_home . /.mailrc;
+ if (-e $mailrc) {
+ open FILE, $mailrc or die Failed open $mailrc: $!;
+ while (FILE) {
+ chomp;
+ if (/set sendmail=.*/) {
+ my @data = split '';
+ $smtp_server = $data[1];
+ last;
+ }
+ }
+ close FILE;
+ }
+ }
+
$smtp_server ||= 'localhost'; # could be 127.0.0.1, too... *shrug*
}
--
1.8.5.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
How to substructure rewrites?
Hi, I'm currently rewriting the internals of git-blame. For the somewhat academic example #/bin/sh cd /tmp rm -rf testit mkdir testit cd testit git init for inc in 8 4 3 7 2 9 5 6 1 do seq 252000 -$inc 0 testfile git add testfile git commit -m Run with increment $inc done time git blame testfile /dev/null the performance of git-blame increases by 4000%. It turns out that in real-world bad cases, particularly after aggressively repacking repositories, the gains are quite more modest. I've seen a factor of 2 with source code and a factor of 3 with a large word list. The bulk of the remaining time is spent in system time (which has basically not changed by my work), so it is likely that the repository gets read over and over, calling for some better caching strategies. So the question is how to restructure the work. I want to put out a teaser soonish but I think that there is little point in substructuring the commits I have so far. They start with a few janitorial patches already in pu, but after that there is commit 7c610731e9452f3e8c175ab7e7542eafed1c5b93 Author: David Kastrup d...@gnu.org Date: Sat Jan 25 13:19:17 2014 +0100 wip commit dca4c8c447b94e1a3f8f45874d5415665d503189 Author: David Kastrup d...@gnu.org Date: Wed Jan 22 01:16:06 2014 +0100 wip commit f64b41c472442ae9971321fe8f62c3885ba4d8b7 Author: David Kastrup d...@gnu.org Date: Sun Jan 19 02:16:21 2014 +0100 blame.c: Let output determine MORE_THAN_ONE_PATH more efficiently commit 607b094537d6fe4a75cf9a297470966bda934c73 Author: David Kastrup d...@gnu.org Date: Mon Jan 13 18:06:06 2014 +0100 wip commit 1cd4e172533fb55793d02147c9596c59f7b05343 Author: David Kastrup d...@gnu.org Date: Sun Jan 19 01:30:02 2014 +0100 Reorganize blame data structures commit 5ab2add67d5fcf3837623a7bc028bcaec1006cc4 Author: David Kastrup d...@gnu.org Date: Sun Jan 19 01:29:28 2014 +0100 Add blame_sort function for sorting a blame list commit d3745752968617979878962ead957a6b5f829f0b Author: David Kastrup d...@gnu.org Date: Sun Jan 19 01:28:22 2014 +0100 Add merge_blame function for merging two sorted blame lists. As it can easily be guessed, the add xxx function commits are basically adding not-yet-used code (and so will not disrupt compilation), but everything starting with Reorganize blame data structures up until the final commit will not work or compile since the code does not match the data structures. So there is little point in substructing all that, right? Even something seemingly isolated like commit f64b41c472442ae9971321fe8f62c3885ba4d8b7 Author: David Kastrup d...@gnu.org Date: Sun Jan 19 02:16:21 2014 +0100 blame.c: Let output determine MORE_THAN_ONE_PATH more efficiently is not really useful as a separate commit since while it does implement a particular task, this is done starting with non-working code relying on no-longer existent data structures. I'm seriously considering squashing all that in a single commit. It seems like it would be utterly pointless to introduce artificially working in-between states that simulate a partial migration to new data structures that never happened. Where the algorithmic setup happened, I rewrite from scratch, and it's pretty absurd to match and marry efficient and inefficient half-algorithms. Which brings us to point two: the teaser part. The current stuff has #if 0/#endif around the old implementation of the expensive -M and -C options. They are currently not operative due to the mismatch to data structures. Obviously, that makes the change unsuitable for putting into master or anywhere close. I'd still want to solicit feedback: when not using those options (which will likely cause me another week of headaches), the code is working well and delivering identical information. So should I just squash the stuff and leave just the commits that made it into pu separate (so that people may git-am whether or not they already have those commits)? In general, the rule is likely any commit should not create a non-working state right? -- David Kastrup
[PATCH] Makefile: remove redundant object in git-http{fetch,push}
revision.o is included in libgit.a which is in $(GITLIBS), so we don't need to include is separately. This fixes compilation with -fwhole-program which otherwise fails with messages like this: libgit.a(revision.o): In function `mark_tree_uninteresting': /home/john/src/git/revision.c:108: multiple definition of `mark_tree_uninteresting' /tmp/ccKQRkZV.ltrans2.ltrans.o:/home/john/src/git/revision.c:108: first defined here Signed-off-by: John Keeping j...@keeping.me.uk --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index b4af1e2..b3a408d 100644 --- a/Makefile +++ b/Makefile @@ -2050,10 +2050,10 @@ git-imap-send$X: imap-send.o GIT-LDFLAGS $(GITLIBS) $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \ $(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO) -git-http-fetch$X: revision.o http.o http-walker.o http-fetch.o GIT-LDFLAGS $(GITLIBS) +git-http-fetch$X: http.o http-walker.o http-fetch.o GIT-LDFLAGS $(GITLIBS) $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \ $(LIBS) $(CURL_LIBCURL) -git-http-push$X: revision.o http.o http-push.o GIT-LDFLAGS $(GITLIBS) +git-http-push$X: http.o http-push.o GIT-LDFLAGS $(GITLIBS) $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \ $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT) -- 1.9.rc0.187.g6292fff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Globbing for ignored branches?
On 2014.01.24 at 20:34 -0500, Jeff King wrote: On Fri, Jan 24, 2014 at 01:08:42PM -0800, Junio C Hamano wrote: Not really. You do not have to view it as 'not refs/heads/foo' is affecting the previous '+refs/heads/*:refs/remotes/origin/*'. You can think of two refspecs refs/heads/foo refs/heads/bar are both affecting the end result; so far we only had a single way for multiple refspecs to affect the end result and that was a union. Introducing subtract as another mode of combining is not too bad, I would think, at the conceptual level. I tend to agree that refs/heads/foo: is being too cute and may be confusing, at least if it will be the only way to express this in the end-user-facing UI. Even some people were confused enough on a very sensible push nothing to ref means deletion to make us add another explicit way, push --delete, to ask for the same thing. Agreed. I went with ^refs/heads/master in the patch below, but I am open to other suggestions. Many thanks for the patch. It seems to work as advertised, but only if the negative refspec appears on a separate line. For example: [remote origin] url = git://gcc.gnu.org/git/gcc.git fetch = +refs/heads/*:refs/remotes/origin/* fetch = ^refs/remotes/hjl works fine, but: [remote origin] url = git://gcc.gnu.org/git/gcc.git fetch = +refs/heads/*:refs/remotes/origin/* ^refs/remotes/hjl doesn't. (I think this happens because bad_ref_char in refs.c checks for '^'.) -- Markus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Globbing for ignored branches?
On 2014.01.25 at 15:15 +0100, Markus Trippelsdorf wrote: On 2014.01.24 at 20:34 -0500, Jeff King wrote: On Fri, Jan 24, 2014 at 01:08:42PM -0800, Junio C Hamano wrote: Not really. You do not have to view it as 'not refs/heads/foo' is affecting the previous '+refs/heads/*:refs/remotes/origin/*'. You can think of two refspecs refs/heads/foo refs/heads/bar are both affecting the end result; so far we only had a single way for multiple refspecs to affect the end result and that was a union. Introducing subtract as another mode of combining is not too bad, I would think, at the conceptual level. I tend to agree that refs/heads/foo: is being too cute and may be confusing, at least if it will be the only way to express this in the end-user-facing UI. Even some people were confused enough on a very sensible push nothing to ref means deletion to make us add another explicit way, push --delete, to ask for the same thing. Agreed. I went with ^refs/heads/master in the patch below, but I am open to other suggestions. Many thanks for the patch. It seems to work as advertised, but only if the negative refspec appears on a separate line. For example: I've posted a wrong negative refspec. Sorry. Correction below. [remote origin] url = git://gcc.gnu.org/git/gcc.git fetch = +refs/heads/*:refs/remotes/origin/* fetch = ^refs/remotes/hjl fetch = ^refs/remotes/origin/hjl works fine, but: [remote origin] url = git://gcc.gnu.org/git/gcc.git fetch = +refs/heads/*:refs/remotes/origin/* ^refs/remotes/hjl fetch = +refs/heads/*:refs/remotes/origin/* ^refs/remotes/origin/hjl doesn't. (I think this happens because bad_ref_char in refs.c checks for '^'.) -- Markus -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] Eliminate same_suspect function in builtin/blame.c
Since the origin pointers are interned and reference-counted, comparing
the pointers rather than the content is enough. The only uninterned
origins are cached values kept in commit-util, but same_suspect is not
called on them.
Signed-off-by: David Kastrup d...@gnu.org
---
builtin/blame.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 2195595..ead6148 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -255,15 +255,6 @@ struct scoreboard {
int *lineno;
};
-static inline int same_suspect(struct origin *a, struct origin *b)
-{
- if (a == b)
- return 1;
- if (a-commit != b-commit)
- return 0;
- return !strcmp(a-path, b-path);
-}
-
static void sanity_check_refcnt(struct scoreboard *);
/*
@@ -276,7 +267,7 @@ static void coalesce(struct scoreboard *sb)
struct blame_entry *ent, *next;
for (ent = sb-ent; ent (next = ent-next); ent = next) {
- if (same_suspect(ent-suspect, next-suspect)
+ if (ent-suspect == next-suspect
ent-guilty == next-guilty
ent-s_lno + ent-num_lines == next-s_lno) {
ent-num_lines += next-num_lines;
@@ -735,7 +726,7 @@ static int find_last_in_target(struct scoreboard *sb,
struct origin *target)
int last_in_target = -1;
for (e = sb-ent; e; e = e-next) {
- if (e-guilty || !same_suspect(e-suspect, target))
+ if (e-guilty || e-suspect != target)
continue;
if (last_in_target e-s_lno + e-num_lines)
last_in_target = e-s_lno + e-num_lines;
@@ -755,7 +746,7 @@ static void blame_chunk(struct scoreboard *sb,
struct blame_entry *e;
for (e = sb-ent; e; e = e-next) {
- if (e-guilty || !same_suspect(e-suspect, target))
+ if (e-guilty || e-suspect != target)
continue;
if (same = e-s_lno)
continue;
@@ -985,7 +976,7 @@ static int find_move_in_parent(struct scoreboard *sb,
while (made_progress) {
made_progress = 0;
for (e = sb-ent; e; e = e-next) {
- if (e-guilty || !same_suspect(e-suspect, target) ||
+ if (e-guilty || e-suspect != target ||
ent_score(sb, e) blame_move_score)
continue;
find_copy_in_blob(sb, e, parent, split, file_p);
@@ -1020,14 +1011,14 @@ static struct blame_list *setup_blame_list(struct
scoreboard *sb,
for (e = sb-ent, num_ents = 0; e; e = e-next)
if (!e-scanned !e-guilty
- same_suspect(e-suspect, target)
+ e-suspect == target
min_score ent_score(sb, e))
num_ents++;
if (num_ents) {
blame_list = xcalloc(num_ents, sizeof(struct blame_list));
for (e = sb-ent, i = 0; e; e = e-next)
if (!e-scanned !e-guilty
- same_suspect(e-suspect, target)
+ e-suspect == target
min_score ent_score(sb, e))
blame_list[i++].ent = e;
}
@@ -1171,7 +1162,7 @@ static void pass_whole_blame(struct scoreboard *sb,
origin-file.ptr = NULL;
}
for (e = sb-ent; e; e = e-next) {
- if (!same_suspect(e-suspect, origin))
+ if (e-suspect != origin)
continue;
origin_incref(porigin);
origin_decref(e-suspect);
@@ -1560,7 +1551,7 @@ static void assign_blame(struct scoreboard *sb, int opt)
/* Take responsibility for the remaining entries */
for (ent = sb-ent; ent; ent = ent-next)
- if (same_suspect(ent-suspect, suspect))
+ if (ent-suspect == suspect)
found_guilty_entry(ent);
origin_decref(suspect);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] builtin/blame.c: large-scale rewrite
The previous implementation uses a sorted linear list of struct
blame_entry in a struct scoreboard for organizing all partial or
completed work. Every task that is done requires going through the
whole list where most entries are not relevant to the task at hand.
This commit reorganizes the data structures in order to have each
remaining subtask work with its own sorted linear list it can work off
front to back. Subtasks are organized into struct origin chains
hanging off particular commits. Commits are organized into a priority
queue, processing them in commit date order in order to keep most of
the work affecting a particular blob collated even in the presence of
an extensive merge history. In that manner, linear searches can be
basically avoided anywhere. They still are done for identifying one
of multiple analyzed files in a given commit, but the degenerate case
of a single large file being assembled from a multitude of smaller
files in the past is not likely to occur often enough to warrant
special treatment.
---
builtin/blame.c | 569
1 file changed, 367 insertions(+), 202 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index ead6148..994a9e8 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -18,7 +18,9 @@
#include cache-tree.h
#include string-list.h
#include mailmap.h
+#include mergesort.h
#include parse-options.h
+#include prio-queue.h
#include utf8.h
#include userdiff.h
#include line-range.h
@@ -83,11 +85,43 @@ static unsigned blame_copy_score;
*/
struct origin {
int refcnt;
+ /* Record preceding blame record for this blob */
struct origin *previous;
+ /* origins are put in a list linked via `next' hanging off the
+* corresponding commit's util field in order to make finding
+* them fast. The presence in this chain does not count
+* towards the origin's reference count. It is tempting to
+* let it count as long as the commit is pending examination,
+* but even under circumstances where the commit will be
+* present multiple times in the priority queue of unexamined
+* commits, processing the first instance will not leave any
+* work requiring the origin data for the second instance. An
+* interspersed commit changing that would have to be
+* preexisting with a different ancestry and with the same
+* commit date in order to wedge itself between two instances
+* of the same commit in the priority queue _and_ produce
+* blame entries relevant for it. While we don't want to let
+* us get tripped up by this case, it certainly does not seem
+* worth optimizing for.
+*/
+ struct origin *next;
struct commit *commit;
+ /* `suspects' contains blame entries that may be attributed to
+* this origin's commit or to parent commits. When a commit
+* is being processed, all suspects will be moved, either by
+* assigning them to an origin in a different commit, or by
+* shipping them to the scoreboard's ent list because they
+* cannot be attributed to a different commit.
+*/
+ struct blame_entry *suspects;
mmfile_t file;
unsigned char blob_sha1[20];
unsigned mode;
+ /* shipped gets set when shipping any suspects to the final
+* blame list instead of other commits
+*/
+ char shipped;
+ char guilty;
char path[FLEX_ARRAY];
};
@@ -176,10 +210,23 @@ static inline struct origin *origin_incref(struct origin
*o)
static void origin_decref(struct origin *o)
{
if (o --o-refcnt = 0) {
+ struct origin *p, *l = NULL;
if (o-previous)
origin_decref(o-previous);
free(o-file.ptr);
- free(o);
+ /* Should be present exactly once in commit chain */
+ for (p = o-commit-util; p; l = p, p = p-next) {
+ if (p == o)
+ {
+ if (l)
+ l-next = p-next;
+ else
+ o-commit-util = p-next;
+ free(o);
+ return;
+ }
+ }
+ die(internal error in blame::origin_decref);
}
}
@@ -193,8 +240,12 @@ static void drop_origin_blob(struct origin *o)
/*
* Each group of lines is described by a blame_entry; it can be split
- * as we pass blame to the parents. They form a linked list in the
- * scoreboard structure, sorted by the target line number.
+ * as we pass blame to the parents. They are arranged in linked lists
+ * kept as `suspects' of some unprocessed origin, or entered (when the
+ * blame origin has been finalized) into the scoreboard structure.
[PATCH 0/3] Teaser patch for rewriting blame for efficiency
Ok, here is the teaser for the git-blame rewrite. The first two patches are already in pu and only contained for simplicity. The third patch gives a pretty good idea about the work that's up. It is missing support for the -M and -C options (I think, if that's what the move and copy detection are supposed to be about). Part of preexisting code is #if 0/#endif removed since I don't know yet whether the implementation of copy/move will need some of that. Apart from these rather obvious problems, the question is whether it is ok to do the finished rewrite as a single commit since I cannot really envision useful intermediate stages. While there is not much of a point on commenting on the code (and its tentative changes) within #if 0/#endif, the code that is actually compiled is of course open to preliminary criticism. For obvious reasons, patch #3 is not signed off: it should never be committed in its current form. David Kastrup (3): builtin/blame.c: struct blame_entry does not need a prev link Eliminate same_suspect function in builtin/blame.c builtin/blame.c: large-scale rewrite builtin/blame.c | 595 +++- 1 file changed, 371 insertions(+), 224 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] builtin/blame.c: struct blame_entry does not need a prev link
Signed-off-by: David Kastrup d...@gnu.org
---
builtin/blame.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index e44a6bb..2195595 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -197,7 +197,6 @@ static void drop_origin_blob(struct origin *o)
* scoreboard structure, sorted by the target line number.
*/
struct blame_entry {
- struct blame_entry *prev;
struct blame_entry *next;
/* the first line of this group in the final image;
@@ -282,8 +281,6 @@ static void coalesce(struct scoreboard *sb)
ent-s_lno + ent-num_lines == next-s_lno) {
ent-num_lines += next-num_lines;
ent-next = next-next;
- if (ent-next)
- ent-next-prev = ent;
origin_decref(next-suspect);
free(next);
ent-score = 0;
@@ -534,7 +531,7 @@ static void add_blame_entry(struct scoreboard *sb, struct
blame_entry *e)
prev = ent;
/* prev, if not NULL, is the last one that is below e */
- e-prev = prev;
+
if (prev) {
e-next = prev-next;
prev-next = e;
@@ -543,8 +540,6 @@ static void add_blame_entry(struct scoreboard *sb, struct
blame_entry *e)
e-next = sb-ent;
sb-ent = e;
}
- if (e-next)
- e-next-prev = e;
}
/*
@@ -555,14 +550,12 @@ static void add_blame_entry(struct scoreboard *sb, struct
blame_entry *e)
*/
static void dup_entry(struct blame_entry *dst, struct blame_entry *src)
{
- struct blame_entry *p, *n;
+ struct blame_entry *n;
- p = dst-prev;
n = dst-next;
origin_incref(src-suspect);
origin_decref(dst-suspect);
memcpy(dst, src, sizeof(*src));
- dst-prev = p;
dst-next = n;
dst-score = 0;
}
@@ -2502,8 +2495,6 @@ parse_done:
ent-suspect = o;
ent-s_lno = bottom;
ent-next = next;
- if (next)
- next-prev = ent;
origin_incref(o);
}
origin_decref(o);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Globbing for ignored branches?
On Sat, Jan 25, 2014 at 03:15:42PM +0100, Markus Trippelsdorf wrote: Many thanks for the patch. It seems to work as advertised, but only if the negative refspec appears on a separate line. For example: [remote origin] url = git://gcc.gnu.org/git/gcc.git fetch = +refs/heads/*:refs/remotes/origin/* fetch = ^refs/remotes/hjl works fine, but: [remote origin] url = git://gcc.gnu.org/git/gcc.git fetch = +refs/heads/*:refs/remotes/origin/* ^refs/remotes/hjl That does not have anything to do with the negative refspec. The config format is one refspec per fetch key, but you may have as many keys as you like. Doing: [remote origin] fetch = refs/heads/a:refs/heads/a refs/heads/b:refs/heads/b is similarly wrong. You need to do: [remote origin] fetch = refs/heads/a:refs/heads/a fetch = refs/heads/b:refs/heads/b instead. I believe that since space is forbidden in refnames, it should also be forbidden in refspecs, which means that we could interpret the first one as you expected without losing backwards compatibility. But I do not think there is any real advantage to doing so, aside from being more forgiving. I suspect the documentation in that area could be improved, though. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Verifiable git archives?
Here's a rather hackish implementation of the write side. Any
thoughts on the format? (Obviously the implementation needs work.
For example, it needs to be optional.
Thoughts so far:
- I want to put the value of prefix into an extended header.
- Should blobs have their sha1 hashes in an extended header? Pros:
it makes figuring out substitutions easier. Cons: it adds 512 bytes
per file.
- I want to support tags as roots.
- I (or someone) need to write a verifier / verified unpacker. Does
git accept Python code?
This thing is tested in the sense that GNU tar unpacks its output
without any warnings or other fanfare.
--Andy
diff --git a/archive-tar.c b/archive-tar.c
index 719b629..c6bf7e4 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -2,6 +2,8 @@
* Copyright (c) 2005, 2006 Rene Scharfe
*/
#include cache.h
+#include tree.h
+#include object.h
#include tar.h
#include archive.h
#include streaming.h
@@ -200,6 +202,74 @@ static int write_extended_header(struct archiver_args *args,
return 0;
}
+/*
+ * A GIT-SCM object header is a global extended header that embeds a single
+ * git object. This object serves a purpose described by the purpose
+ * field. Valid purposes include:
+ *
+ * - root -- an object that, by itself, in conjunction with other roots,
+ *or in conjunction with external data, identifies a root to use to
+ *verify this archive.
+ * - vrfy -- an object that can be use to prove that the contents
+ *of this archive are as described.
+ *
+ * There's one basic rule to observe: every vrfy object must hash to
+ * a SHA-1 that matches something described in a root, another vrfy object,
+ * or something typed in by a user decoding the archive.
+ *
+ * (Of course, if you want the archive to be usefully verifiable, all of the
+ * non-GIT-SCM contents should also be attributable to an appropriate
+ * vrfy object.)
+ *
+ * The fields are:
+ * GIT-SCM.obj.purpose: the purpose of the embedded object
+ * GIT-SCM.obj.sha1: the sha1 of the embedded object
+ * GIT-SCM.obj.type: the type of the embedded object
+ * GIT-SCM.obj.data: the data in the embedded object
+ *
+ * The block header is intentionally unspecified, except that it must
+ * have typeflag 'g'. (This is to allow some flexibility in trying to
+ * preserve compatibility with old tar implementations.)
+ */
+static int write_gitscm_obj_header(struct archiver_args *args,
+ const char *purpose,
+ const unsigned char *sha1)
+{
+ struct strbuf ext_header = STRBUF_INIT;
+ struct ustar_header header;
+ unsigned int mode;
+ enum object_type type;
+ unsigned long size;
+ void *buffer;
+ const char *typestr;
+ int err = 0;
+
+ strbuf_append_ext_header(ext_header, GIT-SCM.obj.purpose,
+ purpose, strlen(purpose));
+ strbuf_append_ext_header(ext_header, GIT-SCM.obj.sha1,
+ sha1_to_hex(sha1), 40);
+
+ buffer = read_sha1_file(sha1, type, size);
+ typestr = typename(type);
+
+ strbuf_append_ext_header(ext_header, GIT-SCM.obj.type,
+ typestr, strlen(typestr));
+ strbuf_append_ext_header(ext_header, GIT-SCM.obj.data,
+ buffer, size);
+ free(buffer);
+ buffer = NULL;
+
+ memset(header, 0, sizeof(header));
+ *header.typeflag = TYPEFLAG_GLOBAL_HEADER;
+ mode = 0100666;
+ strcpy(header.name, pax_global_header);
+ prepare_header(args, header, mode, ext_header.len);
+ write_blocked(header, sizeof(header));
+ write_blocked(ext_header.buf, ext_header.len);
+ strbuf_release(ext_header);
+ return err;
+}
+
static int write_tar_entry(struct archiver_args *args,
const unsigned char *sha1,
const char *path, size_t pathlen,
@@ -212,6 +282,10 @@ static int write_tar_entry(struct archiver_args *args,
void *buffer;
int err = 0;
+ if (S_ISDIR(mode)) {
+ write_gitscm_obj_header(args, vrfy, sha1);
+ }
+
memset(header, 0, sizeof(header));
if (S_ISDIR(mode) || S_ISGITLINK(mode)) {
@@ -384,8 +458,11 @@ static int write_tar_archive(const struct archiver *ar,
if (args-commit_sha1)
err = write_global_extended_header(args);
- if (!err)
+ if (!err) {
+ write_gitscm_obj_header(args, root, args-commit_sha1);
+ write_gitscm_obj_header(args, vrfy, args-tree-object.sha1);
err = write_archive_entries(args, write_tar_entry);
+ }
if (!err)
write_trailer();
return err;
[PATCH] tree_entry_interesting: match against all pathspecs
The current basedir compare aborts early in order to avoid futile recursive searches. However, a match may still be found by another pathspec. This can cause an error while checking out files from a branch when using multiple pathspecs: $ git checkout master -- 'a/*.txt' 'b/*.txt' error: pathspec 'a/*.txt' did not match any file(s) known to git. Signed-off-by: Andy Spencer andy753...@gmail.com --- tree-walk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tree-walk.c b/tree-walk.c index 5ece8c3..e06f240 100644 --- a/tree-walk.c +++ b/tree-walk.c @@ -743,7 +743,7 @@ match_wildcards: if (item-nowildcard_len !match_wildcard_base(item, base_str, baselen, matched)) - return entry_not_interesting; + continue; /* * Concatenate base and entry-path into one and do -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added get sendmail from .mailrc
Brilliantov Kirill Vladimirovich brillian...@inbox.ru wrote: Signed-off-by: Brilliantov Kirill Vladimirovich brillian...@inbox.ru --- git-send-email.perl | 18 ++ 1 file changed, 18 insertions(+) Some documentation references to .mailrc and its format would be nice. --- a/git-send-email.perl +++ b/git-send-email.perl @@ -28,6 +28,7 @@ use File::Temp qw/ tempdir tempfile /; use File::Spec::Functions qw(catfile); use Error qw(:try); use Git; +use File::HomeDir; We should probably avoid a new dependency and also remain consistent with the rest of git handles home directories. Unfortunately, expand_user_path()/git_config_pathname() isn't currently exposed to scripters right now... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tree_entry_interesting: match against all pathspecs
On Sat, Jan 25, 2014 at 10:06:46PM +, Andy Spencer wrote: The current basedir compare aborts early in order to avoid futile recursive searches. However, a match may still be found by another pathspec. This can cause an error while checking out files from a branch when using multiple pathspecs: $ git checkout master -- 'a/*.txt' 'b/*.txt' error: pathspec 'a/*.txt' did not match any file(s) known to git. Signed-off-by: Andy Spencer andy753...@gmail.com --- tree-walk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tree-walk.c b/tree-walk.c index 5ece8c3..e06f240 100644 --- a/tree-walk.c +++ b/tree-walk.c @@ -743,7 +743,7 @@ match_wildcards: if (item-nowildcard_len !match_wildcard_base(item, base_str, baselen, matched)) - return entry_not_interesting; + continue; /* * Concatenate base and entry-path into one and do Ack. Perhaps this on top to verify it -- 8 -- diff --git a/t/t4010-diff-pathspec.sh b/t/t4010-diff-pathspec.sh index af5134b..d9f37c3 100755 --- a/t/t4010-diff-pathspec.sh +++ b/t/t4010-diff-pathspec.sh @@ -110,4 +110,17 @@ test_expect_success 'diff-tree -r with wildcard' ' test_cmp expected result ' +test_expect_success 'diff multiple wildcard pathspecs' ' + mkdir path2 + echo rezrov path2/file1 + git update-index --add path2/file1 + tree3=`git write-tree` + git diff --name-only $tree $tree3 -- path2*1 path1*1 actual + cat EOF expect +path1/file1 +path2/file1 +EOF + test_cmp expect actual +' + test_done -- 8 -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added get sendmail from .mailrc
On 2014-01-25 22:37:21, Eric Wong wrote: Brilliantov Kirill Vladimirovich brillian...@inbox.ru wrote: Signed-off-by: Brilliantov Kirill Vladimirovich brillian...@inbox.ru --- git-send-email.perl | 18 ++ 1 file changed, 18 insertions(+) Some documentation references to .mailrc and its format would be nice. Unfortunally I can't found official documentation on this option: http://linux.die.net/man/1/mailx http://publib.boulder.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.files/doc/aixfiles/mailrc.htm On my system (Debian GNU/Linux 7.3) documentation on mailx not conteins description senmail options. --- a/git-send-email.perl +++ b/git-send-email.perl @@ -28,6 +28,7 @@ use File::Temp qw/ tempdir tempfile /; use File::Spec::Functions qw(catfile); use Error qw(:try); use Git; +use File::HomeDir; We should probably avoid a new dependency and also remain consistent with the rest of git handles home directories. Unfortunately, expand_user_path()/git_config_pathname() isn't currently exposed to scripters right now... Ok, if new dependency is not allowed I see next ways: - add new argument - add new configuration parameters -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
