Am 6/10/2014 1:05, schrieb Junio C Hamano:
Junio C Hamano gits...@pobox.com writes:
David Turner dtur...@twopensource.com writes:
Since Junio has picked up the first patch from previous versions of
this series, I'm just going to send the second (SSE) one. I decided
not to
On 06/10/2014 07:55 AM, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
t9001 used a '\n' in a sed expression to split one line into two lines,
but the usage of '\n' in the replacement string is not portable.
This looks peculiarly familiar; don't I already have it queued?
Am 6/10/2014 1:23, schrieb Junio C Hamano:
Elia Pinto gitter.spi...@gmail.com writes:
@@ -1059,13 +1059,17 @@ cmd_summary() {
while read mod_src mod_dst sha1_src sha1_dst status sm_path
do
# Always show modules deleted or type-changed
Johannes Sixt j.s...@viscovery.net writes:
And I get this when I compile on Windows with msysgit:
CC abspath.o
In file included from git-compat-util.h:694,
from cache.h:4,
from abspath.c:1:
compat/cpuid.h: In function 'processor_supports_sse42':
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
--
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
On Fri, Jun 6, 2014 at 7:55 AM, Elia Pinto gitter.spi...@gmail.com wrote:
The construct is error-prone; test being built-in in most modern
shells, the reason to avoid test cond test cond spawning
one extra process by using a single test cond -a cond no
longer exists.
Signed-off-by: Elia
On Monday, June 9, 2014, Jeff King p...@peff.net 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
On Monday, June 9, 2014, Jeff King p...@peff.net 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
Am 6/10/2014 8:52, schrieb Johannes Sixt:
Am 6/10/2014 1:23, schrieb Junio C Hamano:
Elia Pinto gitter.spi...@gmail.com writes:
@@ -1059,13 +1059,17 @@ cmd_summary() {
while read mod_src mod_dst sha1_src sha1_dst status sm_path
do
# Always show
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.
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)
+void
On Sun, Jun 08, 2014 at 05:04:44AM -0400, Eric Sunshine wrote:
On Thu, Jun 5, 2014 at 2:07 AM, Heiko Voigt hvo...@hvoigt.net 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
On Sat, Jun 7, 2014 at 12:42 AM, Junio C Hamano gits...@pobox.com 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
On Mon, Jun 9, 2014 at 8:49 AM, Tanay Abhra tanay...@gmail.com 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
One additional comment...
On Mon, Jun 9, 2014 at 8:49 AM, Tanay Abhra tanay...@gmail.com 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();
On Mon, Jun 9, 2014 at 10:24 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Tanay Abhra tanay...@gmail.com 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
b4073bb387ef303c9ac3c044f46d6a8ae6e190f0 broke git p4 submit, here
is a proper fix, including proper handling for windows end of lines.
Signed-off-by: Maxime Coste frrr...@gmail.com
---
git-p4.py | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/git-p4.py
The construct is error-prone; test being built-in in most modern
shells, the reason to avoid test cond test cond spawning
one extra process by using a single test cond -a cond no
longer exists.
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
This is the fourth revision of this patch.
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..5b6e376
On 06/10/2014 04:45 AM, Eric Sunshine wrote:
One additional comment...
On Mon, Jun 9, 2014 at 8:49 AM, Tanay Abhra tanay...@gmail.com 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)
The shared memory's name folows the template git-something-SHA1
where SHA1 is the trailing SHA-1 of the index file. something 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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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 {
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
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 pclo...@gmail.com
---
builtin/gc.c | 2 +-
cache.h | 2 +-
daemon.c | 2 +-
setup.c | 4 +++-
4 files changed, 6 insertions(+), 4 deletions(-)
diff
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
Elia Pinto gitter.spi...@gmail.com writes:
The construct is error-prone; test being built-in in most modern
shells, the reason to avoid test cond test cond spawning
one extra process by using a single test cond -a cond no
longer exists.
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
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 /dev/null)
@@ -1056,13 +1056,17 @@ cmd_summary() {
while read mod_src mod_dst sha1_src sha1_dst status sm_path
Elia Pinto gitter.spi...@gmail.com 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
2014-06-10 1:28 GMT+02:00 Junio C Hamano gits...@pobox.com:
Pierre-François CLEMENT lik...@gmail.com 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
Am 6/10/2014 16:55, schrieb Junio C Hamano:
Elia Pinto gitter.spi...@gmail.com 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
Torsten Bögershausen tbo...@web.de 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 /dev/null)
@@ -1056,13 +1056,17 @@ cmd_summary() {
while read mod_src
Pierre-François CLEMENT lik...@gmail.com writes:
2014-06-10 1:28 GMT+02:00 Junio C Hamano gits...@pobox.com:
Pierre-François CLEMENT lik...@gmail.com 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
Junio C Hamano gits...@pobox.com writes:
Torsten Bögershausen tbo...@web.de 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 /dev/null)
@@ -1056,13 +1056,17 @@
Johannes Sixt j.s...@viscovery.net writes:
Am 6/10/2014 16:55, schrieb Junio C Hamano:
Elia Pinto gitter.spi...@gmail.com writes:
@@ -832,7 +832,7 @@ Maybe you want to use 'update --init'?)
continue
fi
- if ! test -d $sm_path/.git -o -f
Torsten Bögershausen tbo...@web.de 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
Jeff King p...@peff.net 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
2014-06-10 17:27 GMT+02:00 David Kastrup d...@gnu.org:
Pierre-François CLEMENT lik...@gmail.com writes:
2014-06-10 1:28 GMT+02:00 Junio C Hamano gits...@pobox.com:
Pierre-François CLEMENT lik...@gmail.com writes:
Hm, I didn't think of git apply --index... Makes sense for this
special use,
The construct is error-prone; test being built-in in most modern
shells, the reason to avoid test cond test cond spawning
one extra process by using a single test cond -a cond no
longer exists.
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
This is the fifth revision.
Change based on
Elia Pinto gitter.spi...@gmail.com 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
Elia Pinto gitter.spi...@gmail.com 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
Fabian Ruch baf...@gmail.com writes:
On 05/27/2014 08:42 PM, Junio C Hamano wrote:
Fabian Ruch baf...@gmail.com 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
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 cond test cond spawning
one extra process by using a single test cond -a cond no
longer exists.
Signed-off-by: Elia Pinto
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 cond test cond spawning
one extra process by using a single test cond -a cond no
longer exists.
Signed-off-by: Elia Pinto
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 cond test cond spawning
one extra process by using a single test cond -a cond no
longer exists.
Signed-off-by: Elia Pinto
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 =
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
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 cond test cond spawning
one extra process by using a single test cond -a cond no
longer exists.
Signed-off-by: Elia Pinto
On 06/10/2014 01:56 PM, Junio C Hamano wrote:
Fabian Ruch baf...@gmail.com writes:
On 05/27/2014 08:42 PM, Junio C Hamano wrote:
Fabian Ruch baf...@gmail.com writes:
[..]
In order to signal the three possible situations (not only success and
failure to complete) after a pick through
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). git
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;
-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
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 gits...@pobox.com 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
Phil Hord ho...@cisco.com 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
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 cond test cond spawning
one extra process by using a single test cond
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 cond test cond 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:
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)
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 p...@peff.net
---
Obviously not critical, but after getting it wrong several times while
working on the code, I was inspired to write this.
builtin/repack.c
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
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
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 p...@peff.net
---
We can still 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.sh:.:6:
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, size);
It
On Tue, Jun 10, 2014 at 12:43 PM, Elia Pinto gitter.spi...@gmail.com wrote:
The construct is error-prone; test being built-in in most modern
shells, the reason to avoid test cond test cond spawning
one extra process by using a single test cond -a cond no
longer exists.
Signed-off-by: Elia
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 fallback to
Jeff King p...@peff.net 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
On Tue, Jun 10, 2014 at 8:35 AM, Tanay Abhra tanay...@gmail.com 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
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...
It
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 are
From: Jeff King p...@peff.net
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,
Jeff King p...@peff.net 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
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
Jeff King p...@peff.net 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
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
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
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:
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 bugs
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
Jeff King p...@peff.net 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 p...@peff.net
---
I didn't actually test for the
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.
Right now this is just a one-liner, but abstracting it will
make it easier to change later.
Signed-off-by: Jeff King p...@peff.net
---
builtin/blame.c | 2 +-
commit.c| 7 ++-
commit.h| 6 ++
object.c| 2 +-
4 files changed, 14 insertions(+), 3 deletions(-)
diff
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
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.
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() to
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 p...@peff.net
---
There was no comment on this one in
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 jrnie...@gmail.com 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
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
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 cond test cond
1 - 100 of 163 matches
Mail list logo
