Junio C Hamano writes:
> - Nobody has time or energy to go through 140+ patches in one go,
>with enough concentration necessary to do so without making
>mistakes (this applies to yourself, too---producing mechanical
>replacement is a no-cost thing, finding mistakes in mechanical
>
About half of test_perf() is boilerplate, and half is
actually related to running the perf test. Let's split it
into two functions, so that we can reuse the boilerplate in
future commits.
Signed-off-by: Jeff King
---
t/perf/perf-lib.sh | 61 +++---
A server with bitmapped packs can serve a clone very
quickly. However, fetches are not necessarily made any
faster, because we spend a lot less time in object traversal
(which is what bitmaps help with) and more time finding
deltas (because we may have to throw out on-disk deltas if
the client does
[tl;dr the patch is the same as before, but there is a script to measure
its effects; please try it out on your repos]
This is a continuation of the discussion here:
http://thread.gmane.org/gmane.comp.version-control.git/239647
I'll summarize the story so far.
Basically, the problem is
The main objective of scripts in the perf framework is to
run "test_perf", which measures the time it takes to run
some operation. However, it can also be interesting to see
the change in the output size of certain operations.
This patch introduces test_size, which records a single
numeric output
This will let us reuse the code when we add new values to
aggregate besides times.
Signed-off-by: Jeff King
---
t/perf/aggregate.perl | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/t/perf/aggregate.perl b/t/perf/aggregate.perl
index 15f7fc1..690cd8c 10
When we do a bitmap walk, we save the result, which
represents (WANTs & ~HAVEs); i.e., every object we care
about visiting in our walk. However, we throw away the
haves bitmap, which can sometimes be useful, too. Save it
and provide an access function so code which has performed a
walk can query it
When we calculate the "wants" and "haves" for a pack, we
only add the objects in the boundary commits as preferred
bases. However, we know that every object reachable from the
"haves" could be a preferred base.
We probably don't want to add these to our preferred base
list, because they would clog
On Wed, Mar 26, 2014 at 3:02 AM, Matthieu Moy
wrote:
> Junio C Hamano writes:
>
>> - Nobody has time or energy to go through 140+ patches in one go,
>>with enough concentration necessary to do so without making
>>mistakes (this applies to yourself, too---producing mechanical
>>replac
Am 25.03.2014 21:49, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> For the upcoming submodule test framework we often need to assert that an
>> empty directory exists in the work tree. Add the test_dir_is_empty()
>> function which asserts that the given argument is an empty directory.
>>
>>
Am 3/19/2014 1:46, schrieb sza...@chromium.org:
> This adds a Windows implementation of pread. Note that it is NOT
> safe to intersperse calls to read() and pread() on a file
> descriptor. According to the ReadFile spec, using the 'overlapped'
> argument should not affect the implicit position po
HI,
On Tue, Mar 25, 2014 at 9:18 PM, Junio C Hamano wrote:
>
> * cc/interpret-trailers (2014-03-07) 11 commits
> - Documentation: add documentation for 'git interpret-trailers'
> - trailer: add tests for commands in config file
> - trailer: execute command from 'trailer..command'
> - trailer:
2014-03-26 8:44 GMT+01:00 Eric Sunshine :
> On Wed, Mar 26, 2014 at 3:02 AM, Matthieu Moy
> wrote:
>> Junio C Hamano writes:
>>
>>> - Nobody has time or energy to go through 140+ patches in one go,
>>>with enough concentration necessary to do so without making
>>>mistakes (this applies t
On 03/26/2014 09:29 AM, Jens Lehmann wrote:
> Am 25.03.2014 21:49, schrieb Junio C Hamano:
>> Jens Lehmann writes:
>>
>>> For the upcoming submodule test framework we often need to assert that an
>>> empty directory exists in the work tree. Add the test_dir_is_empty()
>>> function which asserts th
On Mon, Feb 24, 2014 at 02:49:05AM -0500, Jeff King wrote:
> +# date is within 2^63-1, but enough to choke glibc's gmtime
> +test_expect_success 'absurdly far-in-future dates produce sentinel' '
> + commit=$(munge_author_date HEAD 99) &&
> + echo "Thu Jan 1 00:00:00 1970 +00
Junio C Hamano writes:
> Elia Pinto writes:
>
>> The Git CodingGuidelines prefer the $( ... ) construct for command
>> substitution instead of using the back-quotes, or grave accents (`..`).
>>
>> The backquoted form is the historical method for command substitution,
>> and is supported by POSIX
Junio C Hamano writes:
> Jens Lehmann writes:
>
>> For the upcoming submodule test framework we often need to assert that an
>> empty directory exists in the work tree. Add the test_dir_is_empty()
>> function which asserts that the given argument is an empty directory.
>>
>> Signed-off-by: Jens
David Kastrup writes:
> Junio C Hamano writes:
>
>> Elia Pinto writes:
>>
>>> The Git CodingGuidelines prefer the $( ... ) construct for command
>>> substitution instead of using the back-quotes, or grave accents (`..`).
>>>
>>> The backquoted form is the historical method for command substitut
On Mar 25, 2014, at 6:17 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Ævar Arnfjörð Bjarmason writes:
>>
1) Introduce '--borrow' to `git-fetch`. This would behave similarly
>>> to '--reference', except that it operates on a temporary basis, and
>>> does not assume that the re
Compared to v1, git-ls now does not accept ls-files options (previous
git-ls is more like an alias of ls-files). I want this because ls may
take a different set of options than ls-files. Most functionality is
shared so if you're not happy with ls, you can fall back to ls-files.
New alias options a
This is the second (and preferred) source for color information. This
will override $LS_COLORS.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 11 +++
ls_colors.c | 26 ++
2 files changed, 37 insertions(+)
diff --git a/Documentati
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 3 ++-
ls_colors.c | 8 +++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3fb754e..6bca55e 100644
--- a/Documentation/config.txt
+++ b/Do
Reusing color settings from $LS_COLORS could give a native look and
feel on file coloring.
This code is basically from coreutils.git [1], rewritten to fit Git.
As this is from GNU ls, the environment variable CLICOLOR is not
tested. It is to be decided later whether we should ignore $LS_COLORS
if
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-ls-files.txt | 9 +
builtin/ls-files.c | 38 +++---
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index
Buffering so that we can manipulate the strings (e.g. coloring)
further before finally printing them.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/ls-files.c | 48 +++-
1 file changed, 35 insertions(+), 13 deletions(-)
diff --git a/builtin/ls-files
This is more user friendly version of ls-files:
* it's automatically colored and columnized
* it refreshes the index like all porcelain commands
* it defaults to non-recursive behavior like ls
* :(glob) is on by default so '*.c' means a.c but not a/b.c, use
'**/*.c' for that.
* auto pager
Signe
This is a preparation step for the introduction of git-ls. "git ls"
has a different set of command line options, but it will eventually
call ls_files().
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/ls-files.c | 164 +++--
1 file changed, 85 inse
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-ls-files.txt | 7 +++
builtin/ls-files.c | 7 +++
2 files changed, 14 insertions(+)
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index cd52461..3c022eb 100644
--- a/Documentation/git-ls-
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-ls-files.txt | 6 ++
builtin/ls-files.c | 25 +
2 files changed, 31 insertions(+)
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 5c1b7f3..cd52461 100644
--- a/Do
Showing full index entry information is something for ls-files
only. The users of "git ls" may just want to know what entries are not
unmerged.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/ls-files.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/ls-files.c b/buil
Tthe new function is based on print_color_indicator() from commit
7326d1f1a67edf21947ae98194f98c38b6e9e527 in coreutils.git.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
color.h | 2 ++
ls_colors.c | 66 +
2 files changed, 68 insertions
Tag "H" (cached) is not shown though because it's usually the majority
and becomes noise. Not showing it makes the other tags stand out. -t
is on by default if more than one file category is selected.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-ls.txt | 6 ++
builtin/ls-files.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-ls.txt | 4
builtin/ls-files.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/Documentation/git-ls.txt b/Documentation/git-ls.txt
index 67ca522..10df6b0 100644
--- a/Documentation/git-ls.txt
+++ b/Documentation/git-ls.tx
When you mix different file types, with ls-files you may get separate
listing. For example, "ls-files -cm" will show file "abc" twice: one
as part of cached list, one of modified list. With "ls" (and this
patch) they will be in a single sorted list (easier for the eye).
Duplicate entries are also
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-ls.txt | 3 +++
builtin/ls-files.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/Documentation/git-ls.txt b/Documentation/git-ls.txt
index 10df6b0..0480c42 100644
--- a/Documentation/git-ls.txt
+++ b/Documentation/git-ls.txt
With the current show_files() "ls -tcm" will show
foo.c
M foo.c
The first item is redundant. If "foo.c" is modified, we know it's in
the cache. Introduce show_files_compact to do that because ls-files is
plumbing and scripts may already depend on current display behavior.
Another difference in
The index does not store directories explicitly (except submodules) so
we have to figure them out from file list. The function
show_directories() deliberately generates duplicate directories and
expects the previous patch to remove duplicates.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/ls-f
On Tue, Mar 25, 2014 at 6:54 AM, Junio C Hamano wrote:
> As a tangent, I have a suspicion that the current implementation may
> be wrong at the beginning of the string. Wouldn't it match " abc"
> and "abc", even though these two strings shouldn't match?
Wouldn't that be accomplished by just remo
Andrew Keller writes:
> On Mar 25, 2014, at 6:17 PM, Junio C Hamano wrote:
> ...
>>> I think that the standard practice with the existing toolset is to
>>> clone with reference and then repack. That is:
>>>
>>>$ git clone --reference git://over/there mine
>>>$ cd mine
>>>$ git rep
Jeff King writes:
> 2. When considering whether a delta can be reused, check the bitmaps
> to see if the client has the base. If so, allow reuse.
> ...
> The implementation I'm including here is the one I've shown before,
> which does (2). Part of the reason that I'm reposting it before lo
George Papanikolaou writes:
> On Tue, Mar 25, 2014 at 6:54 AM, Junio C Hamano wrote:
>> As a tangent, I have a suspicion that the current implementation may
>> be wrong at the beginning of the string. Wouldn't it match " abc"
>> and "abc", even though these two strings shouldn't match?
>
> Woul
On Wed, Mar 26, 2014 at 10:33:41AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > 2. When considering whether a delta can be reused, check the bitmaps
> > to see if the client has the base. If so, allow reuse.
> > ...
> > The implementation I'm including here is the one I've shown
On Wed, Mar 26, 2014 at 11:05:59AM +, Charles Bailey wrote:
> On Mon, Feb 24, 2014 at 02:49:05AM -0500, Jeff King wrote:
> > +# date is within 2^63-1, but enough to choke glibc's gmtime
> > +test_expect_success 'absurdly far-in-future dates produce sentinel' '
> > + commit=$(munge_author_dat
On Tue, Mar 25, 2014 at 10:45:01AM -0700, Junio C Hamano wrote:
> Kirill Smelkov writes:
>
> >> > static int tree_entry_pathcmp(struct tree_desc *t1, struct tree_desc
> >> > *t2)
> >> > {
> >> > struct name_entry *e1, *e2;
> >> > int cmp;
> >> >
> >> > +if (!t1->siz
On 03/24/2014 01:56 PM, Michael Haggerty wrote:
> +/*
> + * For backwards compatibility, accept an empty string for create's
> + * in binary mode to be equivalent to specifying zeros.
> + */
> +#define PARSE_SHA1_ALLOW_EMPTY 0x02
The comment should say "update's", not "create's".
-Brad
--
To un
On 03/24/2014 01:56 PM, Michael Haggerty wrote:
> Signed-off-by: Michael Haggerty
>
> t1400: Add a test of "update" with too few arguments
>
> Signed-off-by: Michael Haggerty
This looks like a stray squash message.
-Brad
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
On 03/24/2014 01:56 PM, Michael Haggerty wrote:
> Changes relative to v1:
>
> * Rename the functions associated with ref_transactions to be more
> reminiscent of database transactions:
>
> * create_ref_transaction() -> ref_transaction_begin()
> * free_ref_transaction() -> ref_transaction_ro
On 03/24/2014 01:56 PM, Michael Haggerty wrote:
> +void ref_transaction_update(struct ref_transaction *transaction,
> + const char *refname,
> + unsigned char *new_sha1, unsigned char *old_sha1,
> + int flags, int have_old);
[s
One of the tests in t4212 checks our behavior when we feed
gmtime a date so far in the future that it gives up and
returns NULL.
But some gmtime implementations just refuse to quit. They
soldier on, giving us a glimpse of a chilly October evening
some 160 million years in the future (and presumabl
Jeff King writes:
> On Wed, Mar 26, 2014 at 11:05:59AM +, Charles Bailey wrote:
>
>> On Mon, Feb 24, 2014 at 02:49:05AM -0500, Jeff King wrote:
>> > +# date is within 2^63-1, but enough to choke glibc's gmtime
>> > +test_expect_success 'absurdly far-in-future dates produce sentinel' '
>> > +
On Wed, Mar 26, 2014 at 11:58:49AM -0700, Junio C Hamano wrote:
> > Unlike the FreeBSD thing that René brought up, this is not a problem in
> > the code, but just in the test. So I think our options are basically:
> >
> > 1. Scrap the test as unportable.
> >
> > 2. Hard-code a few expected val
On Wed, Mar 26, 2014 at 9:48 AM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/git-ls-files.txt | 9 +
> builtin/ls-files.c | 38 +++---
> 2 files changed, 44 insertions(+), 3 deletions(-)
>
> diff --g
On Wed, Mar 26, 2014 at 9:48 AM, Nguyễn Thái Ngọc Duy wrote:
> Tthe new function is based on print_color_indicator() from commit
s/Tthe/The/
> 7326d1f1a67edf21947ae98194f98c38b6e9e527 in coreutils.git.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> color.h | 2 ++
> ls_colors.c | 66
> +
Jeff King writes:
> +cmp_one_of () {
> + for candidate in "$@"; do
Style ;-)
> + echo "$candidate" >expect &&
> + test_cmp expect actual &&
> + return 0
> + done
> + return 1
> +}
It actually may be easier to understand if you write a trivial cas
On Wed, Mar 26, 2014 at 9:48 AM, Nguyễn Thái Ngọc Duy wrote:
> Buffering so that we can manipulate the strings (e.g. coloring)
> further before finally printing them.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/ls-files.c | 48 +++-
> 1 fil
Am 26.03.2014 11:43, schrieb Michael Haggerty:
> On 03/26/2014 09:29 AM, Jens Lehmann wrote:
>> Am 25.03.2014 21:49, schrieb Junio C Hamano:
>>> Jens Lehmann writes:
t/test-lib-functions.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/t/test-lib-functions.sh
On Wed, Mar 26, 2014 at 12:18:25PM -0700, Junio C Hamano wrote:
> > + echo "$candidate" >expect &&
> > + test_cmp expect actual &&
> > + return 0
> > + done
> > + return 1
> > +}
>
> It actually may be easier to understand if you write a trivial case
> statement
On Wed, Mar 26, 2014 at 03:25:36PM -0400, Jeff King wrote:
> > The primary thing you wanted to achieve by the "gmtime gave us NULL,
> > let's substitute it with an arbitrary value to avoid dereferencing
> > the NULL" change was *not* that we see that same arbitrary value
> > comes out of the syste
On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
> That being said, is the AIX value actually right? I did not look closely
> at first, but just assumed that it was vaguely right. But:
>
> 99 / (86400 * 365)
>
> is something like 31 billion years in the future, not 16
On Wed, Mar 26, 2014 at 9:48 AM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/git-ls-files.txt | 6 ++
> builtin/ls-files.c | 25 +
> 2 files changed, 31 insertions(+)
>
> diff --git a/Documentation/git-ls-files.
On Wed, Mar 26, 2014 at 9:48 AM, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/git-ls-files.txt | 7 +++
> builtin/ls-files.c | 7 +++
> 2 files changed, 14 insertions(+)
>
> diff --git a/Documentation/git-ls-files.txt b/Documentation
On Tue, Mar 25, 2014 at 10:46:32AM -0700, Junio C Hamano wrote:
> Kirill Smelkov writes:
>
> > What are the downsides of "__" prefix by the way?
>
> Aren't these names reserved for compiler/runtime implementations?
Yes, but there are precedents when people don't obey it widely and
in practice e
On Wed, Mar 26, 2014 at 9:48 AM, Nguyễn Thái Ngọc Duy wrote:
> This is more user friendly version of ls-files:
>
> * it's automatically colored and columnized
> * it refreshes the index like all porcelain commands
> * it defaults to non-recursive behavior like ls
> * :(glob) is on by default so '*
On Wed, Mar 26, 2014 at 03:40:43PM -0400, Jeff King wrote:
> On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
>
> > That being said, is the AIX value actually right? I did not look closely
> > at first, but just assumed that it was vaguely right. But:
> >
> > 99 / (864
On Wed, Mar 26, 2014 at 08:36:18PM +, Charles Bailey wrote:
> On Wed, Mar 26, 2014 at 03:40:43PM -0400, Jeff King wrote:
> > On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
> >
> > > That being said, is the AIX value actually right? I did not look closely
> > > at first, but just a
On Wed, Mar 26, 2014 at 04:38:30PM -0400, Jeff King wrote:
>
> By the way, can you confirm that this is a 64-bit system? On a 32-bit
> system, we should be triggering different code paths (we fail at the
> strtoul level). Those should be checked by the previous tests, but I'd
> like to make sure.
Jeff King writes:
> On Wed, Mar 26, 2014 at 11:58:49AM -0700, Junio C Hamano wrote:
>
>> > Unlike the FreeBSD thing that René brought up, this is not a problem in
>> > the code, but just in the test. So I think our options are basically:
>> >
>> > 1. Scrap the test as unportable.
>> >
>> > 2.
Duy Nguyen writes:
> On Tue, Mar 25, 2014 at 08:52:13PM +0700, Duy Nguyen wrote:
>> On Mon, Mar 24, 2014 at 9:52 PM, Torsten Bögershausen wrote:
>> > Did I report that t1501 fails when there is a softlink in $PWD ?
>> > /home/tb/projects is a softlink to /disc5/projects/
>>
>> Yes you did and
On Wed, Mar 26, 2014 at 02:01:21PM -0700, Junio C Hamano wrote:
> > I don't know how important that is. This is such a minor feature that it
> > is not worth a lot of maintenance headache in the test. But I also do
> > not know if this is going to be the last report, or we will have a bunch
> > of
The fuzzy_matchlines() function is used when attempting to resurrect
a patch that is whitespace-damaged, or when applying a patch that
was produced against an old codebase to the codebase after
indentation change.
The patch may want to change a line "a_bc" ("_" is used throught
this description fo
On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
>
> That being said, is the AIX value actually right? I did not look closely
> at first, but just assumed that it was vaguely right. But:
>
> 99 / (86400 * 365)
>
> is something like 31 billion years in the future, not
Kirill Smelkov writes:
> On Tue, Mar 25, 2014 at 10:46:32AM -0700, Junio C Hamano wrote:
>> Kirill Smelkov writes:
>>
>> > What are the downsides of "__" prefix by the way?
>>
>> Aren't these names reserved for compiler/runtime implementations?
>
> Yes, but there are precedents when people don
On 03/26/2014 07:39 PM, Brad King wrote:
> On 03/24/2014 01:56 PM, Michael Haggerty wrote:
>> +void ref_transaction_update(struct ref_transaction *transaction,
>> +const char *refname,
>> +unsigned char *new_sha1, unsigned char *old_sha1,
>> +
On 03/26/2014 07:39 PM, Brad King wrote:
> On 03/24/2014 01:56 PM, Michael Haggerty wrote:
>> Changes relative to v1:
>>
>> * Rename the functions associated with ref_transactions to be more
>> reminiscent of database transactions:
>>
>> * create_ref_transaction() -> ref_transaction_begin()
>>
On Wed, Mar 26, 2014 at 09:22:27PM +, Charles Bailey wrote:
> On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
> >
> > That being said, is the AIX value actually right? I did not look closely
> > at first, but just assumed that it was vaguely right. But:
> >
> > 9
The lowercase() function from config.c and the xstrdup_tolower()
function from daemon.c can benefit from being moved to the same
place because this way the latter can use the former.
Also let's make them available globally so we can use them from
other places like trailer.c.
Signed-off-by: Christ
Read trailers from stdin, parse them and put the result into a doubly linked
list.
Signed-off-by: Christian Couder
---
trailer.c | 76 +++
1 file changed, 76 insertions(+)
diff --git a/trailer.c b/trailer.c
index 1871843..3993840 10064
This patch series implements a new command:
git interpret-trailers
and an infrastructure to process trailers that can be reused,
for example in "commit.c".
1) Rationale:
This command should help with RFC 822 style headers, called
"trailers", that are found at the end of commit messages.
Read the configuration to get trailer information, and then process
it and storing it in a doubly linked list.
The config information is stored in the list whose first item is
pointed to by:
static struct trailer_item *first_conf_item;
Signed-off-by: Christian Couder
---
trailer.c | 153 ++
This patch adds the process_trailers() function that
calls all the previously added processing functions
and then prints the results on the standard output.
Signed-off-by: Christian Couder
---
trailer.c | 49 +
trailer.h | 6 ++
2 files change
Let the user specify a command that will give on its standard output
the value to use for the specified trailer.
Signed-off-by: Christian Couder
---
trailer.c | 63 +++
1 file changed, 63 insertions(+)
diff --git a/trailer.c b/trailer.
Implement the logic to process trailers from stdin and arguments.
At the beginning trailers from stdin are in their own in_tok
doubly linked list, and trailers from arguments are in their own
arg_tok doubly linked list.
The lists are traversed and when an arg_tok should be "applied",
it is remove
Signed-off-by: Christian Couder
---
Documentation/git-interpret-trailers.txt | 123 +++
1 file changed, 123 insertions(+)
create mode 100644 Documentation/git-interpret-trailers.txt
diff --git a/Documentation/git-interpret-trailers.txt
b/Documentation/git-interpret-
Signed-off-by: Christian Couder
---
t/t7513-interpret-trailers.sh | 71 +++
1 file changed, 71 insertions(+)
diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
index 417a4f3..0a1f3b6 100755
--- a/t/t7513-interpret-trailers.sh
+++ b/
Parse the trailer command line arguments and put
the result into an arg_tok doubly linked list.
Signed-off-by: Christian Couder
---
trailer.c | 103 ++
1 file changed, 103 insertions(+)
diff --git a/trailer.c b/trailer.c
index b5a0943.
We will use a doubly linked list to store all information
about trailers and their configuration.
This way we can easily remove or add trailers to or from
trailer lists while traversing the lists in either direction.
Signed-off-by: Christian Couder
---
Makefile | 1 +
trailer.c | 49 +
This patch adds the "git interpret-trailers" command.
This command uses the previously added process_trailers()
function in trailer.c.
Signed-off-by: Christian Couder
---
.gitignore | 1 +
Makefile | 1 +
builtin.h| 1 +
builtin/interp
Signed-off-by: Christian Couder
---
t/t7513-interpret-trailers.sh | 336 ++
1 file changed, 336 insertions(+)
create mode 100755 t/t7513-interpret-trailers.sh
diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
new file mode 100755
Jeff King writes:
> Just looking at the 128-day case again, using bitmaps increased our
> server CPU time _and_ made a much bigger pack. This series not only
> fixes the CPU time regression, but it also drops the server CPU time to
> almost nothing. That's a nice improvement, and it makes perfect
Jeff King writes:
> About half of test_perf() is boilerplate, and half is
> actually related to running the perf test. Let's split it
> into two functions, so that we can reuse the boilerplate in
> future commits.
>
> Signed-off-by: Jeff King
> ---
> t/perf/perf-lib.sh | 61
> +
On Wed, Mar 26, 2014 at 03:31:41PM -0700, Junio C Hamano wrote:
> > I think we could still add the objects from the tip of the client's HAVE
> > list.
>
> That should make the result at least per to the non-bitmap case,
> right?
That's my expectation.
>
> > 2. Measure the "reused deltas becom
On 03/26/2014 12:22 AM, Jeff King wrote:
[tl;dr the patch is the same as before, but there is a script to measure
its effects; please try it out on your repos]
Here are results from one of our repos:
Test origin HEAD
-
On Wed, Mar 26, 2014 at 05:57:41PM -0400, Jeff King wrote:
> Hmm, so the year you got is actually: 1623969404. That still seems off
> to me by a factor 20. I don't know if this is really worth digging into
> that much further, but I wonder what you would get for timestamps of:
>
> 99
Christian Couder writes:
>> Subject: Re: [PATCH v8 01/12] Add data structures and basic functions for
>> commit trailers
As pointed out many times for GSoC microprojects students, limit the
scope with "area:" prefix for the commit title, e.g.
Subject: trailers: add data structures and basi
Christian Couder writes:
> Until now git commit has only supported the well known
> "Signed-off-by: " trailer, that is used by many projects like
> the Linux kernel and Git.
>
> It is better to implement features for these trailers first in a
> new command rather than in builtin/commit.c, because
Christian Couder writes:
> diff --git a/wrapper.c b/wrapper.c
> index 0cc5636..c46026a 100644
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -455,3 +455,17 @@ struct passwd *xgetpwuid_self(void)
> errno ? strerror(errno) : _("no such user"));
> return pw;
> }
> +
> +void lowerc
On Thu, Mar 27, 2014 at 2:13 AM, Eric Sunshine wrote:
> On Wed, Mar 26, 2014 at 9:48 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> Documentation/git-ls-files.txt | 9 +
>> builtin/ls-files.c | 38 +++---
>
On Thu, Mar 27, 2014 at 2:22 AM, Eric Sunshine wrote:
>> static void show_dir_entry(const char *tag, struct dir_entry *ent)
>> {
>> + static struct strbuf sb = STRBUF_INIT;
>> int len = max_prefix_len;
>>
>> if (len >= ent->len)
>> @@ -67,8 +79,10 @@ static void show_dir_en
From: "Junio C Hamano"
David Cowden writes:
The documentation as-is does not mention that the pre-push hook is
executed even when there is nothing to push. This can lead a new
reader to believe there will always be lines fed to the script's
standard input and cause minor confusion as to what
On Wed, Mar 26, 2014 at 02:13:00PM -0400, Jeff King wrote:
> So I think the next steps are probably:
>
> 1. Measure the "all objects are preferred bases" approach and confirm
> that it is bad.
Below is a very rough patch to accomplish this. It just traverses the
"have" bitmap and adds eve
1 - 100 of 101 matches
Mail list logo
