* Re: share object storage for multiple clones of different repositories
From: Frans Klaver @ 2011-11-05 7:37 UTC (permalink / raw)
To: Gelonida N, Junio C Hamano; +Cc: git
In-Reply-To: <7vobwr9uf0.fsf@alter.siamese.dyndns.org>
On Sat, 05 Nov 2011 03:26:11 +0100, Junio C Hamano <gitster@pobox.com>
wrote:
> Gelonida N <gelonida@gmail.com> writes:
>
>> SHARED_STORAGE=$HOME/shared_storage
>> mkdir $SHARED_STORAGE
>>
>> git clone remotehost1:repo1
>> cd repo1
>> rsync -av .git/objects $SHARED_REPO
>
> Up to this part it is probably OK. Repeat that for all your local
> repositories to collect all objects in $HOME/shared_storage.
>
> After doing that, do this in all of your local repositories:
>
> rm -rf .git/objects
> mkdir -p .git/objects/info
> echo $HOME/shared/storage >.git/objects/info/alternates
>
> The reason why nobody should follow your original recipe is because any
> "git gc"/"git repack" in any of your local repositories would break
> others
> with that approach.
Alternatively there's the git-new-workdir script in contrib/workdir in
git.git. Haven't tested it, but it seems like it does what you want.
Frans
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Stephen Boyd @ 2011-11-05 7:53 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <1320376242-27851-1-git-send-email-pclouds@gmail.com>
On 11/03/2011 08:10 PM, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
[...]
> +--progress::
> +--no-progress::
> + When fsck is run in a terminal, it will show the progress.
> + These options can force progress to be shown or not
> + regardless terminal check.
Can we reuse the --progress description in fetch-options.txt (minus the q)?
--[no]-progress::
Progress status is reported on the standard error stream
by default when it is attached to a terminal. This flag
forces progress status even if the standard error stream
is not directed to a terminal.
> ++
> +Progress is not shown when --verbose is used. --progress is ignored
> +in this case.
What progress isn't shown? How about
If --verbose is used with --progress the progress status
will not be shown.
^ permalink raw reply
* [PATCH] completion: Update rebase completion
From: Stephen Boyd @ 2011-11-05 8:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
--no-autosquash is missing in addition to a few others.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
contrib/completion/git-completion.bash | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 98af8f5..5aa8b91 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1764,7 +1764,8 @@ _git_rebase ()
--preserve-merges --stat --no-stat
--committer-date-is-author-date --ignore-date
--ignore-whitespace --whitespace=
- --autosquash
+ --autosquash --no-autosquash --no-ff
+ --rerere-autoupdate --root
"
return
--
1.7.7.1.431.g10b2a
^ permalink raw reply related
* Re: [PATCH 09/10] fmt-merge-msg: Add contents of merged tag in the merge message
From: Johannes Sixt @ 2011-11-05 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1320472900-6601-10-git-send-email-gitster@pobox.com>
Am 05.11.2011 07:01, schrieb Junio C Hamano:
> When a contributor asks the integrator to merge her history, a signed tag
> can be a good vehicle to communicate the authenticity of the request while
> conveying other information such as the purpose of the topic.
>
> E.g. a signed tag "for-linus" can be created, and the integrator can run:
>
> $ git pull git://example.com/work.git/ for-linus
>
> This would allow the integrator to run "git verify-tag FETCH_HEAD" to
> validate the signed tag.
>
> While we do not necessarily want to clutter the global tag namespace of
> the project, we would want to leave enough information in the repository
> to allow third party to later validate the resulting history.
>
> Update fmt-merge-msg that prepares the merge message template, and store
> the contents of the signed tag object and the message that comes from GPG
> signature validation at the end of it. The integrator can choose to leave
> the contents of the tag in the resulting merge commit, or can choose to
> remove it. The GPG validation message is inserted as a comment only to
> help the integrator to review the validation result but otherwise will not
> be recorded in the resulting merge commit, because later validation by
> third parties does not need it.
Since the tag signature depends on the tag message, including all spelin
errors, the integrator must not change the text so that third parties
can repeat the verification. (Correct?) I assume this is the reason that
you put 'tag:' in front of the tag message, to discourage any changes.
What if the tag is not signed? Does this code path trigger at all? In
this case, I would prefer that the discouraging 'tag:' prefix were not
present. The resulting text would fit more naturally in a commit message
as a description of the commit/merge/topic. What do you think?
-- Hannes
^ permalink raw reply
* Re: [PATCHv2] Add options to specify snapshot file name, prefix
From: Jakub Narebski @ 2011-11-05 8:47 UTC (permalink / raw)
To: Thomas Guyot-Sionnest; +Cc: git
In-Reply-To: <4EB488C9.2050301@aei.ca>
On Sat, 5 Nov 2011, Thomas Guyot-Sionnest wrote:
> On 11-11-04 12:10 PM, Jakub Narebski wrote:
> > Thomas Guyot-Sionnest <dermoth@aei.ca> writes:
> >
> > > commit b629275 implemented "smart" snapshot names and prefixes. I have
> > > scripts that used to rely on the old behaviour which allowed in some
> > > cases to have fixed prefix, and would require modifications to work with
> > > newer Gitweb.
[...]
> > > This patch adds two parameters for overriding the snapshot name and
> > > prefix, sn and sp respectively. For example, to get a snapshot
> > > named "myproject.[suffix]" with no prefix one can add this query string:
> > > ?sn=myproject;sp=
> >
> > Would you need support for expandable parameters in both (a la
> > 'action' feature)?
>
> I'm not sure what you mean... I never tinkered with gitweb.pl directly
> before.
I'm sorry I didn't make it clear what I meant here.
What I wanted to ask is if you would need support for snapshot names
like for example
myproject-<full sha1>.tar.gz
It means that snapshot name depends on commit / tag / tree being archived;
for that you would need e.g.
...?sn=myproject-%H.tar.gz;sp=
But even if there would be need for this, it should be anyway put into
separate commit.
In short: forget about this comment.
[...]
> > > @@ -6684,11 +6686,19 @@ sub git_snapshot {
> > > }
> > >
> > > my ($name, $prefix) = snapshot_name($project, $hash);
> > > + if (defined($input_params{'snapshot_name'})) {
> > > + $name = $input_params{'snapshot_name'};
> > > + }
> > > + if (defined($input_params{'snapshot_prefix'})) {
> > > + $prefix = $input_params{'snapshot_prefix'};
> > > + } else {
> > > + $prefix .= '/';
> > > + }
> > > my $filename = "$name$known_snapshot_formats{$format}{'suffix'}";
> > > my $cmd = quote_command(
> > > git_cmd(), 'archive',
> > > "--format=$known_snapshot_formats{$format}{'format'}",
> > > - "--prefix=$prefix/", $hash);
> > > + "--prefix=$prefix", $hash);
> > > if (exists $known_snapshot_formats{$format}{'compressor'}) {
> > > $cmd .= ' | ' . quote_command(@{$known_snapshot_formats{$format}{'compressor'}});
> > > }
> >
> > I wonder if you really want to allow prefix which do not end in '/'
>
> I kind of agree, yet considering its lack of "front-end" visibility it
> made me think of plumbing commands like git-checkout-index (which I use
> sometimes to replace the "missing" git export) where prefix is nothing
> more than an appended string to file names.
>
> And now I remember, this is also exactly how git-archive works.
Right.
I wonder if anybody is using "git archive" with prefix that DOESN'T
end with a '/'...
> > (which would be suprising, isn't it), or just allow empty prefix too.
> >
> >
> > For example
> >
> > @@ -6684,11 +6686,19 @@ sub git_snapshot {
> > }
> >
> > my ($name, $prefix) = snapshot_name($project, $hash);
> > + if (defined($input_params{'snapshot_name'})) {
> > + $name = $input_params{'snapshot_name'};
> > + }
> > + if (defined($input_params{'snapshot_prefix'})) {
> > + $prefix = $input_params{'snapshot_prefix'};
> > + }
> > my $filename = "$name$known_snapshot_formats{$format}{'suffix'}";
> > my $cmd = quote_command(
> > git_cmd(), 'archive',
> > "--format=$known_snapshot_formats{$format}{'format'}",
> > - "--prefix=$prefix/", $hash);
> > + ($prefix eq "" ? () : "--prefix=$prefix"), $hash);
> > if (exists $known_snapshot_formats{$format}{'compressor'}) {
> > $cmd .= ' | ' . quote_command(@{$known_snapshot_formats{$format}{'compressor'}});
> > }
> >
>
> You still have to add the /, i.e.:
>
> > + ($prefix eq "" ? () : "--prefix=$prefix/"), $hash);
True. Sorry about that.
> And personally, I think git-archive is the one that should add a / - it
> has much more visibility to end-users than this obscure query-string.
So should we expect a re-roll?
P.S. I'd like to point out that git is now in pre-release feature freeze,
so please don't expect for these changes to appear in 'master' soon, though
most probably they would be available in 'pu' for the time being.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] fsck: print progress
From: Nguyen Thai Ngoc Duy @ 2011-11-05 9:02 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <4EB4EB70.40801@gmail.com>
2011/11/5 Stephen Boyd <bebarino@gmail.com>:
> On 11/03/2011 08:10 PM, Nguyễn Thái Ngọc Duy wrote:
>> diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
> [...]
>> +--progress::
>> +--no-progress::
>> + When fsck is run in a terminal, it will show the progress.
>> + These options can force progress to be shown or not
>> + regardless terminal check.
>
> Can we reuse the --progress description in fetch-options.txt (minus the q)?
>
> --[no]-progress::
> Progress status is reported on the standard error stream
> by default when it is attached to a terminal. This flag
> forces progress status even if the standard error stream
> is not directed to a terminal.
>
>
>> ++
>> +Progress is not shown when --verbose is used. --progress is ignored
>> +in this case.
>
> What progress isn't shown? How about
>
> If --verbose is used with --progress the progress status
> will not be shown.
"-q" in fetch-options.txt can be converted to "--no-progress or
--verbose". How about this?
--progress::
--no-progress::
Progress status is reported on the standard error stream by
default when it is attached to a terminal, unless
--no-progress or --verbose is specified. --progress forces
progress status even if the standard error stream is not
directed to a terminal.
--
Duy
^ permalink raw reply
* Re: How do I get a squashed diff for review
From: David Aguilar @ 2011-11-05 9:15 UTC (permalink / raw)
To: Alexander Usov; +Cc: git, Roland Kaufmann
In-Reply-To: <CAH_EFyZ_0JB0-5cw-6VEJkfJhSjbmA=3upByQ3YpmnVSvR+9Pg@mail.gmail.com>
On Fri, Nov 04, 2011 at 07:15:01PM +0000, Alexander Usov wrote:
> Hi,
>
> I'm wondering if there is an easy way to get a squashed diff of the
> changes done on the feature branch for review.
> In the simple cases (where feature branch is linear) there is an
> absolutely fantastic way to get a patch for review:
> git diff master...feature
>
> However if the feature branch happened to be long-lived and had
> mainline merged into it it's not going to work -- the
> resulting diff would contain changes from the merge. The way we are
> doing things now is to merge master into it
> once more and then diff, however this is somewhat cumbersome. Is there
> easier way to do it?
"git diff A...B" is equivalent to "git diff <merge-base A B> B".
The merge-base can be found with "git merge-base A B"
and is simply the common ancestor of A and B.
Diffing against the merge base (which doesn't contain the merged
work done in master) is why you're seeing the merges in the diff.
It sounds like you want the simpler form of "diff" which doesn't
do any merge-base calculation.
e.g. "git diff A B" and its synonymn "git diff A..B".
> And while we are on the topic -- is there a tool for git similar to "bzr qdiff"?
> It's a simple graphical diff viewer with 2 nice features -- it shows
> complete diff (of multiple files) in a single window and
> has a checkbox to switch between diff-only & full-text modes.
> I have seen difftool, but it seems to work on per-file basis, and
> something like "vi <(git diff ...)" lacks the easy way to
> switch into full-text mode.
difftool is a wrapper around specialized diff tools, so the
ability to switch from diff to full view is tool-dependent.
A contrib "git-dirdiff" script was posted to the list recently.
It builds upon diff tools that can diff directory trees.
http://thread.gmane.org/gmane.comp.version-control.git/184528
There may be a newer version of this script, too. Roland would
know for sure...
--
David
^ permalink raw reply
* Re: [PATCHv2] Add options to specify snapshot file name, prefix
From: Jakub Narebski @ 2011-11-05 9:18 UTC (permalink / raw)
To: Thomas Guyot-Sionnest; +Cc: git
In-Reply-To: <201111050947.15440.jnareb@gmail.com>
Jakub Narebski wrote:
> So should we expect a re-roll?
By the way, those new query parameters ('sn' and 'sp') should IMHO
be documented in Documentation/gitweb.txt i.e. gitweb(1) manpage.
Also, shouldn't you infer snapshot format from snapshot name
("git archive" does part of that... but not the compression part)?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 00/10] Pulling signed tag
From: Nguyen Thai Ngoc Duy @ 2011-11-05 9:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Robin H. Johnson
In-Reply-To: <1320472900-6601-1-git-send-email-gitster@pobox.com>
On Sat, Nov 5, 2011 at 1:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
> This is my fourth iteration to solve the "how can we allow authenticity of
> work by contributors to be validated by the integrator and leave enough
> information for later audit by third parties" topic. What is unusual is
> that this is not a fourth re-roll of one approach re-re-re-polished, but
> these four are all based on different design.
>
> This round is based on Linus's "let the integrator pull signed tag from
> the contributor" design.
That thread is really long and I may have missed pieces here and
there. My understanding is that this topic now, while supports kernel
development model, would not address the problem gentoo has, which is
described by Robbin in the same thread [1]. Is that correct?
[1] http://thread.gmane.org/gmane.linux.ide/50518/focus=1210629
--
Duy
^ permalink raw reply
* Re: New Feature wanted: Is it possible to let git clone continue last break point?
From: Clemens Buchacher @ 2011-11-05 10:00 UTC (permalink / raw)
To: Shawn Pearce
Cc: Johannes Sixt, Jeff King, Junio C Hamano, Jonathan Nieder,
netroby, Git Mail List, Tomas Carnecky
In-Reply-To: <CAJo=hJtsiEEHA33CQn1MCvb7vFv7uEF+U292YgBa7EWv7P8Jng@mail.gmail.com>
On Fri, Nov 04, 2011 at 07:22:20AM -0700, Shawn Pearce wrote:
> On Fri, Nov 4, 2011 at 02:35, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > Am 11/4/2011 9:56, schrieb Clemens Buchacher:
> >> Cache ... not the pack but the information
> >> to re-create it...
> >
> > It has been discussed. It doesn't work. Because with threaded pack
> > generation, the resulting pack is not deterministic.
So let the client disable it, if they'd rather have a resumeable
fetch than a fast one.
Sorry if I'm being obstinate here. But I don't understand the
problem and I can't find an explanation in related discussions.
> The information to create a pack for a repository with 2M objects
> (e.g. Linux kernel tree) is *at least* 152M of data. This is just a
> first order approximation of what it takes to write out the 2M SHA-1s,
> along with say a 4 byte length so you can find given an offset
> provided by the client roughly where to resumse in the object stream.
> This is like 25% of the pack size itself. Ouch.
Sorry, I should not have said HAVEs. All we need is the common
commits, and the sha1s of the WANTed branch heads at the time of
the initial fetch. That shouldn't be more than 10 or so in typical
cases.
> This data is still insufficient to resume from. A correct solution
> would allow you to resume in the middle of an object, which means we
> also need to store some sort of indicator of which representation was
> chosen from an existing pack file for object reuse. Which adds more
> data to the stream. And then there is the not so simple problem of how
> to resume in the middle of an object that was being recompressed on
> the fly, such as a large loose object.
How often does the "representation chosen from an existing pack
file for object reuse" change? Long term determinism is a problem,
yes. But I see no reason why it should not work for this short-term
case. So long as the pack is created by one particular git and libz
version, and for this particular consecutive run of fetches, we do
not need to store anything about the pack. The client downloads n
MB of data until the drop. To resume, the client says it already
has n MB of data.
No?
Clemens
^ permalink raw reply
* [PATCH] gc --auto: warn gc will soon run, give users a chance to run manually
From: Nguyễn Thái Ngọc Duy @ 2011-11-05 10:33 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I hate it every single time git hangs because gc is activated.
Opening another terminal is an option but I would lose all terminal
settings I have on the current one (e.g. access to suspended vim
sessions).
I don't think gc_warn_* need their own config vars. Hopefully
hardcoded offset is good enough.
builtin/gc.c | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 0498094..1f4555e 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -25,7 +25,9 @@ static const char * const builtin_gc_usage[] = {
static int pack_refs = 1;
static int aggressive_window = 250;
static int gc_auto_threshold = 6700;
+static int gc_warn_auto_threshold = 6600;
static int gc_auto_pack_limit = 50;
+static int gc_warn_auto_pack_limit = 45;
static const char *prune_expire = "2.weeks.ago";
#define MAX_ADD 10
@@ -50,10 +52,12 @@ static int gc_config(const char *var, const char *value, void *cb)
}
if (!strcmp(var, "gc.auto")) {
gc_auto_threshold = git_config_int(var, value);
+ gc_warn_auto_threshold = gc_auto_threshold - 100;
return 0;
}
if (!strcmp(var, "gc.autopacklimit")) {
gc_auto_pack_limit = git_config_int(var, value);
+ gc_warn_auto_pack_limit = gc_auto_pack_limit - 5;
return 0;
}
if (!strcmp(var, "gc.pruneexpire")) {
@@ -118,7 +122,13 @@ static int too_many_loose_objects(void)
}
}
closedir(dir);
- return needed;
+ if (needed)
+ return 1;
+
+ auto_threshold = (gc_warn_auto_threshold + 255) / 256;
+ if (num_loose > auto_threshold)
+ warning(_("Too many loose objects. \"git gc\" will soon run automatically"));
+ return 0;
}
static int too_many_packs(void)
@@ -141,7 +151,12 @@ static int too_many_packs(void)
*/
cnt++;
}
- return gc_auto_pack_limit <= cnt;
+ if (gc_auto_pack_limit <= cnt)
+ return 1;
+
+ if (gc_warn_auto_pack_limit <= cnt)
+ warning(_("Too many packs, \"git gc\" will soon run automatically."));
+ return 0;
}
static int need_to_gc(void)
--
1.7.4.74.g639db
^ permalink raw reply related
* Re: aliases causing “Permission denied” error in git v1.7
From: Алексей Данченков @ 2011-11-05 11:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vhb2jbopp.fsf@alter.siamese.dyndns.org>
Thank you very much, Jeff and Junio!
Not only I discovered more than one directory mentioned in the $PATH,
but missing, but also learned a lot, including the strace tool.
Cheers, Alexei
2011/11/5 Junio C Hamano <gitster@pobox.com>:
> Jeff King <peff@peff.net> writes:
>
> I do not know why my response is not showing up in the list archive, but
> the complaint was that "git co" works for him and "sudo git co" does not.
>
> I suspect that Alexsey will see differences between these:
>
> $ sh -c 'echo $PATH $HOME'
> $ sudo sh -c 'echo $PATH $HOME'
>
> Most likely, the latter would say /root/bin and /root; if an element in
> the $PATH is unreadable, git would say "cannot exec 'git-co': Permission denied".
>
>
>
^ permalink raw reply
* [PATCH] prune: show progress while marking reachable objects
From: Nguyễn Thái Ngọc Duy @ 2011-11-05 12:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Nguyễn Thái Ngọc Duy
prune already shows progress meter while pruning. The marking part may
take a few seconds or more, depending on repository size. Show
progress meter during this time too.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/prune.c | 6 +++++-
builtin/reflog.c | 2 +-
reachable.c | 14 ++++++++++----
reachable.h | 3 ++-
4 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/builtin/prune.c b/builtin/prune.c
index e65690b..6b39d3f 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -5,6 +5,7 @@
#include "builtin.h"
#include "reachable.h"
#include "parse-options.h"
+#include "progress.h"
#include "dir.h"
static const char * const prune_usage[] = {
@@ -124,6 +125,7 @@ static void remove_temporary_files(const char *path)
int cmd_prune(int argc, const char **argv, const char *prefix)
{
struct rev_info revs;
+ struct progress *progress;
const struct option options[] = {
OPT__DRY_RUN(&show_only, "do not remove, show only"),
OPT__VERBOSE(&verbose, "report pruned objects"),
@@ -152,7 +154,9 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
else
die("unrecognized argument: %s", name);
}
- mark_reachable_objects(&revs, 1);
+ progress = start_progress_delay("Checking connectivity", 0, 0, 2);
+ mark_reachable_objects(&revs, 1, progress);
+ stop_progress(&progress);
prune_object_dir(get_object_directory());
prune_packed_objects(show_only);
diff --git a/builtin/reflog.c b/builtin/reflog.c
index 3a9c80f..062d7da 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -647,7 +647,7 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)
init_revisions(&cb.revs, prefix);
if (cb.verbose)
printf("Marking reachable objects...");
- mark_reachable_objects(&cb.revs, 0);
+ mark_reachable_objects(&cb.revs, 0, NULL);
if (cb.verbose)
putchar('\n');
}
diff --git a/reachable.c b/reachable.c
index 3fc6b1d..293d37d 100644
--- a/reachable.c
+++ b/reachable.c
@@ -7,6 +7,7 @@
#include "revision.h"
#include "reachable.h"
#include "cache-tree.h"
+#include "progress.h"
static void process_blob(struct blob *blob,
struct object_array *p,
@@ -81,21 +82,25 @@ static void process_tag(struct tag *tag, struct object_array *p, const char *nam
add_object(tag->tagged, p, NULL, name);
}
-static void walk_commit_list(struct rev_info *revs)
+static void walk_commit_list(struct rev_info *revs, struct progress *progress)
{
int i;
struct commit *commit;
struct object_array objects = OBJECT_ARRAY_INIT;
+ uint32_t count = 0;
/* Walk all commits, process their trees */
- while ((commit = get_revision(revs)) != NULL)
+ while ((commit = get_revision(revs)) != NULL) {
process_tree(commit->tree, &objects, NULL, "");
+ display_progress(progress, ++count);
+ }
/* Then walk all the pending objects, recursively processing them too */
for (i = 0; i < revs->pending.nr; i++) {
struct object_array_entry *pending = revs->pending.objects + i;
struct object *obj = pending->item;
const char *name = pending->name;
+ display_progress(progress, ++count);
if (obj->type == OBJ_TAG) {
process_tag((struct tag *) obj, &objects, name);
continue;
@@ -191,7 +196,8 @@ static void add_cache_refs(struct rev_info *revs)
add_cache_tree(active_cache_tree, revs);
}
-void mark_reachable_objects(struct rev_info *revs, int mark_reflog)
+void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
+ struct progress *progress)
{
/*
* Set up revision parsing, and mark us as being interested
@@ -217,5 +223,5 @@ void mark_reachable_objects(struct rev_info *revs, int mark_reflog)
*/
if (prepare_revision_walk(revs))
die("revision walk setup failed");
- walk_commit_list(revs);
+ walk_commit_list(revs, progress);
}
diff --git a/reachable.h b/reachable.h
index 4075181..5d082ad 100644
--- a/reachable.h
+++ b/reachable.h
@@ -1,6 +1,7 @@
#ifndef REACHEABLE_H
#define REACHEABLE_H
-extern void mark_reachable_objects(struct rev_info *revs, int mark_reflog);
+struct progress;
+extern void mark_reachable_objects(struct rev_info *revs, int mark_reflog, struct progress *);
#endif
--
1.7.4.74.g639db
^ permalink raw reply related
* [PATCH] Add abbreviated commit hash to rebase conflict message
From: Sverre Rabbelier @ 2011-11-05 14:02 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason, Jonas Flodén,
Junio C Hamano, Eric Herman
Cc: Sverre Rabbelier
Also move the $msgnum to a more sensible location.
Before:
Patch failed at 0001 msg
After:
Patch 0001 failed at [da65151] msg
Reviewed-by: Eric Herman <eric@freesa.org>
Reviewed-by: Fernando Vezzosi <buccia@repnz.net>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
git-am.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 9042432..9d70588 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -837,7 +837,8 @@ did you forget to use 'git add'?"
fi
if test $apply_status != 0
then
- eval_gettextln 'Patch failed at $msgnum $FIRSTLINE'
+ abbrev_commit=$(git log -1 --pretty=%h $commit)
+ eval_gettextln 'Patch $msgnum failed at [$abbrev_commit] $FIRSTLINE'
stop_here_user_resolve $this
fi
--
1.7.8.rc0.36.g67522.dirty
^ permalink raw reply related
* [PATCH] grep: detect number of CPUs for thread spawning
From: Ævar Arnfjörð Bjarmason @ 2011-11-05 14:16 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Eric Herman, Sverre Rabbelier, Fernando Vezzosi,
Ævar Arnfjörð Bjarmason
From: Eric Herman <eric@freesa.org>
Change the number of threads that we spawn from a hardcoded value of
"8" to what online_cpus() returns.
Back in v1.7.0-rc1~19^2 when threaded grep was introduced the number
of threads was hardcoded at compile time to 8, but this value was only
used if online_cpus() returned greater than 1.
However just using 8 threads regardless of the actual number of CPUs
is inefficient if we have more than 8 CPUs, and potentially wasteful
if we have fewer than 8 CPUs.
The array holding the threads is now being allocated at runtime
instead of being allocated statically. We free the array further down
the line in the wait_all() function; this is OK since the allocation
and freeing is guarded by the global "use_threads" variable, which is
based on the return value of online_cpus().
Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com>
Reviewed-by: Fernando Vezzosi <buccia@repnz.net>
Signed-off-by: Eric Herman <eric@freesa.org>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
builtin/grep.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 3d7329d..307a253 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -27,8 +27,8 @@ static char const * const grep_usage[] = {
static int use_threads = 1;
#ifndef NO_PTHREADS
-#define THREADS 8
-static pthread_t threads[THREADS];
+static int nthreads;
+static pthread_t *threads;
static void *load_sha1(const unsigned char *sha1, unsigned long *size,
const char *name);
@@ -36,7 +36,7 @@ static void *load_file(const char *filename, size_t *sz);
enum work_type {WORK_SHA1, WORK_FILE};
-/* We use one producer thread and THREADS consumer
+/* We use one producer thread and online_cpus() consumer
* threads. The producer adds struct work_items to 'todo' and the
* consumers pick work items from the same array.
*/
@@ -254,6 +254,8 @@ static void start_threads(struct grep_opt *opt)
{
int i;
+ threads = xmalloc(nthreads * sizeof(pthread_t));
+
pthread_mutex_init(&grep_mutex, NULL);
pthread_mutex_init(&read_sha1_mutex, NULL);
pthread_cond_init(&cond_add, NULL);
@@ -264,7 +266,7 @@ static void start_threads(struct grep_opt *opt)
strbuf_init(&todo[i].out, 0);
}
- for (i = 0; i < ARRAY_SIZE(threads); i++) {
+ for (i = 0; i < nthreads; i++) {
int err;
struct grep_opt *o = grep_opt_dup(opt);
o->output = strbuf_out;
@@ -295,7 +297,7 @@ static int wait_all(void)
pthread_cond_broadcast(&cond_add);
grep_unlock();
- for (i = 0; i < ARRAY_SIZE(threads); i++) {
+ for (i = 0; i < nthreads; i++) {
void *h;
pthread_join(threads[i], &h);
hit |= (int) (intptr_t) h;
@@ -307,6 +309,8 @@ static int wait_all(void)
pthread_cond_destroy(&cond_write);
pthread_cond_destroy(&cond_result);
+ free(threads);
+
return hit;
}
#else /* !NO_PTHREADS */
@@ -1001,7 +1005,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
opt.regflags |= REG_ICASE;
#ifndef NO_PTHREADS
- if (online_cpus() == 1 || !grep_threads_ok(&opt))
+ nthreads = online_cpus();
+ if (nthreads == 1 || !grep_threads_ok(&opt))
use_threads = 0;
if (use_threads) {
--
1.7.7
^ permalink raw reply related
* [PATCH] Introduce gc.autowarnonly config option
From: Fernando Vezzosi @ 2011-11-05 13:39 UTC (permalink / raw)
To: git
When `git gc --auto` would detect need for garbage collection to run, it
would just run. With this patch, enabling gc.autowarnonly will instead
make it just emit a warning.
Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Fernando Vezzosi <buccia@repnz.net>
---
builtin/gc.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 0498094..65b6616 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -26,6 +26,7 @@ static int pack_refs = 1;
static int aggressive_window = 250;
static int gc_auto_threshold = 6700;
static int gc_auto_pack_limit = 50;
+static int gc_auto_warn_only = 0;
static const char *prune_expire = "2.weeks.ago";
#define MAX_ADD 10
@@ -64,6 +65,10 @@ static int gc_config(const char *var, const char *value, void *cb)
}
return git_config_string(&prune_expire, var, value);
}
+ if (!strcmp(var, "gc.autowarnonly")) {
+ gc_auto_warn_only = git_config_bool(var, value);
+ return 0;
+ }
return git_default_config(var, value, cb);
}
@@ -219,6 +224,15 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
*/
if (!need_to_gc())
return 0;
+
+ if (gc_auto_warn_only){
+ fprintf(stderr,
+ _("Pack the repository for optimum performance by running\n"
+ "\"git gc\" manually. See "
+ "\"git help gc\" for more information.\n"));
+ return 0;
+ }
+
if (quiet)
fprintf(stderr, _("Auto packing the repository for optimum performance.\n"));
else
--
1.7.5.3
^ permalink raw reply related
* Re: [PATCH] Introduce gc.autowarnonly config option
From: Sverre Rabbelier @ 2011-11-05 14:22 UTC (permalink / raw)
To: Fernando Vezzosi, Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20111105140529.3A6CE9004A@inscatolati.net>
Heya,
On Sat, Nov 5, 2011 at 14:39, Fernando Vezzosi <buccia@repnz.net> wrote:
> When `git gc --auto` would detect need for garbage collection to run, it
> would just run. With this patch, enabling gc.autowarnonly will instead
> make it just emit a warning.
>
> Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com>
> Signed-off-by: Fernando Vezzosi <buccia@repnz.net>
Highly relevant considering recent (3 hours ago) patch that instead
adds a warning that gc will happen soon.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH 2/1] gc --auto: warn gc will soon run, give users a chance to run manually
From: Fernando Vezzosi @ 2011-11-05 10:33 UTC (permalink / raw)
To: git
In-Reply-To: <20111105140529.3A6CE9004A@inscatolati.net>
Signed-off-by: Fernando Vezzosi <buccia@repnz.net>
---
Rebased Nguyễn's patch on top of mine.
builtin/gc.c | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 65b6616..ca620e3 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -25,8 +25,10 @@ static const char * const builtin_gc_usage[] = {
static int pack_refs = 1;
static int aggressive_window = 250;
static int gc_auto_threshold = 6700;
+static int gc_warn_auto_threshold = 6600;
static int gc_auto_pack_limit = 50;
static int gc_auto_warn_only = 0;
+static int gc_warn_auto_pack_limit = 45;
static const char *prune_expire = "2.weeks.ago";
#define MAX_ADD 10
@@ -51,10 +53,12 @@ static int gc_config(const char *var, const char *value, void *cb)
}
if (!strcmp(var, "gc.auto")) {
gc_auto_threshold = git_config_int(var, value);
+ gc_warn_auto_threshold = gc_auto_threshold - 100;
return 0;
}
if (!strcmp(var, "gc.autopacklimit")) {
gc_auto_pack_limit = git_config_int(var, value);
+ gc_warn_auto_pack_limit = gc_auto_pack_limit - 5;
return 0;
}
if (!strcmp(var, "gc.pruneexpire")) {
@@ -123,7 +127,13 @@ static int too_many_loose_objects(void)
}
}
closedir(dir);
- return needed;
+ if (needed)
+ return 1;
+
+ auto_threshold = (gc_warn_auto_threshold + 255) / 256;
+ if (num_loose > auto_threshold)
+ warning(_("Too many loose objects. \"git gc\" will soon run automatically"));
+ return 0;
}
static int too_many_packs(void)
@@ -146,7 +156,12 @@ static int too_many_packs(void)
*/
cnt++;
}
- return gc_auto_pack_limit <= cnt;
+ if (gc_auto_pack_limit <= cnt)
+ return 1;
+
+ if (gc_warn_auto_pack_limit <= cnt)
+ warning(_("Too many packs, \"git gc\" will soon run automatically."));
+ return 0;
}
static int need_to_gc(void)
--
1.7.5.3
^ permalink raw reply related
* [PATCH] pull: introduce a pull.rebase option to enable --rebase
From: Ævar Arnfjörð Bjarmason @ 2011-11-05 15:35 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Eric Herman, Sverre Rabbelier, Fernando Vezzosi,
Johannes Schindelin, Ævar Arnfjörð Bjarmason
Currently we either need to set branch.<name>.rebase for existing
branches if we'd like "git pull" to mean "git pull --rebase", or have
the forethought of setting "branch.autosetuprebase" before we create
the branch.
But there's no way to globally configure "git pull" to mean "git pull
--rebase" for existing branches, introduce a "pull.rebase" option to
do that.
This option will be considered at a lower priority than
branch.<name>.rebase, i.e. we could set pull.rebase=true and
branch.<name>.rebase=false and the latter configuration option would
win.
Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com>
Reviewed-by: Fernando Vezzosi <buccia@repnz.net>
Reviewed-by: Eric Herman <eric@freesa.org>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
Documentation/config.txt | 14 +++++++++++++-
Documentation/git-pull.txt | 2 +-
git-pull.sh | 4 ++++
t/t5520-pull.sh | 24 ++++++++++++++++++++++--
4 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5a841da..b2d7d92 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -677,7 +677,9 @@ branch.<name>.mergeoptions::
branch.<name>.rebase::
When true, rebase the branch <name> on top of the fetched branch,
instead of merging the default branch from the default remote when
- "git pull" is run.
+ "git pull" is run. See "pull.rebase" for doing this in a non
+ branch-specific manner.
+
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand the implications (see linkgit:git-rebase[1]
for details).
@@ -1590,6 +1592,16 @@ pretty.<name>::
Note that an alias with the same name as a built-in format
will be silently ignored.
+pull.rebase::
+ When true, rebase branches on top of the fetched branch, instead
+ of merging the default branch from the default remote when "git
+ pull" is run. See "branch.<name>.rebase" for setting this on a
+ per-branch basis.
+
+ *NOTE*: this is a possibly dangerous operation; do *not* use
+ it unless you understand the implications (see linkgit:git-rebase[1]
+ for details).
+
pull.octopus::
The default merge strategy to use when pulling multiple branches
at once.
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index e1da468..0f18ec8 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -108,7 +108,7 @@ include::merge-options.txt[]
fetched, the rebase uses that information to avoid rebasing
non-local changes.
+
-See `branch.<name>.rebase` and `branch.autosetuprebase` in
+See `pull.rebase`, `branch.<name>.rebase` and `branch.autosetuprebase` in
linkgit:git-config[1] if you want to make `git pull` always use
`{litdd}rebase` instead of merging.
+
diff --git a/git-pull.sh b/git-pull.sh
index 9868a0b..24b6b7c 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -44,6 +44,10 @@ merge_args=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short="${curr_branch#refs/heads/}"
rebase=$(git config --bool branch.$curr_branch_short.rebase)
+if test -z "$rebase"
+then
+ rebase=$(git config --bool pull.rebase)
+fi
dry_run=
while :
do
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 0e5eb67..ecc4fdc 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -94,16 +94,36 @@ test_expect_success '--rebase' '
test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
test new = $(git show HEAD:file2)
'
+test_expect_success 'pull.rebase' '
+ git reset --hard before-rebase &&
+ git config --bool pull.rebase true &&
+ test_when_finished "git config --unset pull.rebase" &&
+ git pull . copy &&
+ test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
+ test new = $(git show HEAD:file2)
+'
test_expect_success 'branch.to-rebase.rebase' '
git reset --hard before-rebase &&
- git config branch.to-rebase.rebase 1 &&
+ git config --bool branch.to-rebase.rebase true &&
+ test_when_finished "git config --unset branch.to-rebase.rebase" &&
git pull . copy &&
- git config branch.to-rebase.rebase 0 &&
test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
test new = $(git show HEAD:file2)
'
+test_expect_success 'branch.to-rebase.rebase should override pull.rebase' '
+ git reset --hard before-rebase &&
+ git config --bool pull.rebase true &&
+ test_when_finished "git config --unset pull.rebase" &&
+ git config --bool branch.to-rebase.rebase false &&
+ test_when_finished "git config --unset branch.to-rebase.rebase" &&
+ git pull . copy &&
+ git config --unset branch.to-rebase.rebase &&
+ test $(git rev-parse HEAD^) != $(git rev-parse copy) &&
+ test new = $(git show HEAD:file2)
+'
+
test_expect_success '--rebase with rebased upstream' '
git remote add -f me . &&
--
1.7.7
^ permalink raw reply related
* [PATCH na/strtoimax] Compatibility: declare strtoimax() under NO_STRTOUMAX
From: Johannes Sixt @ 2011-11-05 15:37 UTC (permalink / raw)
To: Nick Alcock; +Cc: Junio C Hamano, Git Mailing List
Commit f696543d (Add strtoimax() compatibility function) introduced an
implementation of the function, but forgot to add a declaration.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
git-compat-util.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index feb6f8e..4efef46 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -354,6 +354,8 @@ extern size_t gitstrlcpy(char *, const char *, size_t);
#ifdef NO_STRTOUMAX
#define strtoumax gitstrtoumax
extern uintmax_t gitstrtoumax(const char *, char **, int);
+#define strtoimax gitstrtoimax
+extern intmax_t gitstrtoimax(const char *, char **, int);
#endif
#ifdef NO_STRTOK_R
--
1.7.7.1.1608.gd424d
^ permalink raw reply related
* [PATCH 2/1] gc --auto: warn gc will soon run, give users a chance to run manually
From: Fernando Vezzosi @ 2011-11-05 10:33 UTC (permalink / raw)
To: git
In-Reply-To: <20111105140529.3A6CE9004A@inscatolati.net>
Signed-off-by: Fernando Vezzosi <buccia@repnz.net>
---
Rebased Nguyễn's patch on top of mine.
builtin/gc.c | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 65b6616..ca620e3 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -25,8 +25,10 @@ static const char * const builtin_gc_usage[] = {
static int pack_refs = 1;
static int aggressive_window = 250;
static int gc_auto_threshold = 6700;
+static int gc_warn_auto_threshold = 6600;
static int gc_auto_pack_limit = 50;
static int gc_auto_warn_only = 0;
+static int gc_warn_auto_pack_limit = 45;
static const char *prune_expire = "2.weeks.ago";
#define MAX_ADD 10
@@ -51,10 +53,12 @@ static int gc_config(const char *var, const char *value, void *cb)
}
if (!strcmp(var, "gc.auto")) {
gc_auto_threshold = git_config_int(var, value);
+ gc_warn_auto_threshold = gc_auto_threshold - 100;
return 0;
}
if (!strcmp(var, "gc.autopacklimit")) {
gc_auto_pack_limit = git_config_int(var, value);
+ gc_warn_auto_pack_limit = gc_auto_pack_limit - 5;
return 0;
}
if (!strcmp(var, "gc.pruneexpire")) {
@@ -123,7 +127,13 @@ static int too_many_loose_objects(void)
}
}
closedir(dir);
- return needed;
+ if (needed)
+ return 1;
+
+ auto_threshold = (gc_warn_auto_threshold + 255) / 256;
+ if (num_loose > auto_threshold)
+ warning(_("Too many loose objects. \"git gc\" will soon run automatically"));
+ return 0;
}
static int too_many_packs(void)
@@ -146,7 +156,12 @@ static int too_many_packs(void)
*/
cnt++;
}
- return gc_auto_pack_limit <= cnt;
+ if (gc_auto_pack_limit <= cnt)
+ return 1;
+
+ if (gc_warn_auto_pack_limit <= cnt)
+ warning(_("Too many packs, \"git gc\" will soon run automatically."));
+ return 0;
}
static int need_to_gc(void)
--
1.7.5.3
^ permalink raw reply related
* Re: [PATCH] pull: introduce a pull.rebase option to enable --rebase
From: Johannes Schindelin @ 2011-11-05 15:55 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Eric Herman, Sverre Rabbelier,
Fernando Vezzosi
In-Reply-To: <1320507358-3407-1-git-send-email-avarab@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 674 bytes --]
Hi,
On Sat, 5 Nov 2011, Ævar Arnfjörð Bjarmason wrote:
> Currently we either need to set branch.<name>.rebase for existing
> branches if we'd like "git pull" to mean "git pull --rebase", or have
> the forethought of setting "branch.autosetuprebase" before we create the
> branch.
>
> But there's no way to globally configure "git pull" to mean "git pull
> --rebase" for existing branches, introduce a "pull.rebase" option to do
> that.
>
> This option will be considered at a lower priority than
> branch.<name>.rebase, i.e. we could set pull.rebase=true and
> branch.<name>.rebase=false and the latter configuration option would
> win.
Nice.
Ciao,
Johannes
^ permalink raw reply
* Re: share object storage for multiple clones of different repositories
From: Gelonida N @ 2011-11-05 16:06 UTC (permalink / raw)
To: git
In-Reply-To: <op.v4gp4mai0aolir@keputer.lokaal>
Thanks for both of your replies,
I'll probably mix both approaches and try out how it works.
I didn't know about git.git
What is the best url for an intrudoction into git.git?
On 11/05/2011 08:37 AM, Frans Klaver wrote:
> On Sat, 05 Nov 2011 03:26:11 +0100, Junio C Hamano <gitster@pobox.com>
> wrote:
>
>> Gelonida N <gelonida@gmail.com> writes:
>>
>>> SHARED_STORAGE=$HOME/shared_storage
>>> mkdir $SHARED_STORAGE
>>>
>>> git clone remotehost1:repo1
>>> cd repo1
>>> rsync -av .git/objects $SHARED_REPO
>>
>> Up to this part it is probably OK. Repeat that for all your local
>> repositories to collect all objects in $HOME/shared_storage.
>>
>> After doing that, do this in all of your local repositories:
>>
>> rm -rf .git/objects
>> mkdir -p .git/objects/info
>> echo $HOME/shared/storage >.git/objects/info/alternates
>>
>> The reason why nobody should follow your original recipe is because any
>> "git gc"/"git repack" in any of your local repositories would break
>> others
>> with that approach.
>
>
> Alternatively there's the git-new-workdir script in contrib/workdir in
> git.git. Haven't tested it, but it seems like it does what you want.
>
> Frans
^ permalink raw reply
* Re: share object storage for multiple clones of different repositories
From: Gelonida N @ 2011-11-05 16:20 UTC (permalink / raw)
To: git
In-Reply-To: <j93mu2$ce7$1@dough.gmane.org>
On 11/05/2011 05:06 PM, Gelonida N wrote:
> Thanks for both of your replies,
>
>
> I'll probably mix both approaches and try out how it works.
> I didn't know about git.git
> What is the best url for an intrudoction into git.git?
>
>
>>
>> Alternatively there's the git-new-workdir script in contrib/workdir in
>> git.git. Haven't tested it, but it seems like it does what you want.
>>
>> Frans
>
>
In an installed git (at least on Ubuntu) the contrib directory can be
found at /usr/share/doc/git/contrib
^ permalink raw reply
* Re: [PATCH na/strtoimax] Compatibility: declare strtoimax() under NO_STRTOUMAX
From: Nix @ 2011-11-05 15:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4EB5583E.2030306@kdbg.org>
On 5 Nov 2011, Johannes Sixt said:
> Commit f696543d (Add strtoimax() compatibility function) introduced an
> implementation of the function, but forgot to add a declaration.
Oh, my apologies. (How did my testing miss that? No -Wall, I bet.)
--
NULL && (void)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox