Git development
 help / color / mirror / Atom feed
* Re: How can I force git to recognize a change change in file modes?
From: Jay Soffian @ 2009-02-28 16:52 UTC (permalink / raw)
  To: Brent Goodrick; +Cc: Jan Krüger, git
In-Reply-To: <e38bce640902280824x3ae41d95qab1f1a450235e096@mail.gmail.com>

On Sat, Feb 28, 2009 at 11:24 AM, Brent Goodrick <bgoodr@gmail.com> wrote:
> Thanks Jan.  Was this choice made due to the conditional coding
> required to track the permission bits content between *NIX and
> non-*NIX platform(s)?

The short answer is: because Git was designed to track content. The
long answer is more complicated. Here's one of the more useful past
discussions:

http://thread.gmane.org/gmane.comp.version-control.git/91783

I'm sure you can find others by searching the git list for "metadata".

j.

^ permalink raw reply

* Re: http-push: double free or corruption (!prev): 0x09fedb50
From: Felipe Contreras @ 2009-02-28 16:46 UTC (permalink / raw)
  To: Daniel Stenberg; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0902250912470.28808@yvahk2.pbagnpgbe.fr>

Hi,

Hmm, you didn't CC me so I didn't see your message until now. In
general it's a good idea to CC people in case they are not suscribed,
fortunately this is not the case.

On Wed, Feb 25, 2009 at 10:18 AM, Daniel Stenberg <daniel@haxx.se> wrote:
> On Wed, 25 Feb 2009, Felipe Contreras wrote:
>
>> I'm trying to push over https and I keep getting a crash. "curl -netrc
>> https://server/repo/HEAD" seems to work fine.
>
>> I'm attaching the output of valgrind and this is the backtrace (not on
>> the same run):
>
>> #6  0x064d5b37 in PR_Free (ptr=0x0) at
>> ../../../mozilla/nsprpub/pr/src/malloc/prmem.c:490
>> #7  0x00df72f8 in nss_ZRealloc (pointer=0x9fedb58, newSize=4096) at
>> arena.c:1076
>> #8  0x00de579b in pem_CreateObject (fwInstance=0x8109ba0,
>> fwSession=0x810bac8, mdToken=0x8109cf8, pTemplate=0xbfffd6e4,
>> ulAttributeCount=4, pError=0xbfffd608) at pobject.c:1080
>
> [...]
>
>> Any ideas?
>
> You didn't mention what libcurl version you use, but clearly this is built
> to use NSS for the SSL layer so I guess you're using a Fedora-provided
> library.

Indeed, Fedora 10; libcurl 7.18.2.

> There's already at least one NSS-libcurl-git related bug report[*] for
> Fedora submitted and I think you'll have a reason to follow that to see if
> you can help them or they can help you. To me this looks like at least one
> NSS bug.
>
> In the mean time I suggest you attempt a work-around: build a new libcurl
> powered by another SSL library such as OpenSSL or GnuTLS. It's just a matter
> of running libcurl's configure with the proper command line

Yes, actually I did that and it works fine. For the record, the new
libcurl with NSS still crashes.

> [*] = https://bugzilla.redhat.com/show_bug.cgi?id=483222

Thanks.

-- 
Felipe Contreras

^ permalink raw reply

* jgit and ignore
From: Jon Smirl @ 2009-02-28 16:31 UTC (permalink / raw)
  To: Git Mailing List, Shawn O. Pearce

I'm using jgit in eclipse. Works great for me.

I have a couple of generated files in my working directory. There
doesn't seem to be any UI for ignoring them. Is it there and I just
can't find it?

-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* fatal: git write-tree failed to write a tree
From: Caleb Cushing @ 2009-02-28 16:25 UTC (permalink / raw)
  To: git

git merge java-overlay/master
Adding profiles/package.mask/gentoo.org
Adding profiles/package.mask/perl-experimental
Adding profiles/package.mask/regen2.org
Adding profiles/package.mask/sunrise
profiles/package.mask/java-overlay: unmerged
(f67eeb638e2593b2bee5c9b476e3044a8404916a)
fatal: git write-tree failed to write a tree

normally merges work fine... hmm...

-- 
Caleb Cushing

http://xenoterracide.blogspot.com

^ permalink raw reply

* Re: How can I force git to recognize a change change in file modes?
From: Brent Goodrick @ 2009-02-28 16:24 UTC (permalink / raw)
  To: Jan Krüger; +Cc: git
In-Reply-To: <20090228045531.14399ebf@perceptron>

> git doesn't track permissions quite that closely; all it remembers is
> whether the file should be executable or not.

Thanks Jan.  Was this choice made due to the conditional coding
required to track the permission bits content between *NIX and
non-*NIX platform(s)?

bg

^ permalink raw reply

* Re: [PATCH] fix git format-patch --cc=<email> format
From: Jay Soffian @ 2009-02-28 16:15 UTC (permalink / raw)
  To: Peng Tao; +Cc: git, gitster
In-Reply-To: <1235824944-4967-1-git-send-email-bergwolf@gmail.com>

On Sat, Feb 28, 2009 at 7:42 AM, Peng Tao <bergwolf@gmail.com> wrote:
> If there are multiple --cc=<email> arguments, git format-patch will generate
> patches with cc lines like:
>  Cc: <email>,
>      <email>
> which git send-email fails to parse.
> git send-email only accept formats like:
>  Cc: <email>
>  Cc: <email>
> So change git format-patch to generate patches in a proper format.

This is fixed in next, but we fixed send-email instead to handle the
messages that format-patch generates, as they should be valid.

j.

^ permalink raw reply

* Re: git-svn, and which branch am I on?
From: Peter Harris @ 2009-02-28 15:03 UTC (permalink / raw)
  To: Daniel Pittman; +Cc: git
In-Reply-To: <87ljrr7xof.fsf@rimspace.net>

On Sat, Feb 28, 2009 at 3:50 AM, Daniel Pittman wrote:
>
> The general question was: in git, how do I identify where this branch
> came from?

> Specifically, this was about 'git svn', but also generally how to
> identify this information in git.

> ...and, finally, is the reason that I am finding it hard to explain this
> because I have an expectation of how things work that doesn't match up
> with git?  In other words, is the question actually meaningless?

You've hit the nail on the head. The question is meaningless. Git
tracks a DAG, and a branch is just that - a branch (or 'tip', if you
will) of the DAG.

Take, for example,

o--o--o--o master
 \
  o--o--o--o feature
      \
       o--o working

Which branch did 'working' come from? 'feature' or 'master'? Say I
later delete branch 'feature', since it was going in the wrong
direction. Does the answer change? What if I simply redraw the above
so that feature and working are swapped? Does the answer change? It's
still the same tree.

You can, however, answer related questions.

'git svn info' will tell you which branch a 'git svn dcommit' will
commit to, which is usually the question you actually wanted to
answer.

'git branch -r' will tell you which remote branch your local branch is
tracking. ie. which branch, if any, a plain 'git pull' will fetch and
merge from.

See also http://thread.gmane.org/gmane.comp.version-control.git/77730/focus=77823
and surrounding thread.

Peter Harris

^ permalink raw reply

* Re: git-svn, and which branch am I on?
From: Björn Steinbrink @ 2009-02-28 14:54 UTC (permalink / raw)
  To: Daniel Pittman; +Cc: git
In-Reply-To: <87ljrr7xof.fsf@rimspace.net>

On 2009.02.28 19:50:08 +1100, Daniel Pittman wrote:
> G'day.
> 
> I recently got asked a question about git-svn that I had no idea how to
> answer, and which I am actually curious to know how to find out.
> 
> The general question was: in git, how do I identify where this branch
> came from?

"git svn info" tells you, besides other things, the URL your checked out
branch is based upon WRT svn. Use it with "--url" to show only the URL.

> ...and, finally, is the reason that I am finding it hard to explain this
> because I have an expectation of how things work that doesn't match up
> with git?  In other words, is the question actually meaningless?

If you use git-svn, it's actually meaningful, because it controls what
svn rebase and svn dcommit do. For a pure git repo, it's usually not
that interesting.

Björn

^ permalink raw reply

* Re: How can I force git to recognize a change change in file modes?
From: Lars Noschinski @ 2009-02-28  1:25 UTC (permalink / raw)
  To: git
In-Reply-To: <e38bce640902271717s46cf47f9i7c6bf5aac0d5f273@mail.gmail.com>

* Brent Goodrick <bgoodr@gmail.com> [09-02-28 02:17]:
> I checked in a slew of scripts, only to realize that the file
> permissions were too open (I want them to be chmod 700, not chmod
> 755).  Somehow I thought that git was tracking those permission bits,
> but simply using "chmod 700 <fileset>; git add <fileset>" did not add
> the change of file modes, well, at least git status output doesn't
> show it. Is there a way to do this?

Git does only track the executable bit.

^ permalink raw reply

* Re: [PATCH 3/4] diffcore-pickaxe: further refactor count_match()
From: René Scharfe @ 2009-02-28 13:10 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wnrgkjw.fsf@gitster.siamese.dyndns.org>

Junio C Hamano schrieb:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>> ...
>>> In any case, there is also memmem(), which uses the same fast algorithm
>>> as strstr() in recent glibc versions.  Like this?
>> Thanks; it would be nice to bench this change.
> 
> With memmem() patch applied on top of [1-4/4], the same test as described
> in the commit log message of [4/4] which was:
> 
>     $ STRING='Ensure that the real time constraints are schedulable.'
>     $ git log -S"$STRING" HEAD -- kernel/sched.c >/dev/null
> 
>     (Before the patch, best of 5 runs)
>     5.59user 0.15system 0:05.74elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
>     0inputs+0outputs (0major+39956minor)pagefaults 0swaps
> 
>     (After the patch, best of 5 runs)
>     3.04user 0.17system 0:03.23elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
>     0inputs+0outputs (0major+49697minor)pagefaults 0swaps
> 
>     The file "kernel/sched.c" has roughly 900 changes applied to it, and over
>     its lifetime, it has grown from 5kB to 9kB in size.  I'd expect a larger
>     file may see a bigger performance boost.
> 
> (With memmem() patch, best of 5 runs)
> 2.46user 0.15system 0:02.62elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+49698minor)pagefaults 0swaps

I get this (Ubuntu 8.10 x64, Fedora 10 x64 using the same Linux repo,
Windows Vista x64 using a different Linux repo with the same HEAD on
NTFS and msysgit, numbers are the elapsed time in seconds, best of five
runs):

                           Ubuntu  Fedora  Windows
   v1.6.2-rc2                8.14    8.16    9.236
   v1.6.2-rc2+[1-4]          2.43    2.45    2.995
   v1.6.2-rc2+[1-4]+memmem   1.31    1.25    2.917
   v1.6.2-rc2+[1-3]+memmem   1.51    1.16    8.455

Ubuntu has glibc 2.8, while Fedora 10 has glibc 2.9, with a new and more
efficient memmem() implementation.  On Windows, we use our own naive
memmem() implementation.

So using memmem() is worthwhile.  And providing a better fall-back
version in compat/ can speed up this particular case to the point where
the fourth patch becomes moot.

Hmm, gnulib (http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=summary)
contains all parts ready for copy & paste, licensed under the GPL 2 or
up.  That won't cause problems with the libgit2 relicensing effort, as
memmem()  won't end up in there, right?


For the record, here the raw timings used to make the table above (best
of five):

Fedora 10:
8.10user 0.05system 0:08.16elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+31943minor)pagefaults 0swaps

2.38user 0.06system 0:02.45elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+41294minor)pagefaults 0swaps

1.19user 0.05system 0:01.25elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+39274minor)pagefaults 0swaps

1.10user 0.05system 0:01.16elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+31796minor)pagefaults 0swaps

Ubuntu 8.10:
8.08user 0.05system 0:08.14elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+29579minor)pagefaults 0swaps

2.35user 0.07system 0:02.43elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+40437minor)pagefaults 0swaps

1.23user 0.08system 0:01.31elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+41097minor)pagefaults 0swaps

1.46user 0.05system 0:01.51elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+30533minor)pagefaults 0swaps

Windows:
real    0m9.236s
user    0m0.000s
sys     0m0.000s

real    0m2.995s
user    0m0.000s
sys     0m0.000s

real    0m2.917s
user    0m0.000s
sys     0m0.015s

real    0m8.455s
user    0m0.000s
sys     0m0.000s

^ permalink raw reply

* [PATCH] fix git format-patch --cc=<email> format
From: Peng Tao @ 2009-02-28 12:42 UTC (permalink / raw)
  To: git; +Cc: gitster, Peng Tao

If there are multiple --cc=<email> arguments, git format-patch will generate
patches with cc lines like:
  Cc: <email>,
      <email>
which git send-email fails to parse.
git send-email only accept formats like:
  Cc: <email>
  Cc: <email>
So change git format-patch to generate patches in a proper format.

Signed-off-by: Peng Tao <bergwolf@gmail.com>
---
 builtin-log.c |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index 60f8dd8..22bb6b6 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -907,13 +907,9 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 	}
 
 	if (extra_cc_nr)
-		strbuf_addstr(&buf, "Cc: ");
 	for (i = 0; i < extra_cc_nr; i++) {
-		if (i)
-			strbuf_addstr(&buf, "    ");
+		strbuf_addstr(&buf, "Cc: ");
 		strbuf_addstr(&buf, extra_cc[i]);
-		if (i + 1 < extra_cc_nr)
-			strbuf_addch(&buf, ',');
 		strbuf_addch(&buf, '\n');
 	}
 

^ permalink raw reply related

* Re: [PATCH 0/6] "git repack -a -d" improvements
From: Kjetil Barvik @ 2009-02-28 12:29 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1235812035.git.gitster@pobox.com>

* Junio C Hamano <gitster@pobox.com> writes:
| [2/6] refactors public interface has_sha1_pack() that takes an optional
| "ignore_packed" list.  Most callers pass NULL, so it introduces a new
| function has_sha1_kept_pack() and migrate the minority caller to this
| interface while losing the argument from the original function and callers
| that currently pass NULL.
  [...]
