Re: [PATCH v4] MinGW(-W64) compilation

2014-10-05 Thread Marat Radchenko
On Tue, Sep 30, 2014 at 11:02:29AM +0400, Marat Radchenko wrote:
> This patch series fixes building on modern MinGW and MinGW-W64 (including 
> x86_64!).

Junio, ping?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/16] make prune mtime-checking more careful

2014-10-05 Thread Jeff King
On Sat, Oct 04, 2014 at 03:22:10PM -0700, Junio C Hamano wrote:

> This applied on top of 'maint' (which does have c40fdd01) makes the
> test #9 (prune: do not prune detached HEAD with no reflog) fail.

I'll fix the bone-headed error returns that René noticed and double
check that they were the complete culprit in the test failure you saw
(and not just masking some other problem).

> If we merge 'dt/cache-tree-repair' (which in turn needs
> 'jc/reopen-lock-file') to 'maint' and then apply these on top, the
> said test passes.  But I do not see an apparent reason why X-<.

I suspect it's an unintended interaction that just happens to let my
bogus code code the right thing, but I'll double check on that, too.

Thanks both of you for spotting the problems.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] use skip_prefix() to avoid more magic numbers

2014-10-05 Thread Jeff King
On Sat, Oct 04, 2014 at 08:54:50PM +0200, René Scharfe wrote:

> Continue where ae021d87 (use skip_prefix to avoid magic numbers) left off
> and use skip_prefix() in more places for determining the lengths of prefix
> strings to avoid using dependent constants and other indirect methods.

Thanks, these all look like nice improvements. I think both of the
suggestions made my Jonathan are good on top, though.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] use skip_prefix() to avoid more magic numbers

2014-10-05 Thread Jeff King
On Sun, Oct 05, 2014 at 03:49:19PM -0700, Jonathan Nieder wrote:

> > --- a/builtin/branch.c
> > +++ b/builtin/branch.c
> > @@ -81,14 +81,16 @@ static int parse_branch_color_slot(const char *var, int 
> > ofs)
> >  
> >  static int git_branch_config(const char *var, const char *value, void *cb)
> >  {
> > +   const char *slot_name;
> > +
> > if (starts_with(var, "column."))
> > return git_column_config(var, value, "branch", &colopts);
> > if (!strcmp(var, "color.branch")) {
> > branch_use_color = git_config_colorbool(var, value);
> > return 0;
> > }
> > -   if (starts_with(var, "color.branch.")) {
> > -   int slot = parse_branch_color_slot(var, 13);
> > +   if (skip_prefix(var, "color.branch.", &slot_name)) {
> > +   int slot = parse_branch_color_slot(var, slot_name - var);
> 
> I wonder why the separate var and offset parameters exist in the first
> place.  Wouldn't taking a single const char * so the old code could use
> 'var + 13' instead of 'var, 13' have worked?

I think this is in the same boat as parse_diff_color_slot, which I fixed
in 9e1a5eb (parse_diff_color_slot: drop ofs parameter, 2014-06-18). The
short of it is that the function used to want both the full name and the
slot name, but now needs only the latter.

The fix you proposed below is along the same line, and looks good to me
(and grepping for 'var *+ *ofs' shows only the two sites you found, so
hopefully that is the last of it).

> > @@ -809,18 +808,19 @@ static void parse_commit_header(struct 
> > format_commit_context *context)
> > int i;
> >  
> > for (i = 0; msg[i]; i++) {
> > +   const char *name;
> 
> ident instead of name, maybe? (since it's a 'name  timestamp'
> field)

Yeah, agreed.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] use skip_prefix() to avoid more magic numbers

2014-10-05 Thread Jonathan Nieder
René Scharfe wrote:

> Continue where ae021d87 (use skip_prefix to avoid magic numbers) left off
> and use skip_prefix() in more places for determining the lengths of prefix
> strings to avoid using dependent constants and other indirect methods.

Sounds promising.

[...]
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -81,14 +81,16 @@ static int parse_branch_color_slot(const char *var, int 
> ofs)
>  
>  static int git_branch_config(const char *var, const char *value, void *cb)
>  {
> + const char *slot_name;
> +
>   if (starts_with(var, "column."))
>   return git_column_config(var, value, "branch", &colopts);
>   if (!strcmp(var, "color.branch")) {
>   branch_use_color = git_config_colorbool(var, value);
>   return 0;
>   }
> - if (starts_with(var, "color.branch.")) {
> - int slot = parse_branch_color_slot(var, 13);
> + if (skip_prefix(var, "color.branch.", &slot_name)) {
> + int slot = parse_branch_color_slot(var, slot_name - var);

I wonder why the separate var and offset parameters exist in the first
place.  Wouldn't taking a single const char * so the old code could use
'var + 13' instead of 'var, 13' have worked?

At first glance I thought this should be

int slot = parse_branch_color_slot(slot_name, 0);

to be simpler.  At second glance, how about something like the following
on top?

[...]
> --- a/builtin/log.c
> +++ b/builtin/log.c
[...]
> @@ -388,8 +390,8 @@ static int git_log_config(const char *var, const char 
> *value, void *cb)
>   default_show_root = git_config_bool(var, value);
>   return 0;
>   }
> - if (starts_with(var, "color.decorate."))
> - return parse_decorate_color_config(var, 15, value);
> + if (skip_prefix(var, "color.decorate.", &slot_name))
> + return parse_decorate_color_config(var, slot_name - var, value);

Likewise: the offset-based API seems odd now here, too.

[...]
> --- a/pretty.c
> +++ b/pretty.c
[...]
> @@ -809,18 +808,19 @@ static void parse_commit_header(struct 
> format_commit_context *context)
>   int i;
>  
>   for (i = 0; msg[i]; i++) {
> + const char *name;

ident instead of name, maybe? (since it's a 'name  timestamp'
field)

[...]
> @@ -1522,7 +1518,7 @@ static void pp_header(struct pretty_print_context *pp,
>   int parents_shown = 0;
>  
>   for (;;) {
> - const char *line = *msg_p;
> + const char *name, *line = *msg_p;

Likewise.

With or without the changes below,
Reviewed-by: Jonathan Nieder 

diff --git i/builtin/branch.c w/builtin/branch.c
index 6785097..022a88e 100644
--- i/builtin/branch.c
+++ w/builtin/branch.c
@@ -62,19 +62,19 @@ static unsigned char merge_filter_ref[20];
 static struct string_list output = STRING_LIST_INIT_DUP;
 static unsigned int colopts;
 
-static int parse_branch_color_slot(const char *var, int ofs)
+static int parse_branch_color_slot(const char *slot)
 {
-   if (!strcasecmp(var+ofs, "plain"))
+   if (!strcasecmp(slot, "plain"))
return BRANCH_COLOR_PLAIN;
-   if (!strcasecmp(var+ofs, "reset"))
+   if (!strcasecmp(slot, "reset"))
return BRANCH_COLOR_RESET;
-   if (!strcasecmp(var+ofs, "remote"))
+   if (!strcasecmp(slot, "remote"))
return BRANCH_COLOR_REMOTE;
-   if (!strcasecmp(var+ofs, "local"))
+   if (!strcasecmp(slot, "local"))
return BRANCH_COLOR_LOCAL;
-   if (!strcasecmp(var+ofs, "current"))
+   if (!strcasecmp(slot, "current"))
return BRANCH_COLOR_CURRENT;
-   if (!strcasecmp(var+ofs, "upstream"))
+   if (!strcasecmp(slot, "upstream"))
return BRANCH_COLOR_UPSTREAM;
return -1;
 }
@@ -90,7 +90,7 @@ static int git_branch_config(const char *var, const char 
*value, void *cb)
return 0;
}
if (skip_prefix(var, "color.branch.", &slot_name)) {
-   int slot = parse_branch_color_slot(var, slot_name - var);
+   int slot = parse_branch_color_slot(slot_name);
if (slot < 0)
return 0;
if (!value)
diff --git i/builtin/log.c w/builtin/log.c
index 1202eba..68d5d30 100644
--- i/builtin/log.c
+++ w/builtin/log.c
@@ -391,7 +391,7 @@ static int git_log_config(const char *var, const char 
*value, void *cb)
return 0;
}
if (skip_prefix(var, "color.decorate.", &slot_name))
-   return parse_decorate_color_config(var, slot_name - var, value);
+   return parse_decorate_color_config(var, slot_name, value);
if (!strcmp(var, "log.mailmap")) {
use_mailmap_config = git_config_bool(var, value);
return 0;
diff --git i/log-tree.c w/log-tree.c
index cff7ac1..6402c19 100644
--- i/log-tree.c
+++ w/log-tree.c
@@ -56,9 +56,9 @@ static int parse_decorate_color_slot(const char *slot)
retur

Re: Can I fetch an arbitrary commit by sha1?

2014-10-05 Thread Christian Halstrick
I also like the feature of being able to fetch commits by SHA-1. My
problem is that it is not clear to end users whether they can fetch
SHA-1 from a specific server or not. For exactly the same server a
"git fetch origin " first doesn't work and all of the
sudden that command works and updates e.g. FETCH_HEAD. That's because
between the first and the second fetch you fetched that commit already
by fetching a branch.

And even if the commit is known only to the local repo then the fetch
works. I tried to fetch a commit which I just created locally. And the
output is:

> git fetch eclipse 382dfeab0e11bd88388d7195114c046c3ec27d8f
>From https://git.eclipse.org/r/jgit/jgit
 * branch382dfeab0e11bd88388d7195114c046c3ec27d8f -> FETCH_HEAD

This gives me the impression that that update was triggered by data
coming from the server https://git.eclipse.org/r/jgit/jgit. But the
server doesn't know the commit. In my eyes the fetch should fail if
the server doesn't know the commit.

Ciao
  Chris
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


gitk: sizing on history panels after maximize + restore

2014-10-05 Thread Martin Matusiak
Hi,

I think gitk is great, but I have a small annoyance with it.

As it starts up the three history panels in the top half of the screen
have the same width.

After maximizing the window they all get wider and still have the same
width as each other (scaled up proportionally, which makes sense).

But after restoring/unmaximizing the left and right panels are more
than 1/3 wide and the middle panel (author) is squashed between them.

This is on Ubuntu 14.04 trusty, but I've observed this behavior now
for years (just never actually reported it).


Martin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[no subject]

2014-10-05 Thread Personal Charity



We have a private donation for you

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[bug] [UX] `stash save --untracked` produces a stash that *looks* empty

2014-10-05 Thread Alberto Scotto
Hi all,

I've just found that:
- given you have an empty staging area
- and you have only untracked files in your working dir
- when you do `git stash --untracked`
- then `git stash show` gives you an empty output => stash looks empty

My first thought was "oh god, my files are lost!"
Second thought: "Jeez I found a bug in git! cool!"
Then I found that actually `git stash apply` restores the apparently lost
files
So I think it's a UX issue.
It cost me a few lost files already, as I thought "an empty stash? uhm..
can't remember what/when I stashed.. whatever.. let's just delete it and
clean up a little bit this mess of stashes".


Here are the reproducible steps:

   1. create new fresh git repo in $REPO_DIR
   2. create a couple of files/dirs and commit
   3. edit src/MyClass.java and commit
   4. create dir src/new-dir with one file inside
   5. edit file.txt and stage it
   6. stash => stashes staged changes; only untracked files are left
   7. stash -u => stashes untracked changes => working dir is clean
   8. stash list
   9. git stash show -p => empty output
   10. git stash apply (restore stashed untracked files)


I made a bash script that runs through those steps.
Please check it out.
https://gist.github.com/alb-i986/a4002f1ac50ce355278e

Envs:

   - Mac OSX 10.9.5
   - Darwin 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT
  2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64
  - git version 1.9.3 (Apple Git-50)
  - GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
   - Ubuntu precise <-
   https://github.com/alb-i986/vagrantfiles/tree/master/basic
  - Linux precise64 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51
  UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
  - git version 1.7.9.5
  - GNU bash, version 4.2.24(1)-release (x86_64-pc-linux-gnu)


Thank you


Alberto Scotto
http://alb-i986.me
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 12/16] sha1_file: add for_each iterators for loose and packed objects

2014-10-05 Thread Ramsay Jones
On 05/10/14 09:15, René Scharfe wrote:
> Am 03.10.2014 um 22:32 schrieb Jeff King:
>> We typically iterate over the reachable objects in a
>> repository by starting at the tips and walking the graph.
>> There's no easy way to iterate over all of the objects,
>> including unreachable ones. Let's provide a way of doing so.
>>
>> Signed-off-by: Jeff King 
>> ---
>>   cache.h | 11 +++
>>   sha1_file.c | 62 
>> +
>>   2 files changed, 73 insertions(+)
>>
>> diff --git a/cache.h b/cache.h
>> index 7abe7f6..3826b4b 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -1270,6 +1270,17 @@ int for_each_loose_file_in_objdir(const char *path,
>> each_loose_subdir_fn subdir_cb,
>> void *data);
>>
>> +/*
>> + * Iterate over loose and packed objects in both the local
>> + * repository and any alternates repositories.
>> + */
>> +typedef int each_packed_object_fn(const unsigned char *sha1,
>> +  struct packed_git *pack,
>> +  uint32_t pos,
>> +  void *data);
>> +extern int for_each_loose_object(each_loose_object_fn, void *);
>> +extern int for_each_packed_object(each_packed_object_fn, void *);
>> +
>>   struct object_info {
>>   /* Request */
>>   enum object_type *typep;
>> diff --git a/sha1_file.c b/sha1_file.c
>> index 9fdad47..d017289 100644
>> --- a/sha1_file.c
>> +++ b/sha1_file.c
>> @@ -3313,3 +3313,65 @@ int for_each_loose_file_in_objdir(const char *path,
>>   strbuf_release(&buf);
>>   return r;
>>   }
>> +
>> +struct loose_alt_odb_data {
>> +each_loose_object_fn *cb;
>> +void *data;
>> +};
>> +
>> +static int loose_from_alt_odb(struct alternate_object_database *alt,
>> +  void *vdata)
>> +{
>> +struct loose_alt_odb_data *data = vdata;
>> +return for_each_loose_file_in_objdir(alt->base,
>> + data->cb, NULL, NULL,
>> + data->data);
>> +}
>> +
>> +int for_each_loose_object(each_loose_object_fn cb, void *data)
>> +{
>> +struct loose_alt_odb_data alt;
>> +int r;
>> +
>> +r = for_each_loose_file_in_objdir(get_object_directory(),
>> +  cb, NULL, NULL, data);
>> +if (r)
>> +return r;
>> +
>> +alt.cb = cb;
>> +alt.data = data;
>> +return foreach_alt_odb(loose_from_alt_odb, &alt);
>> +}
>> +
>> +int for_each_object_in_pack(struct packed_git *p, each_packed_object_fn cb, 
>> void *data)
> 
> Should this one be declared static?  It seems to be used only in sha1_file.c.

Heh, I was just about to make the same observation myself (with included patch).

I could imagine this function being useful elsewhere, but until it gains some
more external callers I think it should remain static (so it doesn't cause a
sparse warning), rather than add an extern declaration to cache.h (which would
also suppress sparse).

ATB,
Ramsay Jones

> 
>> +{
>> +uint32_t i;
>> +int r = 0;
>> +
>> +for (i = 0; i < p->num_objects; i++) {
>> +const unsigned char *sha1 = nth_packed_object_sha1(p, i);
>> +
>> +if (!sha1)
>> +return error("unable to get sha1 of object %u in %s",
>> + i, p->pack_name);
>> +
>> +r = cb(sha1, p, i, data);
>> +if (r)
>> +break;
>> +}
>> +return r;
>> +}
>> +
>> +int for_each_packed_object(each_packed_object_fn cb, void *data)
>> +{
>> +struct packed_git *p;
>> +int r = 0;
>> +
>> +prepare_packed_git();
>> +for (p = packed_git; p; p = p->next) {
>> +r = for_each_object_in_pack(p, cb, data);
>> +if (r)
>> +break;
>> +}
>> +return 0;
>> +}
> 
> Perhaps return r instead here?
> 
> René
> 
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/16] make prune mtime-checking more careful

2014-10-05 Thread René Scharfe

Am 05.10.2014 um 00:22 schrieb Junio C Hamano:

Jeff King  writes:


There's quite a lot of patches here, but most of them are preparatory
cleanups. The meat is in patches 13, 15, and 16.

   [01/16]: foreach_alt_odb: propagate return value from callback
   [02/16]: isxdigit: cast input to unsigned char
   [03/16]: object_array: factor out slopbuf-freeing logic
   [04/16]: object_array: add a "clear" function
   [05/16]: clean up name allocation in prepare_revision_walk
   [06/16]: reachable: clear pending array after walking it
   [07/16]: t5304: use test_path_is_* instead of "test -f"
   [08/16]: t5304: use helper to report failure of "test foo = bar"
   [09/16]: prune: factor out loose-object directory traversal
   [10/16]: count-objects: do not use xsize_t when counting object size
   [11/16]: count-objects: use for_each_loose_file_in_objdir
   [12/16]: sha1_file: add for_each iterators for loose and packed objects
   [13/16]: prune: keep objects reachable from recent objects
   [14/16]: pack-objects: refactor unpack-unreachable expiration check
   [15/16]: pack-objects: match prune logic for discarding objects
   [16/16]: write_sha1_file: freshen existing objects


Somebody please help me out here.

This applied on top of 'maint' (which does have c40fdd01) makes the
test #9 (prune: do not prune detached HEAD with no reflog) fail.


The test passes if the return value of freshen_file() is negated in 
freshen_packed_object() (see my reply to patch 16).



If we merge 'dt/cache-tree-repair' (which in turn needs
'jc/reopen-lock-file') to 'maint' and then apply these on top, the
said test passes.  But I do not see an apparent reason why X-<.


Didn't check this interaction, but it sounds strange.

René

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 16/16] write_sha1_file: freshen existing objects

2014-10-05 Thread René Scharfe

Am 03.10.2014 um 22:41 schrieb Jeff King:

When we try to write a loose object file, we first check
whether that object already exists. If so, we skip the
write as an optimization. However, this can interfere with
prune's strategy of using mtimes to mark files in progress.

For example, if a branch contains a particular tree object
and is deleted, that tree object may become unreachable, and
have an old mtime. If a new operation then tries to write
the same tree, this ends up as a noop; we notice we
already have the object and do nothing. A prune running
simultaneously with this operation will see the object as
old, and may delete it.

We can solve this by "freshening" objects that we avoid
writing by updating their mtime. The algorithm for doing so
is essentially the same as that of has_sha1_file. Therefore
we provide a new (static) interface "check_and_freshen",
which finds and optionally freshens the object. It's trivial
to implement freshening and simple checking by tweaking a
single parameter.

Signed-off-by: Jeff King 
---
  sha1_file.c| 51 +++---
  t/t6501-freshen-objects.sh | 27 
  2 files changed, 71 insertions(+), 7 deletions(-)

diff --git a/sha1_file.c b/sha1_file.c
index d017289..d263b38 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -442,27 +442,53 @@ void prepare_alt_odb(void)
read_info_alternates(get_object_directory(), 0);
  }

-static int has_loose_object_local(const unsigned char *sha1)
+static int freshen_file(const char *fn)
  {
-   return !access(sha1_file_name(sha1), F_OK);
+   struct utimbuf t;
+   t.actime = t.modtime = time(NULL);
+   return utime(fn, &t);
  }


Mental note: freshen_file() returns 0 on success.



-int has_loose_object_nonlocal(const unsigned char *sha1)
+static int check_and_freshen_file(const char *fn, int freshen)
+{
+   if (access(fn, F_OK))
+   return 0;
+   if (freshen && freshen_file(fn))
+   return 0;
+   return 1;
+}


Returns 1 on success.


+
+static int check_and_freshen_local(const unsigned char *sha1, int freshen)
+{
+   return check_and_freshen_file(sha1_file_name(sha1), freshen);
+}


Returns 1 on success.


+
+static int check_and_freshen_nonlocal(const unsigned char *sha1, int freshen)
  {
struct alternate_object_database *alt;
prepare_alt_odb();
for (alt = alt_odb_list; alt; alt = alt->next) {
fill_sha1_path(alt->name, sha1);
-   if (!access(alt->base, F_OK))
+   if (check_and_freshen_file(alt->base, freshen))
return 1;
}
return 0;
  }


Returns 1 on success.



+static int check_and_freshen(const unsigned char *sha1, int freshen)
+{
+   return check_and_freshen_local(sha1, freshen) ||
+  check_and_freshen_nonlocal(sha1, freshen);
+}


Returns 1 on success.


+
+int has_loose_object_nonlocal(const unsigned char *sha1)
+{
+   return check_and_freshen_nonlocal(sha1, 0);
+}
+
  static int has_loose_object(const unsigned char *sha1)
  {
-   return has_loose_object_local(sha1) ||
-  has_loose_object_nonlocal(sha1);
+   return check_and_freshen(sha1, 0);
  }

  static unsigned int pack_used_ctr;
@@ -2949,6 +2975,17 @@ static int write_loose_object(const unsigned char *sha1, 
char *hdr, int hdrlen,
return move_temp_to_file(tmp_file, filename);
  }

+static int freshen_loose_object(const unsigned char *sha1)
+{
+   return check_and_freshen(sha1, 1);
+}


Returns 1 on success.


+
+static int freshen_packed_object(const unsigned char *sha1)
+{
+   struct pack_entry e;
+   return find_pack_entry(sha1, &e) && freshen_file(e.p->pack_name);
+}


Returns 1 if a pack entry is found and freshen_file() fails, and 0 if no 
entry is found or freshen_file() succeeds.


It should be "&& !freshen(...)" instead, no?

Or better, let freshen_file() return 1 on success as the other functions 
here.



+
  int write_sha1_file(const void *buf, unsigned long len, const char *type, 
unsigned char *returnsha1)
  {
unsigned char sha1[20];
@@ -2961,7 +2998,7 @@ int write_sha1_file(const void *buf, unsigned long len, 
const char *type, unsign
write_sha1_file_prepare(buf, len, type, sha1, hdr, &hdrlen);
if (returnsha1)
hashcpy(returnsha1, sha1);
-   if (has_sha1_file(sha1))
+   if (freshen_loose_object(sha1) || freshen_packed_object(sha1))
return 0;
return write_loose_object(sha1, hdr, hdrlen, buf, len, 0);
  }
diff --git a/t/t6501-freshen-objects.sh b/t/t6501-freshen-objects.sh
index e25c47d..157f3f9 100755
--- a/t/t6501-freshen-objects.sh
+++ b/t/t6501-freshen-objects.sh
@@ -100,6 +100,33 @@ for repack in '' true; do
test_expect_success "repository passes fsck ($title)" '
git fsck
'
+
+   test_expect_success "abandon objects again ($title)" '
+   git reset -

Re: [PATCH 12/16] sha1_file: add for_each iterators for loose and packed objects

2014-10-05 Thread René Scharfe

Am 03.10.2014 um 22:32 schrieb Jeff King:

We typically iterate over the reachable objects in a
repository by starting at the tips and walking the graph.
There's no easy way to iterate over all of the objects,
including unreachable ones. Let's provide a way of doing so.

Signed-off-by: Jeff King 
---
  cache.h | 11 +++
  sha1_file.c | 62 +
  2 files changed, 73 insertions(+)

diff --git a/cache.h b/cache.h
index 7abe7f6..3826b4b 100644
--- a/cache.h
+++ b/cache.h
@@ -1270,6 +1270,17 @@ int for_each_loose_file_in_objdir(const char *path,
  each_loose_subdir_fn subdir_cb,
  void *data);

+/*
+ * Iterate over loose and packed objects in both the local
+ * repository and any alternates repositories.
+ */
+typedef int each_packed_object_fn(const unsigned char *sha1,
+ struct packed_git *pack,
+ uint32_t pos,
+ void *data);
+extern int for_each_loose_object(each_loose_object_fn, void *);
+extern int for_each_packed_object(each_packed_object_fn, void *);
+
  struct object_info {
/* Request */
enum object_type *typep;
diff --git a/sha1_file.c b/sha1_file.c
index 9fdad47..d017289 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -3313,3 +3313,65 @@ int for_each_loose_file_in_objdir(const char *path,
strbuf_release(&buf);
return r;
  }
+
+struct loose_alt_odb_data {
+   each_loose_object_fn *cb;
+   void *data;
+};
+
+static int loose_from_alt_odb(struct alternate_object_database *alt,
+ void *vdata)
+{
+   struct loose_alt_odb_data *data = vdata;
+   return for_each_loose_file_in_objdir(alt->base,
+data->cb, NULL, NULL,
+data->data);
+}
+
+int for_each_loose_object(each_loose_object_fn cb, void *data)
+{
+   struct loose_alt_odb_data alt;
+   int r;
+
+   r = for_each_loose_file_in_objdir(get_object_directory(),
+ cb, NULL, NULL, data);
+   if (r)
+   return r;
+
+   alt.cb = cb;
+   alt.data = data;
+   return foreach_alt_odb(loose_from_alt_odb, &alt);
+}
+
+int for_each_object_in_pack(struct packed_git *p, each_packed_object_fn cb, 
void *data)


Should this one be declared static?  It seems to be used only in 
sha1_file.c.



+{
+   uint32_t i;
+   int r = 0;
+
+   for (i = 0; i < p->num_objects; i++) {
+   const unsigned char *sha1 = nth_packed_object_sha1(p, i);
+
+   if (!sha1)
+   return error("unable to get sha1 of object %u in %s",
+i, p->pack_name);
+
+   r = cb(sha1, p, i, data);
+   if (r)
+   break;
+   }
+   return r;
+}
+
+int for_each_packed_object(each_packed_object_fn cb, void *data)
+{
+   struct packed_git *p;
+   int r = 0;
+
+   prepare_packed_git();
+   for (p = packed_git; p; p = p->next) {
+   r = for_each_object_in_pack(p, cb, data);
+   if (r)
+   break;
+   }
+   return 0;
+}


Perhaps return r instead here?

René


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html