definitely
good for a heuristic used for improving performance (meaning as an
ordering criterion for a commit priority queue). The problem is how
much I should cater for graceful behavior for the cases where it's not.
Does git do any actual checks before pushing?
--
David Kastrup
--
To unsubscribe
Jeff King p...@peff.net writes:
On Wed, Jan 15, 2014 at 11:37:08AM +0100, David Kastrup wrote:
The question is what guarantees I have with regard to the commit date of
a commit in relation to that of its parent commits:
a) none
b) commitdate(child) = commitdate(parent)
c) commitdate
attributed to me tend to go
_down_ quite regularly in the time from starting the report to sending
it out. Which might also cause me to overlook a particularly
selfpraiseworthy item.
Not sure how feasible it would be to arrive at a stable and
complementary set of --since/--until.
--
David Kastrup
Andreas Krey a.k...@gmx.de writes:
On Wed, 15 Jan 2014 12:40:29 +, David Kastrup wrote:
...
With a single root, depth helps a lot. When looking for a common
parent of a number of commits, you first shorten all ancestries to the
same size and then you can look for the point
.
3) Is this a bug?
No.
--
David Kastrup
--
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
the change...
... that you made here.
Unsurprisingly, the net effect is no change in that area -- and git diff
tells you exactly that.
Looks like I should have looked into the diffs before making my guess
about what happened.
--
David Kastrup
--
To unsubscribe from this list: send the line
, that's a personal preference
setting in that it is useless for those who never use Emacs (the file
can be written/edited using M-x add-dir-local-variable RET). It's still
providing significant convenience for a number of users while touching
only a single file.
--
David Kastrup
--
To unsubscribe from
: their main purpose is to get some cruft out of the way so
that the heavy-duty patches actually dealing with the performance
sinks will be a bit more focused.
And of course, getting the ball rolling again.
David Kastrup (2):
builtin/blame.c: struct blame_entry does not need a prev link
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.
---
builtin/blame.c | 25 -
1 file changed, 8
---
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
David Kastrup d...@gnu.org writes:
This is more a warmup than anything else: I'm actually doing a quite
more involved rewrite of git-blame right now. But it's been a long
time since I sent patches for Git, so I'm starting out with something
reasonably uncontroversial.
Ping?
Now I might
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
Now I might have sent at an unopportune time: blame.c is mostly
attributed to Junio who seems to have been a few days absent now.
I also have seen quite a few mails and patch submissions on the list go
basically unanswered
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
So my understanding is that when we are talking about _significant_
additions to builtin/blame.c (the current patches don't qualify as such
really) that
a) builtin/blame.c is licensed under GPLv2
b) significant contributions
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Any idea how this could be made more clear? E.g., maybe we should
bite the bullet and add a line to all source files that don't already
state a license:
/*
* License
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
and contrib. The README file states
Git is an Open Source project covered by the GNU General Public
License version 2 (some parts of it are under different licenses,
compatible with the GPLv2). It was originally
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
So my understanding is that when we are talking about _significant_
additions to builtin/blame.c (the current patches don't qualify as such
really) that
a) builtin/blame.c is licensed
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
---
Thanks. At some point during its development I must have thought
that having it as a dual-linked list may make it easier when we have
to split a block into pieces, but it seems that split_overlap() does
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
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
Same series as sent previously, just signed off this time.
David Kastrup (2):
builtin/blame.c: struct blame_entry does not need a prev link
Eliminate same_suspect function in builtin/blame.c
builtin/blame.c | 38 ++
1 file changed, 10 insertions(+), 28
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
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
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
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
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
blame --reverse on the Git code
base for figuring out anything of relevance?
Since I am in the process of rewriting git-blame, of course I want to
verify that everything works, but while I achieve the same results, they
seem fabulously useless before and after my rewrite.
--
David Kastrup
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
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
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
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
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
The previous implementation uses a sorted linear list of struct
blame_entry in a struct scoreboard for organizing all partial
is implemented in unexpected ways) is frowned upon in the Git
codebase or not.
--
David Kastrup
--
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
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Hi, I am wondering if I may compare pointers with that have been
created using different calls of malloc.
The C standard does not allow this (inequalities are only allowed for
pointers into the same structure
brian m. carlson sand...@crustytoothpaste.net writes:
On Wed, Jan 29, 2014 at 09:52:45PM +0100, David Kastrup wrote:
Junio C Hamano gits...@pobox.com writes:
Hmm... if you were to implement a set of pointers in such a way that
you can cheaply tell if an unknown pointer belongs to that set
was supposed to produce *exactly* the branch-B version?
No? It will produce the branch-B version in the conflicted area, but
that does not mean that conflict resolution might not have been done
outside of that area.
--
David Kastrup
--
To unsubscribe from this list: send the line unsubscribe git
a notice along the line The performance of git blame has been
significantly improved by David Kastrup d...@gnu.org. If this affects
you, consider contributing to his reimbursement. would of course also
be welcome.
Ok, this should be about covering the bad and the ugly. I'm still
working on the -C
-commit. If it's going to be
per-commit, a footer line would be less obtrusive than a whole sentence.
But it would seem that there's no rule/standard here.
Thanks
--
David Kastrup
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
not. There is a big hole in the indexing of the Google
News history that was taken over from what once was Dejanews. Putting
the information regarding prospective licensing close to the actual
source seems like a smart move.
At any rate, if there is no stock procedure for that, that's it.
--
David
definitely open viable options for dealing with mirrors and/or
repository migrations in general.
--
David Kastrup
--
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
- 1] == '/' || path[wtlen] == '\0')
Is wtlen guaranteed to be nonzero?
--
David Kastrup
--
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
John Keeping j...@keeping.me.uk writes:
On Sun, Feb 02, 2014 at 12:19:43PM +0100, David Kastrup wrote:
Duy Nguyen pclo...@gmail.com writes:
The file is for past commits only.
New commits can contain these info in their messages.
If it's not forgotten. Experience shows that things
Duy Nguyen pclo...@gmail.com writes:
On Sun, Feb 2, 2014 at 6:19 PM, David Kastrup d...@gnu.org wrote:
Since Git has a working facility for references that is catered to do
exactly this kind of mapping and already _does_, it seems like a
convenient path to explore.
It will not scale. If you
Andreas Ericsson a...@op5.se writes:
On 2014-01-31 14:04, David Kastrup wrote:
I'm still in the process of finishing the rewrite of the builtin/blame.c
internals. Now there are various questions regarding the final patch
proposals and commit messages.
Point 1) signing off implies
management.
The second performance patch is not likely to measurably affect
overall performance. Avoiding irrelevant iterations might make
debugging more pleasant, however.
David Kastrup (5):
builtin/blame.c: struct blame_entry does not need a prev link
Eliminate same_suspect function in builtin
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
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
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
---
builtin/blame.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index e881b6e..0188115 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1435,7 +1435,8 @@ static void pass_blame(struct scoreboard *sb, struct
origin *origin, int
---
builtin/blame.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 0188115..80345db 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -928,9 +928,12 @@ static int pass_blame_to_parent(struct scoreboard *sb,
/*
when doing git
push. The server administrator will be rather glad that the clients'
configuration variables don't affect his server's operation.
--
David Kastrup
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
chris j...@hotmail.com writes:
David Kastrup dak at gnu.org writes:
chris jugg at hotmail.com writes:
Duy Nguyen pclouds at gmail.com writes:
On Tue, Feb 4, 2014 at 9:20 AM, chris jugg at hotmail.com wrote:
$ git push origin next
Counting objects: 56, done.
Delta compression using
these mailing list discussions.
The second benefit could likely be achieved by displaying Server
unreachable... retrying... instead of reporting about git gc.
--
David Kastrup
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for sizeof(int *) sizeof(int), admittedly unlikely.
Signed-off-by: David Kastrup d
Whitespace error in line 1778. Should I be reposting?
--
David Kastrup
--
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
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Whitespace error in line 1778. Should I be reposting?
Heh, let me try to clean it up first and then repost for your
review.
Thanks.
-- 8 --
From: David Kastrup d
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Anybody know offhand what I should be including here? It looks like Git
has some fallback definitions of its own, so it's probably not just
string.h I should include?
In general, no *.c files outside
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for sizeof(int *) sizeof(int), admittedly unlikely.
Signed-off-by: David Kastrup d
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for sizeof(int *) sizeof(int), admittedly unlikely.
Signed-off-by: David Kastrup d
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Ok, I now wrote
for (p = buf;; num++, p++) {
p = memchr(p, '\n', end - p);
if (!p)
break;
}
Looks still wrong (perhaps this is a taste issue
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
so something like
for (p = buf; p end; p++) {
p = find the end of this line
if (!p)
break;
num++;
}
perhaps?
Would crash on incomplete
in my mouth.
And I don't want any code marked as written by me that does not
correspond to what I'd be willing to write. So please make sure to put
any rewrites in a separate commit with different authorship.
Thanks
--
David Kastrup
--
To unsubscribe from this list: send the line unsubscribe
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
Junio C Hamano gits...@pobox.com writes:
which I think is the prevalent style in our codebase. The same for
the other loop we see in the new code below.
- avoid assignments in conditionals when you do not have
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
It's snake oil making debugging harder.
OK, that is a sensible argument.
This was fun ;-)
At the expense of seriously impacting my motivation to do any further
code cleanup on Git.
Well, I said it was fun
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
It's snake oil making debugging harder.
OK, that is a sensible argument.
This was fun ;-)
At the expense of seriously impacting my motivation to do any further
code cleanup on Git.
Well, I said it was fun
are shown in
reverse chronological order.
git log --graph can help with getting a better picture.
--
David Kastrup
--
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
If we are calling xrealloc on every single line, the least we can do
is get the right allocation size.
Signed-off-by: David Kastrup d...@gnu.org
---
This should be less contentious than the patch in
URL:http://permalink.gmane.org/gmane.comp.version-control.git/241561,
Message-ID: 1391550392-17118
David Kastrup d...@gnu.org writes:
If we are calling xrealloc on every single line, the least we can do
is get the right allocation size.
Signed-off-by: David Kastrup d...@gnu.org
---
This should be less contentious than the patch in
URL:http://permalink.gmane.org/gmane.comp.version
: a shallow clone is not incomplete: the
cloning process ran to completion.
I don't really like 'gesondert eingehängt', how about 'transplantiert'
instead?
I suggest using the actual translation here as it is perfectly fitting
for both literal and figurative meaning: aufgepfropft.
--
David Kastrup
Thomas Rast t...@thomasrast.ch writes:
David Kastrup d...@gnu.org writes:
Thomas Rast t...@thomasrast.ch writes:
I don't really like 'gesondert eingehängt', how about 'transplantiert'
instead?
I suggest using the actual translation here as it is perfectly fitting
for both literal
Ralf Thielow ralf.thie...@gmail.com writes:
2014-02-08 20:22 GMT+01:00 David Kastrup d...@gnu.org:
verberge keine aufgepfropften Commits seems much more in the spirit of
the original terminology. verbirgt keine Commits mit künstlichen
Vorgängern is plainly wrong anyway since
+1629,8 @@ msgid
Do not touch the line above.\n
Everything below will be removed.
msgstr
+Ändern Sie nicht die Zeile oberhalb.\n
+Alles unterhalb wird entfernt.
That's not even grammatical.
Ändern Sie nicht die obige Zeile.
Alles unterhalb von ihr wird entfernt.
--
David Kastrup
by tried and true Git
developers. So feel free to roll your own patch here: it's not like
this one has any copyrightable content in it.
--
David Kastrup
--
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
.
Is there a reason there are no prewired recipes or advice for using
gprof on git? Is there a way to get the work done, namely seeing the
actual distribution of call times (rather than iterations) using gcov so
that this is not necessary?
--
David Kastrup
--
To unsubscribe from this list: send
Duy Nguyen pclo...@gmail.com writes:
On Tue, Feb 11, 2014 at 6:17 PM, David Kastrup d...@gnu.org wrote:
Looking in the Makefile, I just find support for coverage reports using
gcov. Whatever is there with profile in it seems to be for
profile-based compilation rather than using gprof.
Now
John Keeping j...@keeping.me.uk writes:
On Tue, Feb 11, 2014 at 03:41:55PM +0100, David Kastrup wrote:
Duy Nguyen pclo...@gmail.com writes:
Would perf help? No changes required, and almost no overhead, I think.
Not useful. It would be probably nice for nailing down the performance
gains
David Kastrup d...@gnu.org writes:
John Keeping j...@keeping.me.uk writes:
On Tue, Feb 11, 2014 at 03:41:55PM +0100, David Kastrup wrote:
Duy Nguyen pclo...@gmail.com writes:
Would perf help? No changes required, and almost no overhead, I think.
Not useful. It would be probably nice
?
--
David Kastrup
--
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
Johannes Sixt j.s...@viscovery.net writes:
Am 2/12/2014 13:55, schrieb David Kastrup:
Johannes Sixt j.s...@viscovery.net writes:
Running test suite of 'next' on Windows fails in t5310-pack-bitmaps with
the following symptoms. I haven't followed the topic. Have there been
patches floating
Making a single preparation run for counting the lines will avoid memory
fragmentation. Also, fix the allocated memory size which was wrong
when sizeof(int *) != sizeof(int), and would have been too small
for sizeof(int *) sizeof(int), admittedly unlikely.
Signed-off-by: David Kastrup d
that don't really demonstrate well just how bad the behavior might
become and which code passages are dominant regarding the quadratic
behavior?
--
David Kastrup
consider dedicated hardware running on a native Linux
file system.
--
David Kastrup
--
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
a recommendation for a less labor-intensive way to do
this in emacs, I'd be very grateful.
C-c . RET linux RET before entering any changes.
--
David Kastrup
--
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
Stefan Zager sza...@chromium.org writes:
On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup d...@gnu.org wrote:
Really, give the above patch a try. I am taking longer to finish it
than anticipated (with a lot due to procrastination but that is,
unfortunately, a large part of my workflow
Mike Hommey m...@glandium.org writes:
On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote:
Stefan Zager sza...@chromium.org writes:
On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup d...@gnu.org wrote:
Really, give the above patch a try. I am taking longer to finish it
than
David Kastrup d...@gnu.org writes:
Again, that's with an SSD and ext4 filesystem on GNU/Linux, and there
are no improvements in system time (I/O) except for patch 4 of the
series which helps perhaps 20% or so.
So the benefits of the patch will come into play mostly for big, bad
files
a decade
because some people suggest it might be time to drop the MSDOS port
and/or the associated restriction of having filenames be unique in the
8+3 naming scheme.
--
David Kastrup
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
code from shell to C.
In the context of programming tasks, if there is still time is a prime
candidate for the successful application of branch prediction.
--
David Kastrup
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
proposed by the Git developers?
This definitely should not be we'll think about it if and when that
project is finished material.
--
David Kastrup
--
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
reappearing again and again, so it must be
something systematic.
You probably should check how $new_branch comes about. Also, once a
directory refs/heads/refs/heads exists, refs/heads/$new_branch may
possibly be resolved as a branch with the name refs/heads/$new_branch.
--
David Kastrup
.
--
David Kastrup
--
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
). This is the
final step.
Sounds like I'm, uh, somewhat late in the game. More likely than not
you've taken care of that aspect long ago. Just thought I'd mention it.
--
David Kastrup
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Duy Nguyen pclo...@gmail.com writes:
On Sat, Feb 15, 2014 at 3:23 PM, David Kastrup d...@gnu.org wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Long story short, we wanted globbing wildcard ** so I ripped
wildmatch library from rsync to do it.
Since version 3.0.0, rsync is GPLv3
Thomas Rast t...@thomasrast.ch writes:
David Kastrup d...@gnu.org writes:
This definitely should not be we'll think about it if and when that
project is finished material.
Yes, all of this is true. However, you are painting a big devil on
the wall.
[...]
Your scenario above mostly
When comparing two branches, decorating the flat diff with the
respectively responsible commits seems like it would be nice to do/have
(the blame on the identical parts, in contrast, is not really
interesting). Is there any tool that provides something like that?
--
David Kastrup
Thomas Rast t...@thomasrast.ch writes:
David Kastrup d...@gnu.org writes:
Looking in the Makefile, I just find support for coverage reports using
gcov. Whatever is there with profile in it seems to be for
profile-based compilation rather than using gprof.
[...]
Is there a reason
as
returning an int at all? And why give it the same name as the macro
(risking human/computer confusion and requiring an explicit #undef for
the definition or was that declaration?) instead of
config_error_nonbool_internal or whatever else?
--
David Kastrup
--
To unsubscribe from this list: send the line
Thomas Rast t...@thomasrast.ch writes:
David Kastrup d...@gnu.org writes:
Thomas Rast t...@thomasrast.ch writes:
David Kastrup d...@gnu.org writes:
Looking in the Makefile, I just find support for coverage reports using
gcov. Whatever is there with profile in it seems to be for
profile
Thomas Rast t...@thomasrast.ch writes:
David Kastrup d...@gnu.org writes:
When comparing two branches, decorating the flat diff with the
respectively responsible commits seems like it would be nice to do/have
(the blame on the identical parts, in contrast, is not really
interesting
Jeff King p...@peff.net writes:
On Sun, Feb 16, 2014 at 05:22:45PM +0100, David Kastrup wrote:
config.c:#undef config_error_nonbool
config.c:int config_error_nonbool(const char *var)
You could always look in the commit history:
$ git log -S'#define config_error_nonbool' cache.h
with
the delta coding of the normal unpacked operation (there are a few
older commits from me on that).
--
David Kastrup
--
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
1 - 100 of 296 matches
Mail list logo