| [4/6] identifies three places that use "ignore_packed" list to tell if a
| pack is on the list or not, and introduces a helper function to do so.
| The helper is conveniently called is_kept_pack(), even though at this
| stage the list does not necessarily mean a list of "unkept" packs yet.

  OK, patch 2/6 failed for me when I was doing 'git am' to import the
  patch-series, so sorry if do not see all bits of the patch correctly.

  Would it be an improvment to change the signature of the currently
  find_sha1_pack() function to:

    struct packed_git *
    find_pack_entry(const unsigned char *sha1, off_t *sha1_pack_offset,
                    struct packed_git *packs)

    - The currently existing 'struct pack_entry *e' parameter is only
      used to retrn the offset, so make it more clear.  The struct
      pack_entry can probably be deleted from the sha1_file.c file.

    - When the 'git repack -a -d' command is used, one has to compute
      the list of allowed pack-files to look into, and give this list to
      find_pack_entry().

    - The currently named find_sha1_pack() function can then be deleted.

    - For example, when this function is now used in sha1_object_info()
      it can be called like this:

          found_pack = find_pack_entry(sha1, &offset, packed_git);

  -- kjetil

^ permalink raw reply

* Re: [PATCH] gitk: make use of themed widgets where available
From: Pat Thoyts @ 2009-02-28  9:24 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: git
In-Reply-To: <18856.42302.321781.759870@cargo.ozlabs.ibm.com>

Paul Mackerras <paulus@samba.org> writes:

>Pat Thoyts writes:
>
>>     This patch improves the appearence of gitk on Windows XP and Vista
>>     by making use of the themed widgets that are provided in Tk 8.5
>>     and above. For good Vista support 8.6 will be needed.
>
>Wow.  It'll take me a while to digest this.  Before I start diving
>into it, does gitk still work on Tk 8.4 with this patch?
>
>Paul.

Yes. It uses the variable 'use_ttk' to turn on the use of the themed
widgets and if this is unavailable (or an option could be provided to
turn it off explicitly) then only standard Tk widgets are used.

-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

^ permalink raw reply

* [PATCH 2/6] has_sha1_pack(): refactor "pretend these packs do not exist" interface
From: Junio C Hamano @ 2009-02-28  9:15 UTC (permalink / raw)
  To: git
In-Reply-To: <cover.1235812035.git.gitster@pobox.com>

Most of the callers of this function except only one pass NULL to its last
parameter, ignore_packed.

Introduce has_sha1_kept_pack() function that has the function signature
and the semantics of this function, and convert the sole caller that does
not pass NULL to call this new function.

All other callers and has_sha1_pack() lose the ignore_packed parameter.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-count-objects.c |    2 +-
 builtin-fsck.c          |    2 +-
 builtin-prune-packed.c  |    2 +-
 cache.h                 |    3 ++-
 diff.c                  |    2 +-
 revision.c              |    3 ++-
 sha1_file.c             |   32 +++++++++++++++++++++++++-------
 7 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/builtin-count-objects.c b/builtin-count-objects.c
index 91b5487..c095e8d 100644
--- a/builtin-count-objects.c
+++ b/builtin-count-objects.c
@@ -61,7 +61,7 @@ static void count_objects(DIR *d, char *path, int len, int verbose,
 		hex[40] = 0;
 		if (get_sha1_hex(hex, sha1))
 			die("internal error");
-		if (has_sha1_pack(sha1, NULL))
+		if (has_sha1_pack(sha1))
 			(*packed_loose)++;
 	}
 }
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 30971ce..491375d 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -158,7 +158,7 @@ static void check_reachable_object(struct object *obj)
 	 * do a full fsck
 	 */
 	if (!obj->parsed) {
-		if (has_sha1_pack(obj->sha1, NULL))
+		if (has_sha1_pack(obj->sha1))
 			return; /* it is in pack - forget about it */
 		printf("missing %s %s\n", typename(obj->type), sha1_to_hex(obj->sha1));
 		errors_found |= ERROR_REACHABLE;
diff --git a/builtin-prune-packed.c b/builtin-prune-packed.c
index 10cb8df..2d5b2cd 100644
--- a/builtin-prune-packed.c
+++ b/builtin-prune-packed.c
@@ -23,7 +23,7 @@ static void prune_dir(int i, DIR *dir, char *pathname, int len, int opts)
 		memcpy(hex+2, de->d_name, 38);
 		if (get_sha1_hex(hex, sha1))
 			continue;
-		if (!has_sha1_pack(sha1, NULL))
+		if (!has_sha1_pack(sha1))
 			continue;
 		memcpy(pathname + len, de->d_name, 38);
 		if (opts & DRY_RUN)
diff --git a/cache.h b/cache.h
index 42f2f27..c1539bf 100644
--- a/cache.h
+++ b/cache.h
@@ -565,7 +565,8 @@ extern int check_sha1_signature(const unsigned char *sha1, void *buf, unsigned l
 
 extern int move_temp_to_file(const char *tmpfile, const char *filename);
 
-extern int has_sha1_pack(const unsigned char *sha1, const char **ignore);
+extern int has_sha1_pack(const unsigned char *sha1);
+extern int has_sha1_kept_pack(const unsigned char *sha1, const char **ignore);
 extern int has_sha1_file(const unsigned char *sha1);
 extern int has_loose_object_nonlocal(const unsigned char *sha1);
 
diff --git a/diff.c b/diff.c
index f91f256..a34d26c 100644
--- a/diff.c
+++ b/diff.c
@@ -1743,7 +1743,7 @@ static int reuse_worktree_file(const char *name, const unsigned char *sha1, int
 	 * objects however would tend to be slower as they need
 	 * to be individually opened and inflated.
 	 */
-	if (!FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL))
+	if (!FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1))
 		return 0;
 
 	len = strlen(name);
diff --git a/revision.c b/revision.c
index 45fd7a3..746eeed 100644
--- a/revision.c
+++ b/revision.c
@@ -1485,7 +1485,8 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
 {
 	if (commit->object.flags & SHOWN)
 		return commit_ignore;
-	if (revs->unpacked && has_sha1_pack(commit->object.sha1, revs->ignore_packed))
+	if (revs->unpacked &&
+	    has_sha1_kept_pack(commit->object.sha1, revs->ignore_packed))
 		return commit_ignore;
 	if (revs->show_all)
 		return commit_show;
diff --git a/sha1_file.c b/sha1_file.c
index 88035a0..ac4375d 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1874,7 +1874,8 @@ int matches_pack_name(struct packed_git *p, const char *name)
 	return 0;
 }
 
-static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e, const char **ignore_packed)
+static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
+			 const char **ignore_packed)
 {
 	static struct packed_git *last_found = (void *)1;
 	struct packed_git *p;
@@ -1934,6 +1935,17 @@ static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e, cons
 	return 0;
 }
 
