* Re: [PATCH 0/3] Un-pessimize "diff-index $commit -- $pathspec"
From: Linus Torvalds @ 2011-08-29 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nguyen Thai Ngoc Duy
In-Reply-To: <1314653603-7533-1-git-send-email-gitster@pobox.com>
On Mon, Aug 29, 2011 at 2:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Before and after applying this series, looking for changes in the kernel
> repository with a fairly narrow pathspec gets a moderate speeds up.
"moderate speeds up"?
Looks like a big win to me. Admittedly it's already a pretty fast
operation, but script it and repeat it a million times, and that will
matter a lot more.
I guess the "--raw" diff part means that you are hiding the time to
make a real diff, which would otherwise swamp everything else. Even
so, this looks like a good improvement.
Linus
^ permalink raw reply
* Re: More formatting with 'git tag -l'
From: Michał Górny @ 2011-08-29 21:50 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110829213757.GB14299@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 987 bytes --]
On Mon, 29 Aug 2011 17:37:57 -0400
Jeff King <peff@peff.net> wrote:
> On Mon, Aug 29, 2011 at 11:20:11PM +0200, Michał Górny wrote:
>
> > > You can do something similar with 'git for-each-ref', which is
> > > probably what you should be using if you are scripting, anyway
> > > (as it is "plumbing" and guaranteed not to change in future
> > > releases). Something like:
> >
> > Thanks, that looks great. The only thing I am missing right now is
> > a simple %(body) variant which would strip the GPG signature. I'd
> > really like to avoid establishing a shell oneliner to do that.
>
> Yeah, I don't think that's possible with the current code. I don't
> think it would be unreasonable to add "%(tagcontents)" and
> "%(tagsignature)" or something similar, though.
>
> Want to try a patch?
I'll take a look at the code tomorrow and see if I can assemble
something useful. Someone will have to design nice names though.
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: More formatting with 'git tag -l'
From: Jeff King @ 2011-08-29 21:37 UTC (permalink / raw)
To: Michał Górny; +Cc: git
In-Reply-To: <20110829232011.565ea553@pomiocik.lan>
On Mon, Aug 29, 2011 at 11:20:11PM +0200, Michał Górny wrote:
> > You can do something similar with 'git for-each-ref', which is
> > probably what you should be using if you are scripting, anyway (as it
> > is "plumbing" and guaranteed not to change in future releases).
> > Something like:
>
> Thanks, that looks great. The only thing I am missing right now is
> a simple %(body) variant which would strip the GPG signature. I'd
> really like to avoid establishing a shell oneliner to do that.
Yeah, I don't think that's possible with the current code. I don't think
it would be unreasonable to add "%(tagcontents)" and "%(tagsignature)"
or something similar, though.
Want to try a patch?
-Peff
^ permalink raw reply
* [PATCH 3/3] diff-index: pass pathspec down to unpack-trees machinery
From: Junio C Hamano @ 2011-08-29 21:33 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Nguyen Thai Ngoc Duy
In-Reply-To: <1314653603-7533-1-git-send-email-gitster@pobox.com>
And finally, pass the pathspec down through unpack_trees() to traverse_trees()
callchain.
Before and after applying this series, looking for changes in the kernel
repository with a fairly narrow pathspec gets a moderate speeds up.
(without patch)
$ /usr/bin/time git diff --raw v2.6.27 -- net/ipv6 >/dev/null
0.48user 0.05system 0:00.53elapsed 100%CPU (0avgtext+0avgdata 163296maxresident)k
0inputs+952outputs (0major+11163minor)pagefaults 0swaps
(with patch)
$ /usr/bin/time git diff --raw v2.6.27 -- net/ipv6 >/dev/null
0.01user 0.00system 0:00.02elapsed 104%CPU (0avgtext+0avgdata 43856maxresident)k
0inputs+24outputs (0major+3688minor)pagefaults 0swaps
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff-lib.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index f8454dd..ebe751e 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -468,6 +468,7 @@ static int diff_cache(struct rev_info *revs,
opts.unpack_data = revs;
opts.src_index = &the_index;
opts.dst_index = NULL;
+ opts.pathspec = &revs->diffopt.pathspec;
init_tree_desc(&t, tree->buffer, tree->size);
return unpack_trees(1, &t, &opts);
--
1.7.7.rc0.70.g82660
^ permalink raw reply related
* [PATCH 2/3] unpack-trees: allow pruning with pathspec
From: Junio C Hamano @ 2011-08-29 21:33 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Nguyen Thai Ngoc Duy
In-Reply-To: <1314653603-7533-1-git-send-email-gitster@pobox.com>
Use the pathspec pruning of traverse_trees() from unpack_trees(). Again,
the unpack_trees() machinery is primarily meant for merging two (or more)
trees, and because a merge is a full tree operation, it didn't support any
pruning with pathspec, and this codepath probably should not be enabled
while running a merge, but the caller in diff-lib.c::diff_cache() should
be able to take advanrage of it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
unpack-trees.c | 2 ++
unpack-trees.h | 1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index cc616c3..670b464 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -444,6 +444,7 @@ static int traverse_trees_recursive(int n, unsigned long dirmask,
newinfo = *info;
newinfo.prev = info;
+ newinfo.pathspec = info->pathspec;
newinfo.name = *p;
newinfo.pathlen += tree_entry_len(p->path, p->sha1) + 1;
newinfo.conflicts |= df_conflicts;
@@ -1040,6 +1041,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
info.fn = unpack_callback;
info.data = o;
info.show_all_errors = o->show_all_errors;
+ info.pathspec = o->pathspec;
if (o->prefix) {
/*
diff --git a/unpack-trees.h b/unpack-trees.h
index 7998948..5e432f5 100644
--- a/unpack-trees.h
+++ b/unpack-trees.h
@@ -52,6 +52,7 @@ struct unpack_trees_options {
const char *prefix;
int cache_bottom;
struct dir_struct *dir;
+ struct pathspec *pathspec;
merge_fn_t fn;
const char *msgs[NB_UNPACK_TREES_ERROR_TYPES];
/*
--
1.7.7.rc0.70.g82660
^ permalink raw reply related
* [PATCH 1/3] traverse_trees(): allow pruning with pathspec
From: Junio C Hamano @ 2011-08-29 21:33 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Nguyen Thai Ngoc Duy
In-Reply-To: <1314653603-7533-1-git-send-email-gitster@pobox.com>
The traverse_trees() machinery is primarily meant for merging two (or
more) trees, and because a merge is a full tree operation, it doesn't
support any pruning with pathspec.
Since d1f2d7e (Make run_diff_index() use unpack_trees(), not read_tree(),
2008-01-19), however, we use unpack_trees() to traverse_trees() callchain
to perform "diff-index", which could waste a lot of work traversing trees
outside the user-supplied pathspec, only to discard at the blob comparison
level in diff-lib.c::oneway_diff() which is way too late.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
tree-walk.c | 39 +++++++++++++++++++++++++++++++++------
tree-walk.h | 1 +
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/tree-walk.c b/tree-walk.c
index 33f749e..808bb55 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -309,6 +309,18 @@ static void free_extended_entry(struct tree_desc_x *t)
}
}
+static inline int prune_traversal(struct name_entry *e,
+ struct traverse_info *info,
+ struct strbuf *base,
+ int still_interesting)
+{
+ if (!info->pathspec || still_interesting == 2)
+ return 2;
+ if (still_interesting < 0)
+ return still_interesting;
+ return tree_entry_interesting(e, base, 0, info->pathspec);
+}
+
int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
{
int ret = 0;
@@ -316,10 +328,18 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
struct name_entry *entry = xmalloc(n*sizeof(*entry));
int i;
struct tree_desc_x *tx = xcalloc(n, sizeof(*tx));
+ struct strbuf base = STRBUF_INIT;
+ int interesting = 1;
for (i = 0; i < n; i++)
tx[i].d = t[i];
+ if (info->prev) {
+ strbuf_grow(&base, info->pathlen);
+ make_traverse_path(base.buf, info->prev, &info->name);
+ base.buf[info->pathlen-1] = '/';
+ strbuf_setlen(&base, info->pathlen);
+ }
for (;;) {
unsigned long mask, dirmask;
const char *first = NULL;
@@ -376,16 +396,22 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
mask |= 1ul << i;
if (S_ISDIR(entry[i].mode))
dirmask |= 1ul << i;
+ e = &entry[i];
}
if (!mask)
break;
- ret = info->fn(n, mask, dirmask, entry, info);
- if (ret < 0) {
- error = ret;
- if (!info->show_all_errors)
- break;
+ interesting = prune_traversal(e, info, &base, interesting);
+ if (interesting < 0)
+ break;
+ if (interesting) {
+ ret = info->fn(n, mask, dirmask, entry, info);
+ if (ret < 0) {
+ error = ret;
+ if (!info->show_all_errors)
+ break;
+ }
+ mask &= ret;
}
- mask &= ret;
ret = 0;
for (i = 0; i < n; i++)
if (mask & (1ul << i))
@@ -395,6 +421,7 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
for (i = 0; i < n; i++)
free_extended_entry(tx + i);
free(tx);
+ strbuf_release(&base);
return error;
}
diff --git a/tree-walk.h b/tree-walk.h
index 39524b7..0089581 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -44,6 +44,7 @@ struct traverse_info {
struct traverse_info *prev;
struct name_entry name;
int pathlen;
+ struct pathspec *pathspec;
unsigned long conflicts;
traverse_callback_t fn;
--
1.7.7.rc0.70.g82660
^ permalink raw reply related
* [PATCH 0/3] Un-pessimize "diff-index $commit -- $pathspec"
From: Junio C Hamano @ 2011-08-29 21:33 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Nguyen Thai Ngoc Duy
In-Reply-To: <7vty9054qr.fsf@alter.siamese.dyndns.org>
"git diff A B -- $pathspec" to compare two tree-ishes knew how to apply
pathspec to avoid opening trees that fall outside the area of interest,
but "git diff A -- $pathspec" used unpack_trees() machinery that was meant
for full-tree merges, and ended up reading the whole tree only to discard
potentially major part of the work it does.
Before and after applying this series, looking for changes in the kernel
repository with a fairly narrow pathspec gets a moderate speeds up.
(without patch)
$ /usr/bin/time git diff --raw v2.6.27 -- net/ipv6 >/dev/null
0.48user 0.05system 0:00.53elapsed 100%CPU (0avgtext+0avgdata 163296maxresident)k
0inputs+952outputs (0major+11163minor)pagefaults 0swaps
(with patch)
$ /usr/bin/time git diff --raw v2.6.27 -- net/ipv6 >/dev/null
0.01user 0.00system 0:00.02elapsed 104%CPU (0avgtext+0avgdata 43856maxresident)k
0inputs+24outputs (0major+3688minor)pagefaults 0swaps
Junio C Hamano (3):
tree-walk: allow pruning with pathspec
unpack-trees: allow pruning with pathspec
diff-index: pass pathspec down to unpack-trees machinery
diff-lib.c | 1 +
tree-walk.c | 39 +++++++++++++++++++++++++++++++++------
tree-walk.h | 1 +
unpack-trees.c | 2 ++
unpack-trees.h | 1 +
5 files changed, 38 insertions(+), 6 deletions(-)
--
1.7.7.rc0.70.g82660
^ permalink raw reply
* Re: [PATCH] .gitattributes: Enable cpp diff parsing for .[ch] files
From: Peter Zijlstra @ 2011-08-29 21:30 UTC (permalink / raw)
To: Boaz Harrosh
Cc: Linus Torvalds, Andrew Morton, Git Mailing List, linux-kernel,
Junio C Hamano
In-Reply-To: <4E5BFD36.2090000@panasas.com>
On Mon, 2011-08-29 at 13:57 -0700, Boaz Harrosh wrote:
>
> Adding a .gitattributes file to the Linux git tree is a very simple message.
> "In the linux git tree all .c and .h files are c-source files" (And git will
> treat them that way)
I'm all for it, I hate those labels in git-diff output..
^ permalink raw reply
* Re: [PATCH v2 1/2] check-ref-format --print: Normalize refnames that start with slashes
From: Jeff King @ 2011-08-29 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, cmn
In-Reply-To: <7vhb50543g.fsf@alter.siamese.dyndns.org>
On Mon, Aug 29, 2011 at 01:56:35PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Mon, Aug 29, 2011 at 02:50:12PM -0400, Jeff King wrote:
> >
> >> 3. Having better tool support for comparing two sets of commits. The
> >> ideal interface (to me) for this workflow would be something like:
> >
> > BTW, this discussion is obviously about comparing what was applied
> > upstream with what was submitted, but I think such a tool could have
> > other purposes, too. It should be able to provide a much nicer interdiff
> > between two versions of the same series (e.g., for reviewers looking at
> > a re-roll).
>
> I agree with it in principle, but I am not going to write one any time
> soon.
Heh. I didn't expect you to. :) I may make an attempt at something, but
I'd be happy if somebody else has ideas, too.
> I think the most difficult case is when the submitter based a fix on
> 'next' or 'pu' and I fixed it up so that it applies to 'maint'. It is not
> trivial to express conflict resolution in such a case, as what your tool
> has to do its work are (1) the original patch that may apply to
> "somewhere" (the tool could ask "am -3" to help it out), and (2) the patch
> that is queued somewhere in 'pu'.
The nastiest part of such a thing is not necessarily comparing the
patches afterwards, but the actual conflicts you have to resolve to
convince "am -3" to apply the patch on "master" in the first place.
Consider this toy example, which accidentally bases a topic off of
"next" instead of "master":
git init repo &&
cd repo &&
perl -le 'print "line $_" for (1..20)' >file &&
git add file &&
git commit -m base &&
git checkout -b next &&
perl -pi -e 's/10/$& unrelated topic on next/' file &&
git commit -a -m 'unrelated topic' &&
git checkout -b our-topic next && # oops!
perl -pi -e 's/11/$& our topic/' file &&
git commit -a -m 'our topic' &&
git format-patch --stdout -1 >patch &&
git checkout master
Obviously "git am" will fail to apply the patch. You can do it with "am
-3", but get a conflict like:
++<<<<<<< HEAD
+line 10
+line 11
++=======
+ line 10 unrelated topic on next
+ line 11 our topic
++>>>>>>> our topic
which is obviously easy to resolve in this toy example, but harder in
the real world (I assume in really hard cases, you just complain to the
submitter to rebase it properly).
But assuming you resolve that properly to:
line 10
line 11 our topic
what does the original submitter see? If they try to rebase their topic
onto master, they'll get this pretty sane conflict:
++<<<<<<< HEAD
+line 10
++=======
+ line 10 unrelated topic on next
++>>>>>>> our topic
I think the tool behavior I outlined in the previous message would
yield:
diff --git a/file b/file
--- a/file
+++ b/file
line 8
line 9
-line 10 unrelated topic on next
+line 10
line 11 our topic
line 12
Accept this change [y,n,q]?
That is, it would look at the final versions of what each patch
produces, and try to apply the differences from one to the other, and
then use the result to apply on top of our rebase-in-progress.
So really, I think the ugliness of what the submitter would see is no
uglier than what you had to do during "git am". If you make trivial
changes, they'll see trivial changes. If you had to pick apart large
chunks of code into their constituent topics, then that's what the
submitter will see when reviewing the differences.
But note that I didn't actually run the above "this is what my tool
should do" through an actual script. I haven't written anything yet, so
I am just guessing, and there may be more complex cases where it breaks
down.
-Peff
^ permalink raw reply
* Re: More formatting with 'git tag -l'
From: Michał Górny @ 2011-08-29 21:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110829193658.GG756@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
On Mon, 29 Aug 2011 15:36:58 -0400
Jeff King <peff@peff.net> wrote:
> On Mon, Aug 29, 2011 at 09:10:18PM +0200, Michał Górny wrote:
>
> > Would it be feasible to add more formatting options to 'git tag -l'.
> > Right now, it's just '-n' but if more formatting options were added,
> > I think I could use annotated tags as a nice source for
> > autogenerated 'NEWS' file.
> >
> > What I am most concerned about is the date of last commit contained
> > in the tag. Having an option to format each printed tag and use that
> > information along with tag details in a format string (like the one
> > used by 'git log') would be great.
>
> You can do something similar with 'git for-each-ref', which is
> probably what you should be using if you are scripting, anyway (as it
> is "plumbing" and guaranteed not to change in future releases).
> Something like:
Thanks, that looks great. The only thing I am missing right now is
a simple %(body) variant which would strip the GPG signature. I'd
really like to avoid establishing a shell oneliner to do that.
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* [PATCH] strbuf_grow(): maintain nul-termination even for new buffer
From: Thomas Rast @ 2011-08-29 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit
In the case where sb is initialized to the slopbuf (through
strbuf_init(sb,0) or STRBUF_INIT), strbuf_grow() loses the terminating
nul: it grows the buffer, but gives ALLOC_GROW a NULL source to avoid
it being freed. So ALLOC_GROW does not copy anything to the new
memory area.
This subtly broke the call to strbuf_getline in read_next_command()
[fast-import.c:1855], which goes
strbuf_detach(&command_buf, NULL); # command_buf is now = STRBUF_INIT
stdin_eof = strbuf_getline(&command_buf, stdin, '\n');
if (stdin_eof)
return EOF;
In strbuf_getwholeline, this did
strbuf_grow(sb, 0); # loses nul-termination
if (feof(fp))
return EOF;
strbuf_reset(sb); # this would have nul-terminated!
Valgrind found this because fast-import subsequently uses prefixcmp()
on command_buf.buf, which after the EOF exit contains only
uninitialized memory.
Arguably strbuf_getwholeline is also broken, in that it touches the
buffer before deciding whether to do any work. However, it seems more
futureproof to not let the strbuf API lose the nul-termination by its
own fault.
So make sure that strbuf_grow() puts in a nul even if it has nowhere
to copy it from. This makes strbuf_grow(sb, 0) a semantic no-op as
far as readers of the buffer are concerned.
Also remove the nul-termination added by strbuf_init, which is made
redudant.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Only found this now because the bug is only triggered by the tests
added in 4cedb78 (fast-import: add input format tests, 2011-08-11).
strbuf.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index 1a7df12..4556f96 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -30,10 +30,8 @@ void strbuf_init(struct strbuf *sb, size_t hint)
{
sb->alloc = sb->len = 0;
sb->buf = strbuf_slopbuf;
- if (hint) {
+ if (hint)
strbuf_grow(sb, hint);
- sb->buf[0] = '\0';
- }
}
void strbuf_release(struct strbuf *sb)
@@ -65,12 +63,15 @@ void strbuf_attach(struct strbuf *sb, void *buf, size_t len, size_t alloc)
void strbuf_grow(struct strbuf *sb, size_t extra)
{
+ int new_buf = !sb->alloc;
if (unsigned_add_overflows(extra, 1) ||
unsigned_add_overflows(sb->len, extra + 1))
die("you want to use way too much memory");
- if (!sb->alloc)
+ if (new_buf)
sb->buf = NULL;
ALLOC_GROW(sb->buf, sb->len + extra + 1, sb->alloc);
+ if (new_buf)
+ sb->buf[0] = '\0';
}
void strbuf_trim(struct strbuf *sb)
--
1.7.7.rc0.370.gdcae57
^ permalink raw reply related
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Junio C Hamano @ 2011-08-29 21:09 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Marat Radchenko, git
In-Reply-To: <7vty9054qr.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Of course the merge machinery does not know anything about pruning with
>> pathspec, so it is understandable (not justifiable) it would walk the full
>> tree.
>>
>> Will try to find time this week to cook up something.
>
> This is still rough, but seems to pass the test suite, and gives me some
> performance boost when applied to the kernel tree:
>
> (without patch)
> $ time git diff --raw --cached v2.6.30 -- virt/kvm
> real 0m0.114s
> user 0m0.088s
> sys 0m0.028s
>
> (with patch)
> $ time ./git diff --raw --cached v2.6.30 -- virt/kvm
> real 0m0.075s
> user 0m0.068s
> sys 0m0.008s
Heh, this is even better without --cached.
(without patch)
$ /usr/bin/time git diff --raw v2.6.27 -- net/ipv6
real 0m0.538s
user 0m0.492s
sys 0m0.048s
(with patch)
$ /usr/bin/time git diff --raw v2.6.27 -- net/ipv6
real 0m0.038s
user 0m0.028s
sys 0m0.012s
^ permalink raw reply
* Re: [PATCH 1/2] am: preliminary support for hg patches
From: Junio C Hamano @ 2011-08-29 21:05 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <CAOxFTcyqGCB3TcS2CmFuVXqrCP2H-1aBDv3JJVKrNp-Q8Zahmg@mail.gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> Nope, it doesn't have index .... lines. Still, the patches seems to
> apply correctly. Well, the couple of patches I tested did, at least,
> even though they were marked as diff --git and they were lacking the
> index ... lines.
Does "am -3" do the right thing when the patch does not apply cleanly, for
example? What about renaming patches?
Until we are reasonably sure that we can grok it reasonably well, I'd
sleep better if we stripped " --git" part from a patch that is known to be
produced by somebody that does not fully re-implement "git diff".
^ permalink raw reply
* Re: [PATCH] .gitattributes: Enable cpp diff parsing for .[ch] files
From: Boaz Harrosh @ 2011-08-29 20:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Linus Torvalds, Andrew Morton, Git Mailing List, linux-kernel,
Junio C Hamano
In-Reply-To: <1314624752.2816.32.camel@twins>
On 08/29/2011 06:32 AM, Peter Zijlstra wrote:
> On Fri, 2011-08-26 at 13:55 -0700, Boaz Harrosh wrote:
>
>> But this patch is for all the people and distributions that are going
>> to use the old git versions for a while, (Years).
>>
>> It is important for the Linux mailing-list review, because you get
>> patches with:
>>
>> @@@ lable out:
>> - change foo
>> + to bazz
>>
>> And how the hell are you suppose to know where in the file it is.
>> This is such a trivial addition, that can help unify everyone's
>> usage. I don't see the down sides.
>
> Ah, I'm using:
>
> # cat ~/.gitconfig
> [diff "default"]
> xfuncname = "^[[:alpha:]$_].*[^:]$"
>
>
> For this.
It looks like a lost cause so I'll try for the last time.
Everyone is suggesting that each one do his own cooked up secrets and solutions.
And those that are stupid and know nothing like me are un-lucky. But what I'm
proposing is that by just doing a "git clone" you'll be using these settings
that we like to see, when you send us your patches.
Adding a .gitattributes file to the Linux git tree is a very simple message.
"In the linux git tree all .c and .h files are c-source files" (And git will
treat them that way)
Now that was not so hard was it? Really, no one said anything bad or negative
about the patch, only excuses how it can be achieved, very difficultly, in
another way. So for the last time:
What are you guys afraid of? what possibly could be bad about this patch?
Sigh
Good bye to this subject
Boaz
^ permalink raw reply
* Re: [PATCH v2 1/2] check-ref-format --print: Normalize refnames that start with slashes
From: Junio C Hamano @ 2011-08-29 20:56 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Haggerty, git, cmn
In-Reply-To: <20110829190118.GE756@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Aug 29, 2011 at 02:50:12PM -0400, Jeff King wrote:
>
>> 3. Having better tool support for comparing two sets of commits. The
>> ideal interface (to me) for this workflow would be something like:
>
> BTW, this discussion is obviously about comparing what was applied
> upstream with what was submitted, but I think such a tool could have
> other purposes, too. It should be able to provide a much nicer interdiff
> between two versions of the same series (e.g., for reviewers looking at
> a re-roll).
I agree with it in principle, but I am not going to write one any time
soon. I think the most difficult case is when the submitter based a fix on
'next' or 'pu' and I fixed it up so that it applies to 'maint'. It is not
trivial to express conflict resolution in such a case, as what your tool
has to do its work are (1) the original patch that may apply to
"somewhere" (the tool could ask "am -3" to help it out), and (2) the patch
that is queued somewhere in 'pu'.
^ permalink raw reply
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Junio C Hamano @ 2011-08-29 20:50 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Marat Radchenko, git
In-Reply-To: <7vty9054qr.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Of course the merge machinery does not know anything about pruning with
>> pathspec, so it is understandable (not justifiable) it would walk the full
>> tree.
>>
>> Will try to find time this week to cook up something.
>
> This is still rough, but seems to pass the test suite, and gives me some
> performance boost when applied to the kernel tree:
Ehh, no, the patch does not apply to the kernel tree, but I meant "when
used on the kernel tree".
> (without patch)
> $ time git diff --raw --cached v2.6.30 -- virt/kvm
> real 0m0.114s
> user 0m0.088s
> sys 0m0.028s
>
> (with patch)
> $ time ./git diff --raw --cached v2.6.30 -- virt/kvm
> real 0m0.075s
> user 0m0.068s
> sys 0m0.008s
>
> What I do not like about it most is that we have an infrastructure that
> links traverse_info across stackframes to store the paths unexpanded and
> without extra linear allocation, but tree_entry_interesting() wants the
> path as a single string. Hence unpack_trees() carries an extra baggage
> "base" string, even though the general callback in tree-walk machinery
> does not need it.
>
> I think this can be trivially optimized to keep a pointer to a single
> strbuf in the traverse_info (initialize it at the same points as this
> patch sets info.pathspec), extending it as it digs deeper (copy the same
> pointer to the strbuf to a child traverse_info and tuck the name of the
> directory it descends into it, at the same points as this patch copies
> info->pathspec from the parent), and resetting the length back when the
> traversal into a subdirectory comes back.
>
>
>
> diff-lib.c | 1 +
> tree-walk.c | 39 +++++++++++++++++++++++++++++++++------
> tree-walk.h | 1 +
> unpack-trees.c | 2 ++
> unpack-trees.h | 1 +
> 5 files changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/diff-lib.c b/diff-lib.c
> index f8454dd..ebe751e 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> @@ -468,6 +468,7 @@ static int diff_cache(struct rev_info *revs,
> opts.unpack_data = revs;
> opts.src_index = &the_index;
> opts.dst_index = NULL;
> + opts.pathspec = &revs->diffopt.pathspec;
>
> init_tree_desc(&t, tree->buffer, tree->size);
> return unpack_trees(1, &t, &opts);
> diff --git a/tree-walk.c b/tree-walk.c
> index 33f749e..808bb55 100644
> --- a/tree-walk.c
> +++ b/tree-walk.c
> @@ -309,6 +309,18 @@ static void free_extended_entry(struct tree_desc_x *t)
> }
> }
>
> +static inline int prune_traversal(struct name_entry *e,
> + struct traverse_info *info,
> + struct strbuf *base,
> + int still_interesting)
> +{
> + if (!info->pathspec || still_interesting == 2)
> + return 2;
> + if (still_interesting < 0)
> + return still_interesting;
> + return tree_entry_interesting(e, base, 0, info->pathspec);
> +}
> +
> int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
> {
> int ret = 0;
> @@ -316,10 +328,18 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
> struct name_entry *entry = xmalloc(n*sizeof(*entry));
> int i;
> struct tree_desc_x *tx = xcalloc(n, sizeof(*tx));
> + struct strbuf base = STRBUF_INIT;
> + int interesting = 1;
>
> for (i = 0; i < n; i++)
> tx[i].d = t[i];
>
> + if (info->prev) {
> + strbuf_grow(&base, info->pathlen);
> + make_traverse_path(base.buf, info->prev, &info->name);
> + base.buf[info->pathlen-1] = '/';
> + strbuf_setlen(&base, info->pathlen);
> + }
> for (;;) {
> unsigned long mask, dirmask;
> const char *first = NULL;
> @@ -376,16 +396,22 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
> mask |= 1ul << i;
> if (S_ISDIR(entry[i].mode))
> dirmask |= 1ul << i;
> + e = &entry[i];
> }
> if (!mask)
> break;
> - ret = info->fn(n, mask, dirmask, entry, info);
> - if (ret < 0) {
> - error = ret;
> - if (!info->show_all_errors)
> - break;
> + interesting = prune_traversal(e, info, &base, interesting);
> + if (interesting < 0)
> + break;
> + if (interesting) {
> + ret = info->fn(n, mask, dirmask, entry, info);
> + if (ret < 0) {
> + error = ret;
> + if (!info->show_all_errors)
> + break;
> + }
> + mask &= ret;
> }
> - mask &= ret;
> ret = 0;
> for (i = 0; i < n; i++)
> if (mask & (1ul << i))
> @@ -395,6 +421,7 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
> for (i = 0; i < n; i++)
> free_extended_entry(tx + i);
> free(tx);
> + strbuf_release(&base);
> return error;
> }
>
> diff --git a/tree-walk.h b/tree-walk.h
> index 39524b7..0089581 100644
> --- a/tree-walk.h
> +++ b/tree-walk.h
> @@ -44,6 +44,7 @@ struct traverse_info {
> struct traverse_info *prev;
> struct name_entry name;
> int pathlen;
> + struct pathspec *pathspec;
>
> unsigned long conflicts;
> traverse_callback_t fn;
> diff --git a/unpack-trees.c b/unpack-trees.c
> index cc616c3..670b464 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -444,6 +444,7 @@ static int traverse_trees_recursive(int n, unsigned long dirmask,
>
> newinfo = *info;
> newinfo.prev = info;
> + newinfo.pathspec = info->pathspec;
> newinfo.name = *p;
> newinfo.pathlen += tree_entry_len(p->path, p->sha1) + 1;
> newinfo.conflicts |= df_conflicts;
> @@ -1040,6 +1041,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
> info.fn = unpack_callback;
> info.data = o;
> info.show_all_errors = o->show_all_errors;
> + info.pathspec = o->pathspec;
>
> if (o->prefix) {
> /*
> diff --git a/unpack-trees.h b/unpack-trees.h
> index 7998948..5e432f5 100644
> --- a/unpack-trees.h
> +++ b/unpack-trees.h
> @@ -52,6 +52,7 @@ struct unpack_trees_options {
> const char *prefix;
> int cache_bottom;
> struct dir_struct *dir;
> + struct pathspec *pathspec;
> merge_fn_t fn;
> const char *msgs[NB_UNPACK_TREES_ERROR_TYPES];
> /*
^ permalink raw reply
* Re: git bug reporting
From: Junio C Hamano @ 2011-08-29 20:44 UTC (permalink / raw)
To: Jeff King; +Cc: Bryan Jacobs, Scott Chacon, git
In-Reply-To: <20110829192618.GF756@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> In the meantime, I've updated:
> ...
Thanks. I've also made sure that the very first paragraph of "A note fromt
he maintainer" talks about it (yes it already does).
^ permalink raw reply
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Junio C Hamano @ 2011-08-29 20:42 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Marat Radchenko, git
In-Reply-To: <7v1uw46srf.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Of course the merge machinery does not know anything about pruning with
> pathspec, so it is understandable (not justifiable) it would walk the full
> tree.
>
> Will try to find time this week to cook up something.
This is still rough, but seems to pass the test suite, and gives me some
performance boost when applied to the kernel tree:
(without patch)
$ time git diff --raw --cached v2.6.30 -- virt/kvm
real 0m0.114s
user 0m0.088s
sys 0m0.028s
(with patch)
$ time ./git diff --raw --cached v2.6.30 -- virt/kvm
real 0m0.075s
user 0m0.068s
sys 0m0.008s
What I do not like about it most is that we have an infrastructure that
links traverse_info across stackframes to store the paths unexpanded and
without extra linear allocation, but tree_entry_interesting() wants the
path as a single string. Hence unpack_trees() carries an extra baggage
"base" string, even though the general callback in tree-walk machinery
does not need it.
I think this can be trivially optimized to keep a pointer to a single
strbuf in the traverse_info (initialize it at the same points as this
patch sets info.pathspec), extending it as it digs deeper (copy the same
pointer to the strbuf to a child traverse_info and tuck the name of the
directory it descends into it, at the same points as this patch copies
info->pathspec from the parent), and resetting the length back when the
traversal into a subdirectory comes back.
diff-lib.c | 1 +
tree-walk.c | 39 +++++++++++++++++++++++++++++++++------
tree-walk.h | 1 +
unpack-trees.c | 2 ++
unpack-trees.h | 1 +
5 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index f8454dd..ebe751e 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -468,6 +468,7 @@ static int diff_cache(struct rev_info *revs,
opts.unpack_data = revs;
opts.src_index = &the_index;
opts.dst_index = NULL;
+ opts.pathspec = &revs->diffopt.pathspec;
init_tree_desc(&t, tree->buffer, tree->size);
return unpack_trees(1, &t, &opts);
diff --git a/tree-walk.c b/tree-walk.c
index 33f749e..808bb55 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -309,6 +309,18 @@ static void free_extended_entry(struct tree_desc_x *t)
}
}
+static inline int prune_traversal(struct name_entry *e,
+ struct traverse_info *info,
+ struct strbuf *base,
+ int still_interesting)
+{
+ if (!info->pathspec || still_interesting == 2)
+ return 2;
+ if (still_interesting < 0)
+ return still_interesting;
+ return tree_entry_interesting(e, base, 0, info->pathspec);
+}
+
int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
{
int ret = 0;
@@ -316,10 +328,18 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
struct name_entry *entry = xmalloc(n*sizeof(*entry));
int i;
struct tree_desc_x *tx = xcalloc(n, sizeof(*tx));
+ struct strbuf base = STRBUF_INIT;
+ int interesting = 1;
for (i = 0; i < n; i++)
tx[i].d = t[i];
+ if (info->prev) {
+ strbuf_grow(&base, info->pathlen);
+ make_traverse_path(base.buf, info->prev, &info->name);
+ base.buf[info->pathlen-1] = '/';
+ strbuf_setlen(&base, info->pathlen);
+ }
for (;;) {
unsigned long mask, dirmask;
const char *first = NULL;
@@ -376,16 +396,22 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
mask |= 1ul << i;
if (S_ISDIR(entry[i].mode))
dirmask |= 1ul << i;
+ e = &entry[i];
}
if (!mask)
break;
- ret = info->fn(n, mask, dirmask, entry, info);
- if (ret < 0) {
- error = ret;
- if (!info->show_all_errors)
- break;
+ interesting = prune_traversal(e, info, &base, interesting);
+ if (interesting < 0)
+ break;
+ if (interesting) {
+ ret = info->fn(n, mask, dirmask, entry, info);
+ if (ret < 0) {
+ error = ret;
+ if (!info->show_all_errors)
+ break;
+ }
+ mask &= ret;
}
- mask &= ret;
ret = 0;
for (i = 0; i < n; i++)
if (mask & (1ul << i))
@@ -395,6 +421,7 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
for (i = 0; i < n; i++)
free_extended_entry(tx + i);
free(tx);
+ strbuf_release(&base);
return error;
}
diff --git a/tree-walk.h b/tree-walk.h
index 39524b7..0089581 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -44,6 +44,7 @@ struct traverse_info {
struct traverse_info *prev;
struct name_entry name;
int pathlen;
+ struct pathspec *pathspec;
unsigned long conflicts;
traverse_callback_t fn;
diff --git a/unpack-trees.c b/unpack-trees.c
index cc616c3..670b464 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -444,6 +444,7 @@ static int traverse_trees_recursive(int n, unsigned long dirmask,
newinfo = *info;
newinfo.prev = info;
+ newinfo.pathspec = info->pathspec;
newinfo.name = *p;
newinfo.pathlen += tree_entry_len(p->path, p->sha1) + 1;
newinfo.conflicts |= df_conflicts;
@@ -1040,6 +1041,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
info.fn = unpack_callback;
info.data = o;
info.show_all_errors = o->show_all_errors;
+ info.pathspec = o->pathspec;
if (o->prefix) {
/*
diff --git a/unpack-trees.h b/unpack-trees.h
index 7998948..5e432f5 100644
--- a/unpack-trees.h
+++ b/unpack-trees.h
@@ -52,6 +52,7 @@ struct unpack_trees_options {
const char *prefix;
int cache_bottom;
struct dir_struct *dir;
+ struct pathspec *pathspec;
merge_fn_t fn;
const char *msgs[NB_UNPACK_TREES_ERROR_TYPES];
/*
^ permalink raw reply related
* [PATCH] do not require filters to consume stdin
From: Joey Hess @ 2011-08-29 20:31 UTC (permalink / raw)
To: git
A clean filter that uses %f to examine a file may not need to consume
the entire file content from stdin every time it's run, due to caching
or other optimisations to support large files.
Ignore the SIGPIPE that may result when writing to the filter
if it exits without consuming stdin, and do not check that all
content is sent to it. The filter is still required to exit
successfully, so a crash in the filter should still be handled
correctly.
---
There has been discussion before about using clean and smudge filters
with %f to handle big files in git, with the file content stored outside
git somewhere. A simplistic clean filter for large files could look
like this:
#!/bin/sh
file="$1"
ln -f $file ~/.big/$file
echo $file
But trying to use this will fail on truely large files. For example:
$ ls -l sorta.huge
-rw-r--r-- 3 joey joey 524288000 Aug 29 15:19 sorta.huge
$ git add sorta.huge
broken pipe git add sorta.huge
$ echo $?
141
The SIGPIPE occurs because git expects the clean filter to read
the full file content from stdin. (Although if the content is small
enough, a SIGPIPE may not occur.) So the clean filter needs to
look like this:
#!/bin/sh
file="$1"
cat >/dev/null
ln -f $file ~/.big/$file
echo $file
But this means much more work has to be done whenever the clean filter
is run. Including every time git status is run. So it's currently
impractical to use clean/smudge filters like this for large files.
This patch should close that gap and allow such filters to be developed.
convert.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/convert.c b/convert.c
index 416bf83..3d528c4 100644
--- a/convert.c
+++ b/convert.c
@@ -330,7 +330,7 @@ static int filter_buffer(int in, int out, void *data)
*/
struct child_process child_process;
struct filter_params *params = (struct filter_params *)data;
- int write_err, status;
+ int write_err = 0, status;
const char *argv[] = { NULL, NULL };
/* apply % substitution to cmd */
@@ -360,9 +360,11 @@ static int filter_buffer(int in, int out, void *data)
if (start_command(&child_process))
return error("cannot fork to run external filter %s", params->cmd);
- write_err = (write_in_full(child_process.in, params->src, params->size) < 0);
+ signal(SIGPIPE, SIG_IGN);
+ write_in_full(child_process.in, params->src, params->size);
if (close(child_process.in))
write_err = 1;
+ signal(SIGPIPE, SIG_DFL);
if (write_err)
error("cannot feed the input to external filter %s", params->cmd);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2] unpack-trees: divert check_updates() output via update_progress()
From: sdaoden @ 2011-08-29 20:17 UTC (permalink / raw)
To: git; +Cc: Steffen Daode Nurpmeso
In-Reply-To: <cover.1314647163.git.sdaoden@gmail.com>
From: Steffen Daode Nurpmeso <sdaoden@gmail.com>
The progress shown by check_updates() yet always printed
"Checking out files", even if basically files were only
unlinked.
This commit diverts that into "Updating working tree:" plus the
actual action which currently is performed (i.e. "removing
files" or "checking out files").
Inspired-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Steffen Daode Nurpmeso <sdaoden@gmail.com>
---
unpack-trees.c | 30 +++++++++++++++++++++++-------
1 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index cc616c3..95cd8a6 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -178,26 +178,34 @@ static void unlink_entry(struct cache_entry *ce)
static struct checkout state;
static int check_updates(struct unpack_trees_options *o)
{
- unsigned cnt = 0, total = 0;
+ unsigned rm_cnt, co_cnt, cnt;
struct progress *progress = NULL;
struct index_state *index = &o->result;
int i;
int errs = 0;
if (o->update && o->verbose_update) {
- for (total = cnt = 0; cnt < index->cache_nr; cnt++) {
+ rm_cnt = co_cnt = 0;
+ for (cnt = 0; cnt < index->cache_nr; cnt++) {
struct cache_entry *ce = index->cache[cnt];
- if (ce->ce_flags & (CE_UPDATE | CE_WT_REMOVE))
- total++;
+ switch (ce->ce_flags & (CE_UPDATE | CE_WT_REMOVE)) {
+ case CE_UPDATE:
+ co_cnt++;
+ break;
+ default:
+ rm_cnt++;
+ break;
+ }
}
- progress = start_progress_delay("Checking out files",
- total, 50, 1);
+ progress = start_progress_delay("Updating work tree: "
+ "removing files",
+ rm_cnt, 64, 1);
cnt = 0;
}
-
if (o->update)
git_attr_set_direction(GIT_ATTR_CHECKOUT, &o->result);
+
for (i = 0; i < index->cache_nr; i++) {
struct cache_entry *ce = index->cache[i];
@@ -211,6 +219,13 @@ static int check_updates(struct unpack_trees_options *o)
remove_marked_cache_entries(&o->result);
remove_scheduled_dirs();
+ if (co_cnt > 0) {
+ update_progress(progress,
+ "Updating work tree: checking out files",
+ co_cnt);
+ cnt = 0;
+ }
+
for (i = 0; i < index->cache_nr; i++) {
struct cache_entry *ce = index->cache[i];
@@ -222,6 +237,7 @@ static int check_updates(struct unpack_trees_options *o)
}
}
}
+
stop_progress(&progress);
if (o->update)
git_attr_set_direction(GIT_ATTR_CHECKIN, NULL);
--
1.7.7.rc0.dirty
^ permalink raw reply related
* [PATCH 1/2] progress: add update_progress()
From: sdaoden @ 2011-08-29 20:17 UTC (permalink / raw)
To: git; +Cc: Steffen Daode Nurpmeso
In-Reply-To: <cover.1314647163.git.sdaoden@gmail.com>
From: Steffen Daode Nurpmeso <sdaoden@gmail.com>
Sometimes the task which is tracked via progress is splitted
into two parts, e.g. check_updates() in unpack_trees.c updates
the working tree by first removing files, followed by checking
out files. Whereas it is possible to simply recreate a progress
reporter, it's easier to simply call in to update the state of
the yet existing one.
Inspired-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Steffen Daode Nurpmeso <sdaoden@gmail.com>
---
progress.c | 15 +++++++++++++++
progress.h | 2 ++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/progress.c b/progress.c
index 3971f49..c86f83f 100644
--- a/progress.c
+++ b/progress.c
@@ -234,6 +234,21 @@ struct progress *start_progress(const char *title, unsigned total)
return start_progress_delay(title, total, 0, 0);
}
+void update_progress(struct progress *progress, const char *title,
+ unsigned total)
+{
+ if (!progress)
+ return;
+ progress->title = title;
+ progress->total = total;
+ progress->last_value = -1;
+ progress->last_percent = -1;
+ if (progress->delay < 0)
+ progress->delay = 0;
+ clear_progress_signal();
+ set_progress_signal();
+}
+
void stop_progress(struct progress **p_progress)
{
stop_progress_msg(p_progress, "done");
diff --git a/progress.h b/progress.h
index 611e4c4..eed5b58 100644
--- a/progress.h
+++ b/progress.h
@@ -8,6 +8,8 @@ int display_progress(struct progress *progress, unsigned n);
struct progress *start_progress(const char *title, unsigned total);
struct progress *start_progress_delay(const char *title, unsigned total,
unsigned percent_treshold, unsigned delay);
+void update_progress(struct progress *progress, const char *title,
+ unsigned total);
void stop_progress(struct progress **progress);
void stop_progress_msg(struct progress **progress, const char *msg);
--
1.7.7.rc0.dirty
^ permalink raw reply related
* [PATCH 0/2 RFC] Add update_progress(), divert checkout messages
From: sdaoden @ 2011-08-29 20:14 UTC (permalink / raw)
To: git; +Cc: Steffen Daode Nurpmeso
In-Reply-To: <7vaaau9hso.fsf@alter.siamese.dyndns.org>
From: Steffen Daode Nurpmeso <sdaoden@gmail.com>
Whereas only syntactic sugar, i think it's a bit odd that during
a checkout which mostly removes files the git-checkout progress
displays "Checking out files" all of the time.
There are two solutions to this: either simply change that string
to "Updating working tree", which is acceptable to anybody at
anytime. Or divert what progress reports to the actual action
which is currently performed. This series tries to achieve the
latter.
But maybe progress should instead be extended that it could handle
a situation like the following directly. I.e., offer an
additional start_parted_progress() series, or extend the current
one with an additional "signed parted" argument. That
update_progress() could then instead be named
progress_change_part() or whatever. ?
Updating work tree: removing files (x/y [xy%]) total%
Main-Title Action-title Action-cnt
Steffen Daode Nurpmeso (2):
progress: add update_progress()
unpack-trees: divert check_updates() output via update_progress()
progress.c | 15 +++++++++++++++
progress.h | 2 ++
unpack-trees.c | 30 +++++++++++++++++++++++-------
3 files changed, 40 insertions(+), 7 deletions(-)
--
1.7.7.rc0.dirty
^ permalink raw reply
* [PATCH 4/4] Document negated forms of format-patch --to --cc --add-headers
From: Thomas Rast @ 2011-08-29 20:10 UTC (permalink / raw)
To: git; +Cc: Stephen Boyd, Junio C Hamano
In-Reply-To: <bbfb7190ca0125798417f57f4d33b5443257e478.1314648438.git.trast@student.ethz.ch>
The negated forms introduced in c426003 (format-patch: add --no-cc,
--no-to, and --no-add-headers, 2010-03-07) were not documented
anywhere. Add them to the descriptions of the positive forms.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
I can't help but notice that the options aren't symmetric:
--no-add-header clears more than just the options added by
--add-header. It's probably too late to change though.
Documentation/git-format-patch.txt | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index d13c9b2..6ea9be7 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -166,15 +166,22 @@ will want to ensure that threading is disabled for `git send-email`.
--to=<email>::
Add a `To:` header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
+ The negated form `--no-to` discards all `To:` headers added so
+ far (from config or command line).
--cc=<email>::
Add a `Cc:` header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
+ The negated form `--no-cc` discards all `Cc:` headers added so
+ far (from config or command line).
--add-header=<header>::
Add an arbitrary header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
- For example, `--add-header="Organization: git-foo"`
+ For example, `--add-header="Organization: git-foo"`.
+ The negated form `--no-add-header` discards *all* (`To:`,
+ `Cc:`, and custom) headers added so far from config or command
+ line.
--cover-letter::
In addition to the patches, generate a cover letter file
--
1.7.7.rc0.370.gdcae57
^ permalink raw reply related
* [PATCH 3/4] t4014: "no-add-headers" is actually called "no-add-header"
From: Thomas Rast @ 2011-08-29 20:10 UTC (permalink / raw)
To: git; +Cc: Stephen Boyd, Junio C Hamano
In-Reply-To: <bbfb7190ca0125798417f57f4d33b5443257e478.1314648438.git.trast@student.ethz.ch>
Since c426003 (format-patch: add --no-cc, --no-to, and
--no-add-headers, 2010-03-07) the tests have checked for an option
called --no-add-headers introduced by letting the user negate
--add-header.
However, the parseopt machinery does not automatically pluralize
anything, so it is in fact called --no-add-header.
Since the option never worked, is not documented anywhere, and
implementing an actual --no-add-headers would lead to silly code
complications, we just adapt the test to the code.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/t4014-format-patch.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index a45d4fb..5cbc066 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -219,11 +219,11 @@ test_expect_success '--no-cc overrides config.cc' '
! grep "^Cc: C. E. Cipient <rcipient@example.com>\$" patch12
'
-test_expect_failure '--no-add-headers overrides config.headers' '
+test_expect_success '--no-add-header overrides config.headers' '
git config --replace-all format.headers \
"Header1: B. E. Cipient <rcipient@example.com>" &&
- git format-patch --no-add-headers --stdout master..side |
+ git format-patch --no-add-header --stdout master..side |
sed -e "/^\$/q" >patch13 &&
check_patch patch13 &&
! grep "^Header1: B. E. Cipient <rcipient@example.com>\$" patch13
--
1.7.7.rc0.370.gdcae57
^ permalink raw reply related
* [PATCH 2/4] t4014: invoke format-patch with --stdout where intended
From: Thomas Rast @ 2011-08-29 20:10 UTC (permalink / raw)
To: git; +Cc: Stephen Boyd, Junio C Hamano
In-Reply-To: <bbfb7190ca0125798417f57f4d33b5443257e478.1314648438.git.trast@student.ethz.ch>
The test wrote something along the lines of 0001-foo.patch to output,
which of course never contained a signature. Luckily the tested
behaviour is actually present.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/t4014-format-patch.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index b4d4207..a45d4fb 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -698,8 +698,8 @@ test_expect_success 'format-patch --no-signature supresses signatures' '
! grep "^-- \$" output
'
-test_expect_failure 'format-patch --signature="" supresses signatures' '
- git format-patch --signature="" -1 >output &&
+test_expect_success 'format-patch --signature="" supresses signatures' '
+ git format-patch --stdout --signature="" -1 >output &&
check_patch output &&
! grep "^-- \$" output
'
--
1.7.7.rc0.370.gdcae57
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox