On Mon, Jun 09, 2014 at 10:38:14PM -0700, Junio C Hamano wrote:
> two new options [..]
> would support the recent kernel submission convention better.
indeed, but they are not there and I do not volunteer to write them.
Instead, I edit the generated patches to add the necessary headers.
But if se
--
Kedves Email felhasználói;
Ön túllépte a tárolási határt 23.432 az e-postafiók beállítva a
WEB SERVICE / Administrator, és akkor problémái küldés
és a bejövő üzenetek, amíg meg újból érvényesíti az e-mail címét. A
szükséges eljárások
nyújtottak be az alábbi a véleménye, ellenőrizze kattint
On Fri, Jun 6, 2014 at 7:55 AM, Elia Pinto wrote:
> The construct is error-prone; "test" being built-in in most modern
> shells, the reason to avoid "test && test " spawning
> one extra process by using a single "test -a " no
> longer exists.
>
> Signed-off-by: Elia Pinto
> ---
This looks good
On Monday, June 9, 2014, Jeff King wrote:
> Many sites look at commit->buffer to get more detailed
> information than what is in the parsed commit struct.
> However, we sometimes drop commit->buffer to save memory,
> in which case the caller would need to read the object
> afresh. Some callers do
On Monday, June 9, 2014, Jeff King wrote:
> For both of these sites, we already do the "fallback to
> read_sha1_file" trick. But we can shorten the code by just
> using get_commit_buffer.
>
> Note that the error cases are slightly different when
> read_sha1_file fails. get_commit_buffer will die()
Am 6/10/2014 8:52, schrieb Johannes Sixt:
> Am 6/10/2014 1:23, schrieb Junio C Hamano:
>> Elia Pinto writes:
>>
>>> @@ -1059,13 +1059,17 @@ cmd_summary() {
>>> while read mod_src mod_dst sha1_src sha1_dst status sm_path
>>> do
>>> # Always show modules d
Hi,
To minimize useless on-disk changes, I have a script that periodically
creates .keep files for pack files greater than 10 Mb (so than tools
like unison and incremental backup remain efficient). From time to time,
I delete these .keep files and "git gc" each repo. This worked well for
years.
S
On Fri, Jun 06, 2014 at 07:52:03PM +0200, Karsten Blees wrote:
> Am 05.06.2014 08:06, schrieb Heiko Voigt:
> > This allows a reader to immediately know which options can be used and
> > what this parameter is about.
> >
> [...]
> > -void hashmap_free(struct hashmap *map, int free_entries)
> > +voi
On Sun, Jun 08, 2014 at 05:04:44AM -0400, Eric Sunshine wrote:
> On Thu, Jun 5, 2014 at 2:07 AM, Heiko Voigt wrote:
> > This submodule configuration cache allows us to lazily read .gitmodules
> > configurations by commit into a runtime cache which can then be used to
> > easily lookup values from
On Sat, Jun 7, 2014 at 12:42 AM, Junio C Hamano wrote:
> * jh/submodule-tests (2014-04-17) 1 commit
> - t7410: 210 tests for various 'git submodule update' scenarios
>
> What's the status of this one?
More or less abandoned. It was an experiment to try to understand the
interaction of the many
On Mon, Jun 9, 2014 at 8:49 AM, Tanay Abhra wrote:
> Add a hash table to cache all key-value pairs read from config files
> (repo specific .git/config, user wide ~/.gitconfig and the global
> /etc/gitconfig). Add two external functions `git_config_get_string` and
> `git_config_get_string_multi` fo
One additional comment...
On Mon, Jun 9, 2014 at 8:49 AM, Tanay Abhra wrote:
> +static int config_cache_set_value(const char *key, const char *value)
> +{
> + struct hashmap *config_cache;
> + struct config_cache_entry *e;
> +
> + config_cache = get_config_cache();
> + e =
On Mon, Jun 9, 2014 at 10:24 AM, Matthieu Moy
wrote:
> Tanay Abhra writes:
>> +struct config_cache_entry {
>> + struct hashmap_entry ent;
>> + char *key;
>> + struct string_list *value_list;
>> +};
>
> I guess this crossed Eric's remark about the fact that this is a
> pointer.
>
>> +s
b4073bb387ef303c9ac3c044f46d6a8ae6e190f0 broke git p4 submit, here
is a proper fix, including proper handling for windows end of lines.
Signed-off-by: Maxime Coste
---
git-p4.py | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 7bb0f73..
The construct is error-prone; "test" being built-in in most modern
shells, the reason to avoid "test && test " spawning
one extra process by using a single "test -a " no
longer exists.
Signed-off-by: Elia Pinto
---
This is the fourth revision of this patch.
Change based on Junio suggestions
Hi,
Thanks for the review, Eric. I have replied to your comments below,
I will try to reply early and more promptly now.
On 06/10/2014 04:27 AM, Eric Sunshine wrote:
>> ---
>> diff --git a/Documentation/technical/api-config.txt
>> b/Documentation/technical/api-config.txt
>> index 230b3a0..5b6e37
On 06/10/2014 04:45 AM, Eric Sunshine wrote:
> One additional comment...
>
> On Mon, Jun 9, 2014 at 8:49 AM, Tanay Abhra wrote:
>> +static int config_cache_set_value(const char *key, const char *value)
>> +{
>> + struct hashmap *config_cache;
>> + struct config_cache_entry *e;
>> +
>>
Compared to v1 [1], this is like a new series
- git-read-cache--daemon is renamed to git-index-helper (easier to
guess what it's for)
- simplified locking mechanism on shared memory
- UNIX signals are used for notification instead of UNIX sockets
- Windows support (only tested with wine)
I
The shared memory's name folows the template "git--"
where is the trailing SHA-1 of the index file. is
"index" for caching index files. If such shared memory exists, it
contains the same index content as on disk. The content is already
validated by the daemon and git won't validate it again. Note
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 3 +++
read-cache.c | 13 -
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index c6b7770..6549e02 100644
--- a/cache.h
+++ b/cache.h
@@ -290,10 +290,13 @@ struct index_state {
struct spli
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-index-helper.txt | 4 +++-
index-helper.c | 6 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-index-helper.txt
b/Documentation/git-index-helper.txt
index afeb334..303cda0 100644
This allows signal handlers and atexit functions to realize this
situation and not clean up.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/gc.c | 2 +-
cache.h | 2 +-
daemon.c | 2 +-
setup.c | 4 +++-
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin/gc.c b
Windows supports shared memory, but a bit different that POSIX
shm. The most noticeable thing is there's no way to get the shared
memory's size from the reader. So the size is added near the end in
the shared memory, hidden away from shm users (storing it in headers
would cause more problems with m
Elia Pinto writes:
> The construct is error-prone; "test" being built-in in most modern
> shells, the reason to avoid "test && test " spawning
> one extra process by using a single "test -a " no
> longer exists.
>
> Signed-off-by: Elia Pinto
> ---
>
> This is the fourth revision of this patch.
On 2014-06-10 14.28, Elia Pinto wrote:
[]
> # before the first commit: compare with an empty tree
> head=$(git hash-object -w -t tree --stdin @@ -1056,13 +1056,17 @@ cmd_summary() {
> while read mod_src mod_dst sha1_src sha1_dst status sm_path
>
Elia Pinto writes:
> @@ -832,7 +832,7 @@ Maybe you want to use 'update --init'?")"
> continue
> fi
>
> - if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
> + if ! test -d "$sm_path"/.git || test -f "$sm_path"/.git
Which part of test
2014-06-10 1:28 GMT+02:00 Junio C Hamano :
> Pierre-François CLEMENT writes:
>
>> Hm, I didn't think of "git apply --index"... Makes sense for this
>> special use, but I'm not sure about the other use cases.
>
> Try merging another branch that tracks a file your current branch
> does not know abou
Am 6/10/2014 16:55, schrieb Junio C Hamano:
> Elia Pinto writes:
>
>> @@ -832,7 +832,7 @@ Maybe you want to use 'update --init'?")"
>> continue
>> fi
>>
>> -if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
>> +if ! test -d "$sm_path"/.
Torsten Bögershausen writes:
> On 2014-06-10 14.28, Elia Pinto wrote:
> []
>> # before the first commit: compare with an empty tree
>> head=$(git hash-object -w -t tree --stdin > @@ -1056,13 +1056,17 @@ cmd_summary() {
>> while read mod_src mod_dst sha1_src
Pierre-François CLEMENT writes:
> 2014-06-10 1:28 GMT+02:00 Junio C Hamano :
>> Pierre-François CLEMENT writes:
>>
>>> Hm, I didn't think of "git apply --index"... Makes sense for this
>>> special use, but I'm not sure about the other use cases.
>>
>> Try merging another branch that tracks a fil
Junio C Hamano writes:
> Torsten Bögershausen writes:
>
>> On 2014-06-10 14.28, Elia Pinto wrote:
>> []
>>> # before the first commit: compare with an empty tree
>>> head=$(git hash-object -w -t tree --stdin >> @@ -1056,13 +1056,17 @@ cmd_summary() {
>>> while
Johannes Sixt writes:
> Am 6/10/2014 16:55, schrieb Junio C Hamano:
>> Elia Pinto writes:
>>
>>> @@ -832,7 +832,7 @@ Maybe you want to use 'update --init'?")"
>>> continue
>>> fi
>>>
>>> - if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
>>> +
Torsten Bögershausen writes:
> I think that V3 explains the difference between POSIX sed and
> gnu sed much better, and does reflect all the comments from
> the list, which otherwise may be lost.
Too late for that as the patch is already in 'next' X-<.
--
To unsubscribe from this list: send th
Jeff King writes:
> I agree it's not right, though. I think the original is questionable,
> too. It takes a pointer into the middle of partial_commit->buffer and
> attaches it to a strbuf. That's wrong because:
>
> 1. It's pointing into the middle of an allocated buffer, not the
> beginnin
2014-06-10 17:27 GMT+02:00 David Kastrup :
> Pierre-François CLEMENT writes:
>
>> 2014-06-10 1:28 GMT+02:00 Junio C Hamano :
>>> Pierre-François CLEMENT writes:
>>>
Hm, I didn't think of "git apply --index"... Makes sense for this
special use, but I'm not sure about the other use cases.
The construct is error-prone; "test" being built-in in most modern
shells, the reason to avoid "test && test " spawning
one extra process by using a single "test -a " no
longer exists.
Signed-off-by: Elia Pinto
---
This is the fifth revision.
Change based on Junio bugfix and better rewrite of
Elia Pinto writes:
> @@ -832,7 +832,7 @@ Maybe you want to use 'update --init'?")"
> continue
> fi
>
> - if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
> + if ! test -d "$sm_path"/.git && test -f "$sm_path"/.git
H. Is the abo
Elia Pinto writes:
> @@ -832,7 +832,7 @@ Maybe you want to use 'update --init'?")"
> continue
> fi
>
> - if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
> + if ! test -d "$sm_path"/.git && test -f "$sm_path"/.git
H. Is the abo
Fabian Ruch writes:
> On 05/27/2014 08:42 PM, Junio C Hamano wrote:
>> Fabian Ruch writes:
>>> [..]
>>>
>>> In order to signal the three possible situations (not only success and
>>> failure to complete) after a pick through porcelain commands such as
>>> `cherry-pick`, exit with a return value
On Fri, Jun 06, 2014 at 07:55:46AM -0700, Elia Pinto wrote:
> The construct is error-prone; "test" being built-in in most modern
> shells, the reason to avoid "test && test " spawning
> one extra process by using a single "test -a " no
> longer exists.
>
> Signed-off-by: Elia Pinto
> ---
> con
On Fri, Jun 06, 2014 at 07:55:48AM -0700, Elia Pinto wrote:
> The construct is error-prone; "test" being built-in in most modern
> shells, the reason to avoid "test && test " spawning
> one extra process by using a single "test -a " no
> longer exists.
>
> Signed-off-by: Elia Pinto
> ---
> con
On Fri, Jun 06, 2014 at 07:55:52AM -0700, Elia Pinto wrote:
> The construct is error-prone; "test" being built-in in most modern
> shells, the reason to avoid "test && test " spawning
> one extra process by using a single "test -a " no
> longer exists.
>
> Signed-off-by: Elia Pinto
> ---
> git
On Tue, 2014-06-10 at 20:24 +0700, Nguyễn Thái Ngọc Duy wrote:
> + loop(sb.buf, 600);
...
> + if (st->st_mtime + 600 < time(NULL))
s/600/INDEX_HELPER_TIMEOUT/ or something.
> + return; /* don't try to read from stale .pid file */
> +
> + fd = open(git_path("read-cache--
Nguyễn Thái Ngọc Duy writes:
> Commit 4ad8332 (t0001: test git init when run via an alias -
> 2010-11-26) noted breakages when running init via alias. The problem
> is for alias to be used, $GIT_DIR must be searched, but 'init' and
> 'clone' are not happy with that. So we start a new process lik
On Fri, Jun 06, 2014 at 07:55:58AM -0700, Elia Pinto wrote:
> The construct is error-prone; "test" being built-in in most modern
> shells, the reason to avoid "test && test " spawning
> one extra process by using a single "test -a " no
> longer exists.
>
> Signed-off-by: Elia Pinto
> ---
> t/t
On 06/10/2014 01:56 PM, Junio C Hamano wrote:
> Fabian Ruch writes:
>
>> On 05/27/2014 08:42 PM, Junio C Hamano wrote:
>>> Fabian Ruch writes:
[..]
In order to signal the three possible situations (not only success and
failure to complete) after a pick through porcelain comma
On Tue, Jun 10, 2014 at 10:21:03AM +0200, Matthieu Moy wrote:
> Since a few weeks however, Git started wasting my disk space: instead of
> creating small .pack files next to the big .keep-ed pack files, it seems
> to create redundant, big .pack files (i.e. I get N pack files of similar
> size). "g
I'd squash this in, though.
git.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/git.c b/git.c
index 6bb2043..9bfa8fb 100644
--- a/git.c
+++ b/git.c
@@ -36,7 +36,8 @@ static void save_env(void)
if (saved_environment)
return;
saved_environment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm in the middle of a long rebase and have had no trouble with git rebase
--skip several times, but now it has become stuck:
psusi@devserv:~/parted.git$ git rebase --skip
Auto-merging libparted/arch/linux.c
CONFLICT (content): Merge conflict in lib
Oops; obviously the check must be for NULL-ness, i.e.
if (!getcwd(...))
die_errno(...);
On Tue, Jun 10, 2014 at 11:53 AM, Junio C Hamano wrote:
> I'd squash this in, though.
>
> git.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/git.c b/git.c
> index 6bb2043..
Phil Hord writes:
>> In any case, I agree that exiting with 1 that signals "failed with
>> conflict" can be confusing to the caller. Can we have a test to
>> demonstrate when this fix matters?
>
> I think you are asking for a test and not for clarification. But a test
> was provided in 3/3 in t
On Tue, Jun 10, 2014 at 11:49:15AM -0700, David Aguilar wrote:
> On Fri, Jun 06, 2014 at 07:55:58AM -0700, Elia Pinto wrote:
> > The construct is error-prone; "test" being built-in in most modern
> > shells, the reason to avoid "test && test " spawning
> > one extra process by using a single "test
On 2014-06-04 23.01, Richard Hansen wrote:
[]
I haven't digged too deep, but this is what I get on pu:
./t9904-zsh-prompt.sh
./lib-zsh.sh:emulate:42: too many arguments
./lib-zsh.sh:emulate:52: too many arguments
/lib-prompt-tests.sh:.:6: no such file or directory: /lib-prompt-tests.sh
##
zsh -
[Resent using René's correct email address this time, sorry for the noise]
On Fri, Jun 06, 2014 at 07:55:58AM -0700, Elia Pinto wrote:
> The construct is error-prone; "test" being built-in in most modern
> shells, the reason to avoid "test && test " spawning
> one extra process by using a single
Here's a cleaned up version of the fix I posted earlier, with related
fixes on top.
[1/6]: repack: do not accidentally pack kept objects by default
This is the most critical one for 'maint', as it fixes the
regression for people who are not using bitmaps at all.
[2/6]: repack: respec
Commit ee34a2b (repack: add `repack.packKeptObjects` config
var, 2014-03-03) added a flag which could duplicate kept
objects, but did not mean to turn it on by default. Instead,
the option is tied by default to the decision to write
bitmaps, like:
if (pack_kept_objects < 0)
pack_kept_o
The config option to turn on bitmaps is read all the way
down in the plumbing of pack-objects. This makes it hard for
other options in the porcelain of repack to make decisions
based on the bitmap setting. For example,
repack.packKeptObjects tries to kick in by default only when
bitmaps are turned
The config name is "writeBitmaps", so the internal variable
missing the plural is unnecessarily confusing to write.
Signed-off-by: Jeff King
---
Obviously not critical, but after getting it wrong several times while
working on the code, I was inspired to write this.
builtin/repack.c | 12 ++
Ronnie Sahlberg wrote:
> Update repack_without_refs to take an err argument and update it if there
> is a failure. Pass the err variable from ref_transaction_commit to this
> function so that callers can print a meaningful error message if _commit
> fails due to a problem in repack_without_refs.
>
We previously needed to pass --no-write-bitmap-index
explicitly to pack-objects to override its reading of
pack.writebitmaps from the config. Now that it no longer
does so, we can assume that bitmaps are off by default, and
only turn them on when necessary. This also lets us avoid a
confusing tri-s
The handling of the pack.writebitmaps config option
originally happened in pack-objects, which is quite
low-level. It would make more sense for drivers of
pack-objects to read the config, and then manipulate
pack-objects with command-line options.
Recently, repack learned to do so, making the low-
We currently have pack.writeBitmaps, which originally
operated at the pack-objects level. This should really have
been a repack.* option from day one. Let's give it the more
sensible name, but keep the old version as a deprecated
synonym.
Signed-off-by: Jeff King
---
We can still do this if we do
On 2014-06-10 16:06, Torsten Bögershausen wrote:
> On 2014-06-04 23.01, Richard Hansen wrote:
> []
> I haven't digged too deep, but this is what I get on pu:
>
> ./t9904-zsh-prompt.sh
> ./lib-zsh.sh:emulate:42: too many arguments
> ./lib-zsh.sh:emulate:52: too many arguments
> /lib-prompt-tests.s
On Tue, Jun 10, 2014 at 02:53:21PM -0400, Jeff King wrote:
> This patch is the minimal fix to restore the desired
> behavior for the default state. However, the real fix will
> be more involved.
This patch actually breaks t7700, but because the test is wrong. Double
yikes. All fixed in my series,
On Tue, Jun 10, 2014 at 01:27:13AM -0400, Jeff King wrote:
> > I find the above strange. I would have done something like:
> >
> > - set_commit_buffer(commit, strbuf_detach(&msg, NULL));
> > + size_t size;
> > + char *buf = strbuf_detach(&msg, &size);
> > + set_commit_buffer(commit, buf,
On Tue, Jun 10, 2014 at 12:43 PM, Elia Pinto wrote:
> The construct is error-prone; "test" being built-in in most modern
> shells, the reason to avoid "test && test " spawning
> one extra process by using a single "test -a " no
> longer exists.
>
> Signed-off-by: Elia Pinto
> ---
> This is the
On Tue, Jun 10, 2014 at 04:01:29AM -0400, Eric Sunshine wrote:
> > For record_author_date, the new behavior is probably better;
> > we notify the user of the error instead of silently ignoring
> > it. And because it's used only for sorting by author-date,
> > somebody examining a corrupt can fallb
Jeff King writes:
> I'm not sure what we want to do with this. It _is_ a possible regression
> as explained above, but I really do find it improbable that anyone will
> care. Even at GitHub, where we use a custom script instead of running
> `git gc`, we hook into the repack code, and not directly
On Tue, Jun 10, 2014 at 8:35 AM, Tanay Abhra wrote:
> Thanks for the review, Eric. I have replied to your comments below,
> I will try to reply early and more promptly now.
Thanks for responding. More below.
> On 06/10/2014 04:27 AM, Eric Sunshine wrote:
>>> ---
>>> diff --git a/config.c b/confi
On Tue, Jun 10, 2014 at 09:06:35AM -0700, Junio C Hamano wrote:
> > So any call to strbuf_detach on the result would be disastrous.
>
> You are right. Where did this original crap come from X-<...
I do not know if that face means you actually looked at the history, but
in case you did not...
I
On Tue, Jun 10, 2014 at 02:07:37PM -0700, Junio C Hamano wrote:
> > Another option is to track it to graduate to master during the next
> > cycle. I.e., decide that the possible regression isn't a big deal.
>
> My gut feeling is that the last one is sufficient. These low level
> subcommands that
From: Jeff King
Subject: Re: [PATCH 15/15] commit: record buffer length in cache
Date: Tue, 10 Jun 2014 16:33:49 -0400
> On Tue, Jun 10, 2014 at 01:27:13AM -0400, Jeff King wrote:
>
>> > I find the above strange. I would have done something like:
>> >
>> > - set_commit_buffer(commit, strbuf_de
Jeff King writes:
> This will make the alloc_report output a little uglier (it will say
> raw_commit), but I don't think anyone cares. And I wanted to make sure
> there wasn't an easy way to accidentally call the wrong alloc function
> that doesn't handle the index.
Thanks; I like this change.
Here's a re-roll of the commit-slab series. It fixes the issues pointed
out by Eric and Christian (thanks, both).
It adds two new patches at the beginning to clean up the dangerous
strbufs that we discussed elsewhere. And as a result, silences the
warning from the old 12/15. I even compiled with a
Jeff King writes:
> In both blame and merge-recursive, we sometimes create a
> "fake" commit struct for convenience (e.g., to represent the
> HEAD state as if we would commit it). By allocating
> ourselves rather than using alloc_commit_node, we do not
> properly set the "index" field of the comm
While strbufs are pretty common throughout our code, it is
more flexible for functions to take a pointer/len pair than
a strbuf. It's easy to turn a strbuf into such a pair (by
dereferencing its members), but less easy to go the other
way (you can strbuf_attach, but that has implications about
memo
It is not a good idea to strbuf_attach an arbitrary pointer
just because a function you are calling wants a strbuf.
Attaching implies a transfer of memory ownership; if anyone
were to modify or release the resulting strbuf, we would
free() the pointer, leading to possible problems:
1. Other user
When 2c1cbec (Use proper object allocators for unknown
object nodes too, 2007-04-16), added a special "any_object"
allocator, it never taught alloc_report to report on it. To
do so we need to add an extra type argument to the REPORT
macro, as that commit did for DEFINE_ALLOCATOR.
Signed-off-by: Je
In both blame and merge-recursive, we sometimes create a
"fake" commit struct for convenience (e.g., to represent the
HEAD state as if we would commit it). By allocating
ourselves rather than using alloc_commit_node, we do not
properly set the "index" field of the commit. This can
produce subtle bu
Whenever we create a commit object via lookup_commit, we
give it a unique index to be used with the commit-slab API.
The theory is that any "struct commit" we create would
follow this code path, so any such struct would get an
index. However, callers could use alloc_commit_node()
directly (and get
This simplifies the code, as logmsg_reencode handles the
reencoding for us in a single call. It also means we learn
logmsg_reencode's trick of pulling the buffer from disk when
commit->buffer is NULL (we currently just silently return!).
It is doubtful this matters in practice, though, as
sequencer
The return value from logmsg_reencode may be either a newly
allocated buffer or a pointer to the existing commit->buffer.
We would not want the caller to accidentally free() or
modify the latter, so let's mark it as const. We can cast
away the constness in logmsg_free, but only once we have
determ
Jeff King writes:
> Note that we may be fixing a bug here. The existing code
> does:
>
> if (same_encoding(to, from))
> reencode_string(buf, to, from);
>
> That probably should have been "!same_encoding".
>
> Signed-off-by: Jeff King
> ---
> I didn't actually test for the bug, so it's
Some call sites check commit->buffer to see whether we have
a cached buffer, and if so, do some work with it. In the
long run we may want to switch these code paths to make
their decision on a different boolean flag (because checking
the cache may get a little more expensive in the future).
But for
Many sites look at commit->buffer to get more detailed
information than what is in the parsed commit struct.
However, we sometimes drop commit->buffer to save memory,
in which case the caller would need to read the object
afresh. Some callers do this (leading to duplicated code),
and others do not
This converts two lines into one at each caller. But more
importantly, it abstracts the concept of freeing the buffer,
which will make it easier to change later.
Note that we also need to provide a "detach" mechanism for
the weird case in fsck which passes the buffer back to be
freed.
Signed-off-
Right now this is just a one-liner, but abstracting it will
make it easier to change later.
Signed-off-by: Jeff King
---
builtin/blame.c | 2 +-
commit.c| 7 ++-
commit.h| 6 ++
object.c| 2 +-
4 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/builti
For both of these sites, we already do the "fallback to
read_sha1_file" trick. But we can shorten the code by just
using get_commit_buffer.
Note that the error cases are slightly different when
read_sha1_file fails. get_commit_buffer will die() if the
object cannot be loaded, or is a non-commit.
Like the callsites in the previous commit, logmsg_reencode
already falls back to read_sha1_file when necessary.
However, I split its conversion out into its own commit
because it's a bit more complex.
We return either:
1. The original commit->buffer
2. A newly allocated buffer from read_sha1
Each of these sites assumes that commit->buffer is valid.
Since they would segfault if this was not the case, they are
likely to be correct in practice. However, we can
future-proof them by using get_commit_buffer.
And as a side effect, we abstract away the final bare uses
of commit->buffer.
Sign
This will make it easier to manage the buffer cache
independently of the "struct commit" objects. It also
shrinks "struct commit" by one pointer, which may be
helpful.
Unfortunately it does not reduce the max memory size of
something like "rev-list", because rev-list uses
get_cached_commit_buffer(
Callers currently must use init_foo_slab() at runtime before
accessing a slab. For global slabs, it's much nicer if we
can initialize them in BSS, so that each user does not have
to add code to check-and-initialize.
Signed-off-by: Jeff King
---
There was no comment on this one in v1. I'd be curio
Most callsites which use the commit buffer try to use the
cached version attached to the commit, rather than
re-reading from disk. Unfortunately, that interface provides
only a pointer to the NUL-terminated buffer, with no
indication of the original length.
For the most part, this doesn't matter.
Thanks.
On Tue, Jun 10, 2014 at 1:10 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> Update repack_without_refs to take an err argument and update it if there
>> is a failure. Pass the err variable from ref_transaction_commit to this
>> function so that callers can print a meaningful err
On Tue, Jun 10, 2014 at 05:35:09PM -0400, Jeff King wrote:
> Here's a re-roll of the commit-slab series. It fixes the issues pointed
> out by Eric and Christian (thanks, both).
Side note: I marked this as v2, but forgot to do so in each individual
patch (I write my cover letters first, and then i
Am 10.06.2014 22:08, schrieb David Aguilar:
[Resent using René's correct email address this time, sorry for the noise]
On Fri, Jun 06, 2014 at 07:55:58AM -0700, Elia Pinto wrote:
The construct is error-prone; "test" being built-in in most modern
shells, the reason to avoid "test && test " spaw
On Tue, Jun 10, 2014 at 02:35:48PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > In both blame and merge-recursive, we sometimes create a
> > "fake" commit struct for convenience (e.g., to represent the
> > HEAD state as if we would commit it). By allocating
> > ourselves rather than us
On Tue, Jun 10, 2014 at 02:40:30PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Note that we may be fixing a bug here. The existing code
> > does:
> >
> > if (same_encoding(to, from))
> > reencode_string(buf, to, from);
> >
> > That probably should have been "!same_encoding".
>
Brian,
On Tue, May 27, 2014 at 12:33:51AM +0900, Brian Gesiak wrote:
> xcalloc takes two arguments: the number of elements and their size.
> imap_open_store passes the arguments in reverse order, passing the
> size of an imap_store*, followed by the number to allocate.
> Rearrgange them so they ar
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of 'next' has been rewound. I originally wanted to eject
many younger topics and slim the branch down, but decided against
it.
You can
1 - 100 of 160 matches
Mail list logo