+static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)
+{
+	return find_pack_ent(sha1, e, NULL);
+}
+
+static int find_kept_pack_entry(const unsigned char *sha1, struct pack_entry *e,
+				const char **ignore_packed)
+{
+	return find_pack_ent(sha1, e, ignore_packed);
+}
+
 struct packed_git *find_sha1_pack(const unsigned char *sha1,
 				  struct packed_git *packs)
 {
@@ -1975,7 +1987,7 @@ int sha1_object_info(const unsigned char *sha1, unsigned long *sizep)
 	struct pack_entry e;
 	int status;
 
-	if (!find_pack_entry(sha1, &e, NULL)) {
+	if (!find_pack_entry(sha1, &e)) {
 		/* Most likely it's a loose object. */
 		status = sha1_loose_object_info(sha1, sizep);
 		if (status >= 0)
@@ -1983,7 +1995,7 @@ int sha1_object_info(const unsigned char *sha1, unsigned long *sizep)
 
 		/* Not a loose object; someone else may have just packed it. */
 		reprepare_packed_git();
-		if (!find_pack_entry(sha1, &e, NULL))
+		if (!find_pack_entry(sha1, &e))
 			return status;
 	}
 	return packed_object_info(e.p, e.offset, sizep);
@@ -1995,7 +2007,7 @@ static void *read_packed_sha1(const unsigned char *sha1,
 	struct pack_entry e;
 	void *data;
 
-	if (!find_pack_entry(sha1, &e, NULL))
+	if (!find_pack_entry(sha1, &e))
 		return NULL;
 	data = cache_or_unpack_entry(e.p, e.offset, size, type, 1);
 	if (!data) {
@@ -2395,17 +2407,23 @@ int has_pack_file(const unsigned char *sha1)
 	return 1;
 }
 
-int has_sha1_pack(const unsigned char *sha1, const char **ignore_packed)
+int has_sha1_pack(const unsigned char *sha1)
+{
+	struct pack_entry e;
+	return find_pack_entry(sha1, &e);
+}
+
+int has_sha1_kept_pack(const unsigned char *sha1, const char **ignore_packed)
 {
 	struct pack_entry e;
-	return find_pack_entry(sha1, &e, ignore_packed);
+	return find_kept_pack_entry(sha1, &e, ignore_packed);
 }
 
 int has_sha1_file(const unsigned char *sha1)
 {
 	struct pack_entry e;
 
-	if (find_pack_entry(sha1, &e, NULL))
+	if (find_pack_entry(sha1, &e))
 		return 1;
 	return has_loose_object(sha1);
 }
-- 
1.6.2.rc2.99.g9f3bb

^ permalink raw reply related

* [PATCH 4/6] Consolidate ignore_packed logic more
From: Junio C Hamano @ 2009-02-28  9:15 UTC (permalink / raw)
  To: git
In-Reply-To: <cover.1235812035.git.gitster@pobox.com>

This refactors three loops that check if a given packfile is on the
ignore_packed list into a function is_kept_pack().  The function returns
false for a pack on the list, and true for a pack not on the list, because
this list is solely used by "git repack" to pass list of packfiles that do
not have corresponding .keep files, i.e. a packfile not on the list is
"kept".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-pack-objects.c |   12 ++----------
 cache.h                |    1 -
 revision.h             |    1 +
 sha1_file.c            |   24 ++++++++++++++----------
 4 files changed, 17 insertions(+), 21 deletions(-)

diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index fb5e14d..7e7719b 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1915,11 +1915,7 @@ static void add_objects_in_unpacked_packs(struct rev_info *revs)
 		const unsigned char *sha1;
 		struct object *o;
 
-		for (i = 0; i < revs->num_ignore_packed; i++) {
-			if (matches_pack_name(p, revs->ignore_packed[i]))
-				break;
-		}
-		if (revs->num_ignore_packed <= i)
+		if (is_kept_pack(p, revs))
 			continue;
 		if (open_pack_index(p))
 			die("cannot open pack index");
@@ -1955,11 +1951,7 @@ static void loosen_unused_packed_objects(struct rev_info *revs)
 	const unsigned char *sha1;
 
 	for (p = packed_git; p; p = p->next) {
-		for (i = 0; i < revs->num_ignore_packed; i++) {
-			if (matches_pack_name(p, revs->ignore_packed[i]))
-				break;
-		}
-		if (revs->num_ignore_packed <= i)
+		if (is_kept_pack(p, revs))
 			continue;
 
 		if (open_pack_index(p))
diff --git a/cache.h b/cache.h
index 8e43f38..23c16d0 100644
--- a/cache.h
+++ b/cache.h
@@ -747,7 +747,6 @@ extern void *unpack_entry(struct packed_git *, off_t, enum object_type *, unsign
 extern unsigned long unpack_object_header_gently(const unsigned char *buf, unsigned long len, enum object_type *type, unsigned long *sizep);
 extern unsigned long get_size_from_delta(struct packed_git *, struct pack_window **, off_t);
 extern const char *packed_object_info_detail(struct packed_git *, off_t, unsigned long *, unsigned long *, unsigned int *, unsigned char *);
-extern int matches_pack_name(struct packed_git *p, const char *name);
 
 /* Dumb servers support */
 extern int update_server_info(int);
diff --git a/revision.h b/revision.h
index 9304296..af414e5 100644
--- a/revision.h
+++ b/revision.h
@@ -159,5 +159,6 @@ enum commit_action {
 extern enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit);
 
 extern int has_sha1_kept_pack(const unsigned char *sha1, const struct rev_info *);
+extern int is_kept_pack(const struct packed_git *, const struct rev_info *);
 
 #endif
diff --git a/sha1_file.c b/sha1_file.c
index f963c3c..6e0a462 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1858,7 +1858,7 @@ off_t find_pack_entry_one(const unsigned char *sha1,
 	return 0;
 }
 
-int matches_pack_name(struct packed_git *p, const char *name)
+static int matches_pack_name(const struct packed_git *p, const char *name)
 {
 	const char *last_c, *c;
 
@@ -1876,6 +1876,17 @@ int matches_pack_name(struct packed_git *p, const char *name)
 	return 0;
 }
 
+int is_kept_pack(const struct packed_git *p, const struct rev_info *revs)
+{
+	int i;
+
+	for (i = 0; i < revs->num_ignore_packed; i++) {
+		if (matches_pack_name(p, revs->ignore_packed[i]))
+			return 0;
+	}
+	return 1;
+}
+
 static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
 			 const struct rev_info *revs)
 {
@@ -1889,15 +1900,8 @@ static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
 	p = (last_found == (void *)1) ? packed_git : last_found;
 
 	do {
-		if (revs->ignore_packed) {
-			const char **ig;
-			for (ig = revs->ignore_packed; *ig; ig++)
-				if (matches_pack_name(p, *ig))
-					break;
-			if (*ig)
-				goto next;
-		}
-
+		if (revs->ignore_packed && !is_kept_pack(p, revs))
+			goto next;
 		if (p->num_bad_objects) {
 			unsigned i;
 			for (i = 0; i < p->num_bad_objects; i++)
-- 
1.6.2.rc2.99.g9f3bb

^ permalink raw reply related

* [PATCH 5/6] Simplify is_kept_pack()
From: Junio C Hamano @ 2009-02-28  9:15 UTC (permalink / raw)
  To: git
In-Reply-To: <cover.1235812035.git.gitster@pobox.com>

This removes --unpacked=<packfile> parameter from the revision parser, and
rewrites its use in git-repack to pass a single --kept-pack-only option
instead.

The new --kept-pack-only option means just that.  When this option is
given, is_kept_pack() that used to say "not on the --unpacked=<packfile>
list" now says "the packfile has corresponding .keep file".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-pack-objects.c |    6 +++---
 git-repack.sh          |    5 ++++-
 revision.c             |   20 +++++---------------
 revision.h             |    8 +++-----
 sha1_file.c            |   30 +++---------------------------
 5 files changed, 18 insertions(+), 51 deletions(-)

diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 7e7719b..150258b 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1915,7 +1915,7 @@ static void add_objects_in_unpacked_packs(struct rev_info *revs)
 		const unsigned char *sha1;
 		struct object *o;
 
-		if (is_kept_pack(p, revs))
+		if (is_kept_pack(p))
 			continue;
 		if (open_pack_index(p))
 			die("cannot open pack index");
@@ -1951,7 +1951,7 @@ static void loosen_unused_packed_objects(struct rev_info *revs)
 	const unsigned char *sha1;
 
 	for (p = packed_git; p; p = p->next) {
-		if (is_kept_pack(p, revs))
+		if (is_kept_pack(p))
 			continue;
 
 		if (open_pack_index(p))
@@ -2149,7 +2149,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
 			continue;
 		}
 		if (!strcmp("--unpacked", arg) ||
-		    !prefixcmp(arg, "--unpacked=") ||
+		    !strcmp("--kept-pack-only", arg) ||
 		    !strcmp("--reflog", arg) ||
 		    !strcmp("--all", arg)) {
 			use_internal_rev_list = 1;
diff --git a/git-repack.sh b/git-repack.sh
index 8600015..a736009 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -68,10 +68,13 @@ case ",$all_into_one," in
 			if [ -e "$PACKDIR/$e.keep" ]; then
 				: keep
 			else
-				args="$args --unpacked=$e.pack"
 				existing="$existing $e"
 			fi
 		done
+		if test -n "$existing"
+		then
+			args="--kept-pack-only"
+		fi
 		if test -n "$args" -a -n "$unpack_unreachable" -a \
 			-n "$remove_redundant"
 		then
diff --git a/revision.c b/revision.c
index 795e0c0..3cfd653 100644
--- a/revision.c
+++ b/revision.c
@@ -963,16 +963,6 @@ static void add_message_grep(struct rev_info *revs, const char *pattern)
 	add_grep(revs, pattern, GREP_PATTERN_BODY);
 }
 
-static void add_ignore_packed(struct rev_info *revs, const char *name)
-{
-	int num = ++revs->num_ignore_packed;
-
-	revs->ignore_packed = xrealloc(revs->ignore_packed,
-				       sizeof(const char *) * (num + 1));
-	revs->ignore_packed[num-1] = name;
-	revs->ignore_packed[num] = NULL;
-}
-
 static int handle_revision_opt(struct rev_info *revs, int argc, const char **argv,
 			       int *unkc, const char **unkv)
 {
@@ -1072,12 +1062,12 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
 		revs->edge_hint = 1;
 	} else if (!strcmp(arg, "--unpacked")) {
 		revs->unpacked = 1;
-		free(revs->ignore_packed);
-		revs->ignore_packed = NULL;
-		revs->num_ignore_packed = 0;
-	} else if (!prefixcmp(arg, "--unpacked=")) {
+		revs->kept_pack_only = 0;
+	} else if (!strcmp(arg, "--kept-pack-only")) {
 		revs->unpacked = 1;
-		add_ignore_packed(revs, arg+11);
+		revs->kept_pack_only = 1;
+	} else if (!prefixcmp(arg, "--unpacked=")) {
+		die("--unpacked=<packfile> no longer supported.");
 	} else if (!strcmp(arg, "-r")) {
 		revs->diff = 1;
 		DIFF_OPT_SET(&revs->diffopt, RECURSIVE);
diff --git a/revision.h b/revision.h
index af414e5..f63596f 100644
--- a/revision.h
+++ b/revision.h
@@ -47,7 +47,8 @@ struct rev_info {
 			blob_objects:1,
 			edge_hint:1,
 			limited:1,
-			unpacked:1, /* see also ignore_packed below */
+			unpacked:1,
+			kept_pack_only:1,
 			boundary:2,
 			left_right:1,
 			rewrite_parents:1,
@@ -75,9 +76,6 @@ struct rev_info {
 			missing_newline:1;
 	enum date_mode date_mode;
 
-	const char **ignore_packed; /* pretend objects in these are unpacked */
-	int num_ignore_packed;
-
 	unsigned int	abbrev;
 	enum cmit_fmt	commit_format;
 	struct log_info *loginfo;
@@ -159,6 +157,6 @@ enum commit_action {
 extern enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit);
 
 extern int has_sha1_kept_pack(const unsigned char *sha1, const struct rev_info *);
-extern int is_kept_pack(const struct packed_git *, const struct rev_info *);
+extern int is_kept_pack(const struct packed_git *);
 
 #endif
diff --git a/sha1_file.c b/sha1_file.c
index 6e0a462..e8a9517 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1858,33 +1858,9 @@ off_t find_pack_entry_one(const unsigned char *sha1,
 	return 0;
 }
 
-static int matches_pack_name(const struct packed_git *p, const char *name)
+int is_kept_pack(const struct packed_git *p)
 {
-	const char *last_c, *c;
-
-	if (!strcmp(p->pack_name, name))
-		return 1;
-
-	for (c = p->pack_name, last_c = c; *c;)
-		if (*c == '/')
-			last_c = ++c;
-		else
-			++c;
-	if (!strcmp(last_c, name))
-		return 1;
-
-	return 0;
-}
-
-int is_kept_pack(const struct packed_git *p, const struct rev_info *revs)
-{
-	int i;
-
-	for (i = 0; i < revs->num_ignore_packed; i++) {
-		if (matches_pack_name(p, revs->ignore_packed[i]))
-			return 0;
-	}
-	return 1;
+	return p->pack_keep;
 }
 
 static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
@@ -1900,7 +1876,7 @@ static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
 	p = (last_found == (void *)1) ? packed_git : last_found;
 
 	do {
-		if (revs->ignore_packed && !is_kept_pack(p, revs))
+		if (revs->kept_pack_only && !is_kept_pack(p))
 			goto next;
 		if (p->num_bad_objects) {
 			unsigned i;
-- 
1.6.2.rc2.99.g9f3bb

^ permalink raw reply related

* [PATCH 6/6] is_kept_pack(): final clean-up
From: Junio C Hamano @ 2009-02-28  9:15 UTC (permalink / raw)
  To: git
In-Reply-To: <cover.1235812035.git.gitster@pobox.com>

Now is_kept_pack() is just a member lookup into a structure, we can write
it as such.

Also rewrite the sole caller of has_sha1_kept_pack() to switch on the
criteria the callee uses (namely, revs->kept_pack_only) between calling
has_sha1_kept_pack() and has_sha1_pack(), so that these two callees do not
have to take a pointer to struct rev_info as an argument.

This removes the header file dependency issue temporarily introduced by
the earlier commit, so we revert changes associated to that as well.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-pack-objects.c |    4 ++--
 cache.h                |    1 +
 revision.c             |    4 +++-
 revision.h             |    3 ---
 sha1_file.c            |   22 +++++++---------------
 5 files changed, 13 insertions(+), 21 deletions(-)

diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 150258b..b2e4626 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1915,7 +1915,7 @@ static void add_objects_in_unpacked_packs(struct rev_info *revs)
 		const unsigned char *sha1;
 		struct object *o;
 
-		if (is_kept_pack(p))
+		if (p->pack_keep)
 			continue;
 		if (open_pack_index(p))
 			die("cannot open pack index");
@@ -1951,7 +1951,7 @@ static void loosen_unused_packed_objects(struct rev_info *revs)
 	const unsigned char *sha1;
 
 	for (p = packed_git; p; p = p->next) {
-		if (is_kept_pack(p))
+		if (p->pack_keep)
 			continue;
 
 		if (open_pack_index(p))
diff --git a/cache.h b/cache.h
index 23c16d0..0a3d523 100644
--- a/cache.h
+++ b/cache.h
@@ -566,6 +566,7 @@ extern int check_sha1_signature(const unsigned char *sha1, void *buf, unsigned l
 extern int move_temp_to_file(const char *tmpfile, const char *filename);
 
 extern int has_sha1_pack(const unsigned char *sha1);
+extern int has_sha1_kept_pack(const unsigned char *sha1);
 extern int has_sha1_file(const unsigned char *sha1);
 extern int has_loose_object_nonlocal(const unsigned char *sha1);
 
diff --git a/revision.c b/revision.c
index 3cfd653..6d8ac46 100644
--- a/revision.c
+++ b/revision.c
@@ -1476,7 +1476,9 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
 	if (commit->object.flags & SHOWN)
 		return commit_ignore;
 	if (revs->unpacked &&
-	    has_sha1_kept_pack(commit->object.sha1, revs))
+	    (revs->kept_pack_only
+	     ? has_sha1_kept_pack(commit->object.sha1)
+	     : has_sha1_pack(commit->object.sha1)))
 		return commit_ignore;
 	if (revs->show_all)
 		return commit_show;
diff --git a/revision.h b/revision.h
index f63596f..b9fa9c2 100644
--- a/revision.h
+++ b/revision.h
@@ -156,7 +156,4 @@ enum commit_action {
 
 extern enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit);
 
-extern int has_sha1_kept_pack(const unsigned char *sha1, const struct rev_info *);
-extern int is_kept_pack(const struct packed_git *);
-
 #endif
diff --git a/sha1_file.c b/sha1_file.c
index e8a9517..7ead56c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -16,8 +16,6 @@
 #include "refs.h"
 #include "pack-revindex.h"
 #include "sha1-lookup.h"
-#include "diff.h"
-#include "revision.h"
 
 #ifndef O_NOATIME
 #if defined(__linux__) && (defined(__i386__) || defined(__PPC__))
@@ -1858,13 +1856,8 @@ off_t find_pack_entry_one(const unsigned char *sha1,
 	return 0;
 }
 
-int is_kept_pack(const struct packed_git *p)
-{
-	return p->pack_keep;
-}
-
 static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
-			 const struct rev_info *revs)
+			 int kept_pack_only)
 {
 	static struct packed_git *last_found = (void *)1;
 	struct packed_git *p;
@@ -1876,7 +1869,7 @@ static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
 	p = (last_found == (void *)1) ? packed_git : last_found;
 
 	do {
-		if (revs->kept_pack_only && !is_kept_pack(p))
+		if (kept_pack_only && !p->pack_keep)
 			goto next;
 		if (p->num_bad_objects) {
 			unsigned i;
@@ -1919,13 +1912,12 @@ static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
 
 static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)
 {
-	return find_pack_ent(sha1, e, NULL);
+	return find_pack_ent(sha1, e, 0);
 }
 
-static int find_kept_pack_entry(const unsigned char *sha1, struct pack_entry *e,
-				const struct rev_info *revs)
+static int find_kept_pack_entry(const unsigned char *sha1, struct pack_entry *e)
 {
-	return find_pack_ent(sha1, e, revs);
+	return find_pack_ent(sha1, e, 1);
 }
 
 struct packed_git *find_sha1_pack(const unsigned char *sha1,
@@ -2395,10 +2387,10 @@ int has_sha1_pack(const unsigned char *sha1)
 	return find_pack_entry(sha1, &e);
 }
 
-int has_sha1_kept_pack(const unsigned char *sha1, const struct rev_info *revs)
+int has_sha1_kept_pack(const unsigned char *sha1)
 {
 	struct pack_entry e;
-	return find_kept_pack_entry(sha1, &e, revs);
+	return find_kept_pack_entry(sha1, &e);
 }
 
 int has_sha1_file(const unsigned char *sha1)
-- 
1.6.2.rc2.99.g9f3bb

^ permalink raw reply related

* [PATCH 3/6] has_sha1_kept_pack(): take "struct rev_info"
From: Junio C Hamano @ 2009-02-28  9:15 UTC (permalink / raw)
  To: git
In-Reply-To: <cover.1235812035.git.gitster@pobox.com>

Its "ignore_packed" parameter always comes from struct rev_info.  This
patch makes the function take a pointer to the surrounding structure, so
that the refactoring in the next patch becomes easier to review.

There is an unfortunate header file dependency and the easiest workaround
is to temporarily move the function declaration from cache.h to
revision.h; this will be moved back to cache.h once the function loses
this "ignore_packed" parameter altogether in the later part of the
series.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 cache.h     |    1 -
 revision.c  |    2 +-
 revision.h  |    2 ++
 sha1_file.c |   16 +++++++++-------
 4 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/cache.h b/cache.h
index c1539bf..8e43f38 100644
--- a/cache.h
+++ b/cache.h
@@ -566,7 +566,6 @@ extern int check_sha1_signature(const unsigned char *sha1, void *buf, unsigned l
 extern int move_temp_to_file(const char *tmpfile, const char *filename);
 
 extern int has_sha1_pack(const unsigned char *sha1);
-extern int has_sha1_kept_pack(const unsigned char *sha1, const char **ignore);
 extern int has_sha1_file(const unsigned char *sha1);
 extern int has_loose_object_nonlocal(const unsigned char *sha1);
 
diff --git a/revision.c b/revision.c
index 746eeed..795e0c0 100644
--- a/revision.c
+++ b/revision.c
@@ -1486,7 +1486,7 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
 	if (commit->object.flags & SHOWN)
 		return commit_ignore;
 	if (revs->unpacked &&
-	    has_sha1_kept_pack(commit->object.sha1, revs->ignore_packed))
+	    has_sha1_kept_pack(commit->object.sha1, revs))
 		return commit_ignore;
 	if (revs->show_all)
 		return commit_show;
diff --git a/revision.h b/revision.h
index 91f1944..9304296 100644
--- a/revision.h
+++ b/revision.h
@@ -158,4 +158,6 @@ enum commit_action {
 
 extern enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit);
 
+extern int has_sha1_kept_pack(const unsigned char *sha1, const struct rev_info *);
+
 #endif
diff --git a/sha1_file.c b/sha1_file.c
index ac4375d..f963c3c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -16,6 +16,8 @@
 #include "refs.h"
 #include "pack-revindex.h"
 #include "sha1-lookup.h"
+#include "diff.h"
+#include "revision.h"
 
 #ifndef O_NOATIME
 #if defined(__linux__) && (defined(__i386__) || defined(__PPC__))
@@ -1875,7 +1877,7 @@ int matches_pack_name(struct packed_git *p, const char *name)
 }
 
 static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
-			 const char **ignore_packed)
+			 const struct rev_info *revs)
 {
 	static struct packed_git *last_found = (void *)1;
 	struct packed_git *p;
@@ -1887,9 +1889,9 @@ static int find_pack_ent(const unsigned char *sha1, struct pack_entry *e,
 	p = (last_found == (void *)1) ? packed_git : last_found;
 
 	do {
-		if (ignore_packed) {
+		if (revs->ignore_packed) {
 			const char **ig;
-			for (ig = ignore_packed; *ig; ig++)
+			for (ig = revs->ignore_packed; *ig; ig++)
 				if (matches_pack_name(p, *ig))
 					break;
 			if (*ig)
@@ -1941,9 +1943,9 @@ static int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)
 }
 
 static int find_kept_pack_entry(const unsigned char *sha1, struct pack_entry *e,
-				const char **ignore_packed)
+				const struct rev_info *revs)
 {
-	return find_pack_ent(sha1, e, ignore_packed);
+	return find_pack_ent(sha1, e, revs);
 }
 
 struct packed_git *find_sha1_pack(const unsigned char *sha1,
@@ -2413,10 +2415,10 @@ int has_sha1_pack(const unsigned char *sha1)
 	return find_pack_entry(sha1, &e);
 }
 
-int has_sha1_kept_pack(const unsigned char *sha1, const char **ignore_packed)
+int has_sha1_kept_pack(const unsigned char *sha1, const struct rev_info *revs)
 {
 	struct pack_entry e;
-	return find_kept_pack_entry(sha1, &e, ignore_packed);
+	return find_kept_pack_entry(sha1, &e, revs);
 }
 
 int has_sha1_file(const unsigned char *sha1)
-- 
1.6.2.rc2.99.g9f3bb

^ permalink raw reply related

* [PATCH 1/6] git-repack: resist stray environment variable
From: Junio C Hamano @ 2009-02-28  9:15 UTC (permalink / raw)
  To: git
In-Reply-To: <cover.1235812035.git.gitster@pobox.com>

The script used $args and $existing without initializing it to empty.  It
would have been confused by an environment variable the end user had
before running it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-repack.sh |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/git-repack.sh b/git-repack.sh
index 458a497..8600015 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -60,6 +60,7 @@ case ",$all_into_one," in
 	args='--unpacked --incremental'
 	;;
 ,t,)
+	args= existing=
 	if [ -d "$PACKDIR" ]; then
 		for e in `cd "$PACKDIR" && find . -type f -name '*.pack' \
 			| sed -e 's/^\.\///' -e 's/\.pack$//'`
-- 
1.6.2.rc2.99.g9f3bb

^ permalink raw reply related

* [PATCH 0/6] "git repack -a -d" improvements
From: Junio C Hamano @ 2009-02-28  9:15 UTC (permalink / raw)
  To: git
In-Reply-To: <alpine.LFD.2.00.0902191318310.21686@localhost.localdomain>

This is series removes the linear search in "ignore_packed" list when "git
repack -a -d" is run to consolidate many packfiles that are not marked to
be kept with ".keep".  It is oversplit for easier review; in the final
form, I think it should be two patch series, 1/6 and the rest.

The current mechanism is to pass the name of packfiles that are not marked
to be kept with --unpacked= command line option.  This list is used to a
few internal functions to pretend as if the objects found in named packs
exist in loose form and subject to repacking.  This look-up is linear and
found to be very inefficient.

[1/6] is a preparatory and an unrelated bugfix to git-repack script.

[2/6] refactors public interface has_sha1_pack() that takes an optional
"ignore_packed" list.  Most callers pass NULL, so it introduces a new
function has_sha1_kept_pack() and migrate the minority caller to this
interface while losing the argument from the original function and callers
that currently pass NULL.

[3/6] temporarily makes the the extra argument to has_sha1_kept_pack()
function to pass "ignore_packed" list from a list of char* to a pointer to
struct rev_info, solely to make the refactoring done in [4/6] easier to
follow.  Most of the effects of this patch will be removed at the end.

[4/6] identifies three places that use "ignore_packed" list to tell if a
pack is on the list or not, and introduces a helper function to do so.
The helper is conveniently called is_kept_pack(), even though at this
stage the list does not necessarily mean a list of "unkept" packs yet.

[5/6] removes --unpacked=<packfile> parameter, and adds --kept-pack-only
option.  The sole user of --unpacked=<packfile>, git-repack, is updated to
pass this option instead of listing the "unkept" packfiles on the command
line.

[6/6] reverts most of the effects of [3/6] made solely for reviewability
and removes is_kept_pack() helper function, which now is merely a lookup
of a structure member "p->pack_keep".

I think we probably could get rid of --honor-pack-keep mechanism after
this series, but I didn't look very deeply into it.

Junio C Hamano (6):
  git-repack: resist stray environment variable
  has_sha1_pack(): refactor "pretend these packs do not exist"
    interface
  has_sha1_kept_pack(): take "struct rev_info"
  Consolidate ignore_packed logic more
  Simplify is_kept_pack()
  is_kept_pack(): final clean-up

 builtin-count-objects.c |    2 +-
 builtin-fsck.c          |    2 +-
 builtin-pack-objects.c  |   14 ++--------
 builtin-prune-packed.c  |    2 +-
 cache.h                 |    4 +-
 diff.c                  |    2 +-
 git-repack.sh           |    6 ++++-
 revision.c              |   25 +++++++------------
 revision.h              |    6 +---
 sha1_file.c             |   60 ++++++++++++++++++++--------------------------
 10 files changed, 51 insertions(+), 72 deletions(-)

^ permalink raw reply

* git-svn, and which branch am I on?
From: Daniel Pittman @ 2009-02-28  8:50 UTC (permalink / raw)
  To: git

G'day.

I recently got asked a question about git-svn that I had no idea how to
answer, and which I am actually curious to know how to find out.

The general question was: in git, how do I identify where this branch
came from?

Specifically, this was about 'git svn', but also generally how to
identify this information in git.

So, with a repository branch layout like this:

  master        (local)
  testing       (local)
  trunk         (remote)
  v100          (remote)

How would I find out which remote branch master and trunk came from?


To restate that, because I am not sure if that is clear, given this
layout of branches:

     trunk (remote)
     |
 o---o---o---o---o  branch master
  \
   \
    o---o---o---o branch testing
    |
    v100 (remote)

How can I identify that 'testing' came from the 'v100' branch, and that
master came from the 'trunk' branch?


Ideally, I would like to work this out on the command line, without
needing to reference gitk or another graphical tool, but even a solution
that used them would be fine.

Initially I figured there would be some equivalent of the Mercurial
'glog' output available, showing this; for reference the second and
third examples here are what I was envisaging:
http://www.selenic.com/mercurial/wiki/index.cgi/GraphlogExtension

(from that display I could infer where testing and master came from,
 rather than directly getting the answer, but that is just fine.)


...and, finally, is the reason that I am finding it hard to explain this
because I have an expectation of how things work that doesn't match up
with git?  In other words, is the question actually meaningless?

Regards,
        Daniel

^ permalink raw reply

* Re: [PATCH] autoconf: Add limited support for --htmldir
From: Jakub Narebski @ 2009-02-28  7:59 UTC (permalink / raw)
  To: David Syzdek; +Cc: git
In-Reply-To: <9a0027270902272323y44091bfakcb640f168c33a824@mail.gmail.com>

On Sat, 28 Feb 2009, David Syzdek wrote:

> I tested the below patch using autoconf 2.59 and autoconf 2.62.  If
> the version of autoconf used to create the configure script supports
> the `--htmldir' option then the htmldir is set by either autoconf or
> the user defined value.  If the version of autoconf does not support
> the `--htmldir' option, then htmldir defaults to [DATADIR/doc/git].
> 
> This way a newer version of autoconf is not required for users on
> distros more than a year or so old, however users on newer distros are
> able to use the '--html' flag.

Thanks a lot.
-- 
Jakub Narebski
Poland

^ permalink raw reply

* Re: proper way to merge?
From: John Tapsell @ 2009-02-28  7:58 UTC (permalink / raw)
  To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E709F06FDA@EXCHANGE.trad.tradestation.com>

2009/2/27 John Dlugosz <JDlugosz@tradestation.com>:
> I'm merging two branches: let's say "dev" is for development of future
> releases, and "rel" is changes made to the current release for immediate
> application.  Now I want to bring the changes made in rel back to dev.
>
> Rather than trying to merge it all at once, I'm applying the changes a
> few at a time and making sure it still compiles as I go.  Then,
> git-reset and I have dev as my HEAD and the desired merge result in the
> working tree.
>
> Now, I want to introduce the proper commit node to show that this is the
> graft.  But, I don't want to be presented with all the differences that
> I already resolved; I know what it should look like already.  How do I
> commit the current state of things and have it show up with both dev and
> rel as parents? (then make that the new dev)
>
> I'm also interesting in learning how to do it better next time.  But I'm
> doing the incremental merging now and need to know how to conclude it.

Instead of merge, I prefer to rebase.  so:

git checkout dev
git rebase origin rel

This replays each commit made in 'dev' on top of release, letting you
fix each commit separately.  It also means that when I commit to
release, the changes are a nice tree.

This only works if you have a relatively small number of changes.  I
tried to rebase 50 patches from 'dev' to 'rel' where the patches
changed pretty much every file.  It took all day to do.  (But it was
still better than trying to merge, in my specific case)

JohnFlux



>
> --John
>
> TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

^ permalink raw reply

* [PATCH] autoconf: Add limited support for --htmldir
From: David Syzdek @ 2009-02-28  7:23 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git, Jeff King, Tim Visher

On Fri, Feb 27, 2009 at 4:57 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 28 Feb 2009, David Syzdek wrote:
>> On Fri, Feb 27, 2009 at 3:33 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> On Thu, 26 Feb 2009, Jeff King wrote:
>>>> On Thu, Feb 26, 2009 at 09:48:29AM -0500, Tim Visher wrote:
>>>>
>>>>> I'm working on getting git 1.6.2-rc2 built.  I have a bin, man, info,
>>>>> and html directory in my home folder that I'd like to use as the
>>>>> defaults for git.  I attempted to do this through
>>>>>
>>>>>     make configure
>>>>>     ./configure --XXdir=/full/path/to/dir
>>>>>     make all man info html
>>>>>     make install install-man install-info install-html
> [...]
>
>>>> The configure support is notoriously incomplete (AFAIK, very few of the
>>>> active developers use it regularly). Probably you need something like
>>>> this (but I didn't test it):
>>>>
>>>> diff --git a/config.mak.in b/config.mak.in
>>>> index 7cce0c1..505d5c7 100644
>>>> --- a/config.mak.in
>>>> +++ b/config.mak.in
>>>> @@ -18,6 +18,8 @@ datarootdir = @datarootdir@
>>>>  template_dir = @datadir@/git-core/templates
>>>>
>>>>  mandir=@mandir@
>>>> +htmldir=@htmldir@
>>>> +infodir=@infodir@
>>>>
>>>>  srcdir = @srcdir@
>>>>  VPATH = @srcdir@
>>>
>>> Well, the infodir part works trivially, because autoconf (and
>>> therefore ./configure script) has support for --infodir=DIR.
>>> Below there is patch that adds that, with the commit message.
>>>
>>> But it is more difficult with respect to --htmldir. I am not autoconf
>>> hacker, so I don't know how to add support for having --htmldir=DIR in
>>> ./configure (in configure.ac).  What can be done is to derive htmldir
>>> in config.mak.in from other sources, for example:
>>
>> Autoconf add support for --htmldir in version 2.60.  Here is a snippet from
>> the help message from a configure script generated with 2.60:
>>
>> --datarootdir=DIR       read-only arch.-independent data root [PREFIX/share]
>>
>> --docdir=DIR            documentation root [DATAROOTDIR/doc/PROJECT_TARNAME]
>>
>> --htmldir=DIR           html documentation [DOCDIR]
>>
>>
>> The current configure.ac requires autoconf version>= 2.59, bumping the
>> requirement to autoconf>= 2.60 would allow the autoconf variable $(htmldir)
>> to be used.  Bumping the required version of autoconf will affect users with
>> older linux installations who use git to upgrade git; and may affect the
>> maintainer's ability to create a "release" tarball if he has an older
>> version of autoconf.
>
> Well, I have autoconf 2.59, so I cannot test the following patch
> (and I am not sure if it is welcome). And of course it needs commit
> message, at least with explanation why bumping required version of
> autoconf was needed.

I tested the below patch using autoconf 2.59 and autoconf 2.62.  If
the version of autoconf used to create the configure script supports
the `--htmldir' option then the htmldir is set by either autoconf or
the user defined value.  If the version of autoconf does not support
the `--htmldir' option, then htmldir defaults to [DATADIR/doc/git].

This way a newer version of autoconf is not required for users on
distros more than a year or so old, however users on newer distros are
able to use the '--html' flag.

-- >8 --
Add support for --htmdir=DIR [DATAROOT/doc/git] if the configure
script is created with autoconf 2.60 or higher. htmldir defaults to
[DATADIR/doc/git] if the configure script is created with autoconf
2.59 or lower.

Signed-off-by: David M. Syzdek <david@syzdek.net>
---
 config.mak.in |    1 +
 configure.ac  |    7 +++++++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/config.mak.in b/config.mak.in
index 7cce0c1..5ae076e 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -18,6 +18,7 @@ datarootdir = @datarootdir@
 template_dir = @datadir@/git-core/templates

 mandir=@mandir@
+htmldir=@htmldir@

 srcdir = @srcdir@
 VPATH = @srcdir@
diff --git a/configure.ac b/configure.ac
index 082a03d..6e16034 100644
--- a/configure.ac
+++ b/configure.ac
@@ -107,6 +107,13 @@ AS_HELP_STRING([],[Bare --with-tcltk will make
the GUI part only if])
 AS_HELP_STRING([],[Tcl/Tk interpreter will be found in a system.]),\
 GIT_PARSE_WITH(tcltk))
 #
+# Define ${htmldir} if the configure script was created with a version of
+# autoconf older than 2.60.
+if test "x${htmldir}" = "x";then
+   htmldir="${datadir}/doc/${PACKAGE_TARNAME}"
+   AC_SUBST(htmldir, [${htmldir}])
+fi
+#


 ## Checks for programs.
-- 
1.6.2.rc2.268.g13cc9

^ permalink raw reply related

* counting the number of connections?
From: Tay Ray Chuan @ 2009-02-28  6:44 UTC (permalink / raw)
  To: git

Hi,

some time ago I noticed curl doesn't remember your credentials (apart
from those it can get from ~/.netrc), and very recently there was an
thread on repeated prompting for credentials while pushing to https.

I've written a simple patch series, which allows git to play nice
without curl_multi. That is, git uses a single persistent connection
throughout.

However, I'm at a loss at how to test for this. How does one count the
number of connections made during the lifespan of a program's
execution? So far, I've been relying on my firewall log (Comodo on
windows). Perhaps there a more operating system/software-agnostic
method to do this?

-- 
Cheers,
Ray Chuan

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox