* Re: git-cvsimport BUG: some commits are completely out of phase (but cvsps sees them all right)
From: Shawn O. Pearce @ 2008-11-03 19:08 UTC (permalink / raw)
To: Samuel Lucas Vaz de Mello; +Cc: Michael Haggerty, git
In-Reply-To: <490F4B1E.2080707@datacom.ind.br>
Samuel Lucas Vaz de Mello <samuellucas@datacom.ind.br> wrote:
> Michael Haggerty wrote:
> > Francis Galiegue wrote:
> >> The plan would be to convert all modules in one go, with no one committing in
> >> the meantime, so that's not a problem.
> >
> > Then you should definitely try cvs2svn/cvs2git [1]. cvsps-based
> > conversion tools all have known and unavoidable problems due to the
> > limitations of cvsps.
>
> Does cvs2git plans to support incremental importing?
No, it doesn't, and likely never will. Computing the
change sets from CVS is ugly and more-or-less requires
that you do it all in one pass.
--
Shawn.
^ permalink raw reply
* Re: git-cvsimport BUG: some commits are completely out of phase (but cvsps sees them all right)
From: Samuel Lucas Vaz de Mello @ 2008-11-03 19:03 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <490F1021.1090002@alum.mit.edu>
Michael Haggerty wrote:
> Francis Galiegue wrote:
>> The plan would be to convert all modules in one go, with no one committing in
>> the meantime, so that's not a problem.
>
> Then you should definitely try cvs2svn/cvs2git [1]. cvsps-based
> conversion tools all have known and unavoidable problems due to the
> limitations of cvsps.
>
Michael,
Does cvs2git plans to support incremental importing?
- Samuel
^ permalink raw reply
* Re: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable
From: Andy Parkins @ 2008-11-03 18:58 UTC (permalink / raw)
To: Pete Harlan; +Cc: git
In-Reply-To: <1225668059-12670-1-git-send-email-pgit@pcharlan.com>
On Sunday 02 November 2008 23:20:59 Pete Harlan wrote:
> Add configuration option hooks.showrev, letting the user override how
> revisions will be shown in the commit email.
>
> Signed-off-by: Pete Harlan <pgit@pcharlan.com>
Acked-By: Andy Parkins <andyparkins@gmail.com>
--
Dr Andy Parkins
andyparkins@gmail.com
^ permalink raw reply
* Re: [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Francis Galiegue @ 2008-11-03 18:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alexander Gavrilov, git
In-Reply-To: <m38ws0fzca.fsf@localhost.localdomain>
Le Monday 03 November 2008 19:18:56 Jakub Narebski, vous avez écrit :
> >
> > Well, as far as Apache is concerned, it can do:
> >
> > * basic .htpasswd authentication,
> > * LDAP,
> > * PAM,
> > * SSL certificate check (via mod_ssl),
> > * probably others.
> >
> > Plenty of possibilities.
> [...]
>
> Well, the question is if Apache (and other web servers used with
> gitweb) can do authentication based on path_info or on query-string.
> Because it is encoded in gitweb (via $projectroot) where to find git
> repositories...
>
Can you expand on path_info and query-string? Keep in mind that Apache
has mod_rewrite, which can rewrite URLs in any way before it gets
actually sent to the underlying program (whether it be a CGI or
anything else), even badly (or mischievously).
--
fge
^ permalink raw reply
* Re: git bisect v2.6.27 v2.6.26 problem/bug
From: Linus Torvalds @ 2008-11-03 18:43 UTC (permalink / raw)
To: Miquel van Smoorenburg; +Cc: git
In-Reply-To: <20081103173911.GA12363@xs4all.net>
On Mon, 3 Nov 2008, Miquel van Smoorenburg wrote:
>
> If at this point I do a 'git bisect good' I end up in a 2.6.26
> branch, which is good, but after a few bisects I end up at
> a version before v2.6.26 (2.6.26-rc5) again, which should be
> impossible right ?
No, not at all.
What is going on is that you are hitting commits that were not merged into
2.6.26 (so they are _not_ in the "good" part), but they were _developed_
before it. So the kernel Makefile says "v2.6.26-rc8" (not quite 2.6.26
yet), but that's because the version in the Makefile ends up being a
linear explanation of what the nearest _earlier_ version was, but is not
at all indicative of the much more complex non-linear development model.
IOW, you have history that looks like
- A -> B -> C->
\ /
- D -
And let's say that 'A' is v2.6.26-rc8, while 'B' is the final v2.6.26
release, and is your 'good', while 'C' is 2.6.27, and is your 'bad'.
What does that make 'D' then?
It is clearly potentially bad, because it is _not_ in the good set (it was
merged after 2.6.26, and could very well be the source of your bug. But
think about what 'Makefile' must contain in 'D'.
The difference between linear history and non-linear history is very
important, and "git bisect" very much is all about getting it right. It
does't take a "linear" half-way point, it really does a _set_ operation,
and it bisects the set of commits. And that set of commits is a DAG, not a
linear series.
> Anyway - at the end I end up with a 'good' version that is
> 2.6.26-rc<something> which is kind of useless. I know that
> version up to 2.6.26 are good ...
Not at all. It's not "kind of useless", it's very important.
> What am I doing wrong ?
You're not doing anything wrong, you just didn't realize how non-linear
development works.
Linus
^ permalink raw reply
* Re: [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Jakub Narebski @ 2008-11-03 18:18 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Alexander Gavrilov, git
In-Reply-To: <200811031845.46451.fg@one2team.net>
Francis Galiegue <fg@one2team.net> writes:
> Le Monday 03 November 2008 18:26:44 Alexander Gavrilov, vous avez écrit :
>> On Mon, Nov 3, 2008 at 7:54 PM, Francis Galiegue <fg@one2team.net> wrote:
>>>
>>> It just seems to me that this is emulating functionality that
>>> multiple Web servers already provide...
>>>
>>> What's more, knowledge about these Web servers are _much_ more
>>> widespread than knowledge about gitweb.
>>>
>>> Why reinvent the wheel?
[...]
>> If you are speaking of web servers as in 'Apache', then how would it
>> know which files are going to be accessed when it executes
>> cgi-bin/gitweb.cgi?p=very/private/project.git to check permissions?
>>
>
> Well, as far as Apache is concerned, it can do:
>
> * basic .htpasswd authentication,
> * LDAP,
> * PAM,
> * SSL certificate check (via mod_ssl),
> * probably others.
>
> Plenty of possibilities.
[...]
Well, the question is if Apache (and other web servers used with
gitweb) can do authentication based on path_info or on query-string.
Because it is encoded in gitweb (via $projectroot) where to find git
repositories...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [Announce] teamGit v0.0.4
From: Alex Riesen @ 2008-11-03 18:28 UTC (permalink / raw)
To: Abhijit Bhopatkar; +Cc: Matthieu Moy, git
In-Reply-To: <2fcfa6df0811030535m208999ben2608878fb0978fae@mail.gmail.com>
Abhijit Bhopatkar, Mon, Nov 03, 2008 14:35:24 +0100:
> teamGit is a GUI for git,
> in its final roadmap it aims to aid small closed teams to use git,
What special features does it offer to aid small closed teams?
Why are they "closed"?
^ permalink raw reply
* Re: [PATCH 1/3] packed_git: convert pack_local flag into generic bit mask
From: Brandon Casey @ 2008-11-03 18:24 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: drafnel, git, gitster, nico
In-Reply-To: <20081103161202.GJ15463@spearce.org>
Shawn O. Pearce wrote:
> drafnel@gmail.com wrote:
>> diff --git a/cache.h b/cache.h
>> index b0edbf9..0cb9350 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -679,12 +679,15 @@ extern struct packed_git {
>> int index_version;
>> time_t mtime;
>> int pack_fd;
>> - int pack_local;
>> + unsigned int flags;
>
> Hmm, isn't this a smaller change to make?
heh, well if you want to do it the "easy" way. :)
For some reason I've never used this bit field mechanism, but
I agree it is more readable and simpler, and you can't argue
with that.
-brandon
^ permalink raw reply
* Re: [PATCH] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Brandon Casey @ 2008-11-03 18:20 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: drafnel, git, gitster, nico
In-Reply-To: <490ED3FE.8040103@op5.se>
Andreas Ericsson wrote:
> drafnel@gmail.com wrote:
>> From: Brandon Casey <drafnel@gmail.com>
>>
>> Objects residing in pack files that have an associated .keep file are not
>> supposed to be repacked into new pack files, but they are.
>>
>
> I think that's a misconception. Packfiles that are marked with .keep files
> should never be deleted. There are, afaik, no rules against packing the
> same objects into other packfiles as well. This is nifty for dumb ref
> walkers, as they can use a small pack for incremental fetching while using
> a mega-pack for initial cloning.
Having no rules against an object residing in more than one pack is different
from intending for git to produce pack files with redundant objects.
I think one intention for the .keep mechanism was to allow for a size optimized
pack to be produced and distributed. Currently, if I am handed such a pack file,
I can not merely place it into my pack directory (along with the .idx and .keep
files) and then run git-gc to remove any redundancy. Instead, I would get
a _new_ pack file which would contain all of the objects in the repository and
effectively double the size of my objects store. That doesn't seem like
something a user would expect or should expect.
-brandon
^ permalink raw reply
* Re: [PATCH] Make Pthread link flags configurable
From: Jakub Narebski @ 2008-11-03 18:26 UTC (permalink / raw)
To: David Syzdek; +Cc: David M. Syzdek, git
In-Reply-To: <9a0027270811031018t2b90ee64kcd2ef5e9afa73f6a@mail.gmail.com>
David Syzdek wrote:
> On Mon, Nov 3, 2008 at 12:44 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> david.syzdek@acsalaska.net writes:
>>
>>> From: David M. Syzdek <david.syzdek@acsalaska.net>
>>>
>>> FreeBSD 4.x systems use the linker flags `-pthread' instead of the
>>> linker flags `-lpthread' when linking against the pthread library.
>>>
>>> Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net>
>>> ---
>>> Makefile | 4 +++-
>>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> Would it be possible to add support for this also to configure.ac
>> (and config.mak.in)?
>>
>
> I just sent a patch to the list that adds autoconf tests for pthreads.
> If the test is able to determine which flag to use, then it also sets
> THREADED_DELTA_SEARCH.
Thanks a lot.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Implement git remote rename
From: Miklos Vajna @ 2008-11-03 18:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <7v63nh1sc7.fsf@gitster.siamese.dyndns.org>
The new rename subcommand does the followings:
1) Renames the remote.foo configuration section to remote.bar
2) Updates the remote.bar.fetch refspecs
3) Updates the branch.*.remote settings
4) Renames the tracking branches: renames the normal refs and rewrites
the symrefs to point to the new refs.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Fri, Oct 24, 2008 at 04:33:28PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Hmm, remote_get() can read from all three supported places that you
> can define remotes. Could you explain what happens if the old remote
> is read from say $GIT_DIR/remotes/origin and you are renaming it to
> "upstream" with "git remote rename origin upstream"?
Currently it dies because it can't rename config section 'remote.origin'
to 'remote.upstream'.
> I suspect that if you record where you read the configuration from in
> "struct remote" and add necessary code to remove the original when
> rename.old is *not* coming from in-config definition, you would make
> it possible for repositories initialized with older git that has
> either $GIT_DIR/branches/origin or $GIT_DIR/remotes/origin to be
> migrated to the in-config format using "git remote rename origin
> origin".
Yes, that's possible. I think the patch is already large enough that it
would be better to do it as a separate patch, but I like the idea.
One important step is that currently we have to care about the
remote.upstream.fetch variable, but once migration is supported, we have
to pay attention to remote.upstream.url/push as well.
In the meantime here is an updated patch which applies on top of
mv/maint-branch-m-symref. However, it is not meant for 'maint', of
course. :)
The old version did not "rename" (in fact it is not just a rename but it
replaces origin with upstream in the contents) symrefs properly, now the
testcases are extended to check for this, too.
Documentation/git-remote.txt | 6 ++
builtin-remote.c | 153 ++++++++++++++++++++++++++++++++++++++++++
t/t5505-remote.sh | 15 ++++
3 files changed, 174 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index bb99810..7b227b3 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -11,6 +11,7 @@ SYNOPSIS
[verse]
'git remote' [-v | --verbose]
'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+'git remote rename' <old> <new>
'git remote rm' <name>
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
@@ -61,6 +62,11 @@ only makes sense in bare repositories. If a remote uses mirror
mode, furthermore, `git push` will always behave as if `\--mirror`
was passed.
+'rename'::
+
+Rename the remote named <old> to <new>. All remote tracking branches and
+configuration settings for the remote are updated.
+
'rm'::
Remove the remote named <name>. All remote tracking branches and
diff --git a/builtin-remote.c b/builtin-remote.c
index e396a3a..1ca6cdb 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -10,6 +10,7 @@
static const char * const builtin_remote_usage[] = {
"git remote",
"git remote add <name> <url>",
+ "git remote rename <old> <new>",
"git remote rm <name>",
"git remote show <name>",
"git remote prune <name>",
@@ -329,6 +330,156 @@ static int add_branch_for_removal(const char *refname,
return 0;
}
+struct rename_info {
+ const char *old;
+ const char *new;
+ struct string_list *remote_branches;
+};
+
+static int read_remote_branches(const char *refname,
+ const unsigned char *sha1, int flags, void *cb_data)
+{
+ struct rename_info *rename = cb_data;
+ struct strbuf buf = STRBUF_INIT;
+ struct string_list_item *item;
+ int flag;
+ unsigned char orig_sha1[20];
+ const char *symref;
+
+ strbuf_addf(&buf, "refs/remotes/%s", rename->old);
+ if(!prefixcmp(refname, buf.buf)) {
+ item = string_list_append(xstrdup(refname), rename->remote_branches);
+ symref = resolve_ref(refname, orig_sha1, 1, &flag);
+ if (flag & REF_ISSYMREF)
+ item->util = xstrdup(symref);
+ else
+ item->util = NULL;
+ }
+
+ return 0;
+}
+
+static int mv(int argc, const char **argv)
+{
+ struct option options[] = {
+ OPT_END()
+ };
+ struct remote *oldremote, *newremote;
+ struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT, buf3 = STRBUF_INIT;
+ struct string_list remote_branches = { NULL, 0, 0, 0 };
+ struct rename_info rename;
+ int i;
+
+ if (argc != 3)
+ usage_with_options(builtin_remote_usage, options);
+
+ rename.old = argv[1];
+ rename.new = argv[2];
+ rename.remote_branches = &remote_branches;
+
+ oldremote = remote_get(rename.old);
+ if (!oldremote)
+ die("No such remote: %s", rename.old);
+
+ newremote = remote_get(rename.new);
+ if (newremote && (newremote->url_nr > 1 || newremote->fetch_refspec_nr))
+ die("remote %s already exists.", rename.new);
+
+ strbuf_addf(&buf, "refs/heads/test:refs/remotes/%s/test", rename.new);
+ if (!valid_fetch_refspec(buf.buf))
+ die("'%s' is not a valid remote name", rename.new);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s", rename.old);
+ strbuf_addf(&buf2, "remote.%s", rename.new);
+ if (git_config_rename_section(buf.buf, buf2.buf) < 1)
+ return error("Could not rename config section '%s' to '%s'",
+ buf.buf, buf2.buf);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.fetch", rename.new);
+ if (git_config_set_multivar(buf.buf, NULL, NULL, 1))
+ return error("Could not remove config section '%s'", buf.buf);
+ for (i = 0; i < oldremote->fetch_refspec_nr; i++) {
+ char *ptr;
+
+ strbuf_reset(&buf2);
+ strbuf_addstr(&buf2, oldremote->fetch_refspec[i]);
+ ptr = strstr(buf2.buf, rename.old);
+ if (ptr)
+ strbuf_splice(&buf2, ptr-buf2.buf, strlen(rename.old),
+ rename.new, strlen(rename.new));
+ if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
+ return error("Could not append '%s'", buf.buf);
+ }
+
+ read_branches();
+ for (i = 0; i < branch_list.nr; i++) {
+ struct string_list_item *item = branch_list.items + i;
+ struct branch_info *info = item->util;
+ if (info->remote && !strcmp(info->remote, rename.old)) {
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "branch.%s.remote", item->string);
+ if (git_config_set(buf.buf, rename.new)) {
+ return error("Could not set '%s'", buf.buf);
+ }
+ }
+ }
+
+ /*
+ * First remove symrefs, then rename the rest, finally create
+ * the new symrefs.
+ */
+ for_each_ref(read_remote_branches, &rename);
+ for (i = 0; i < remote_branches.nr; i++) {
+ struct string_list_item *item = remote_branches.items + i;
+ int flag = 0;
+ unsigned char sha1[20];
+ const char *symref;
+
+ symref = resolve_ref(item->string, sha1, 1, &flag);
+ if (!(flag & REF_ISSYMREF))
+ continue;
+ if (delete_ref(item->string, NULL, REF_NODEREF))
+ die("deleting '%s' failed", item->string);
+ }
+ for (i = 0; i < remote_branches.nr; i++) {
+ struct string_list_item *item = remote_branches.items + i;
+
+ if (item->util)
+ continue;
+ strbuf_reset(&buf);
+ strbuf_addstr(&buf, item->string);
+ strbuf_splice(&buf, strlen("refs/remotes/"), strlen(rename.old),
+ rename.new, strlen(rename.new));
+ strbuf_reset(&buf2);
+ strbuf_addf(&buf2, "remote: renamed %s to %s",
+ item->string, buf.buf);
+ if (rename_ref(item->string, buf.buf, buf2.buf))
+ die("renaming '%s' failed", item->string);
+ }
+ for (i = 0; i < remote_branches.nr; i++) {
+ struct string_list_item *item = remote_branches.items + i;
+
+ if (!item->util)
+ continue;
+ strbuf_reset(&buf);
+ strbuf_addstr(&buf, item->string);
+ strbuf_splice(&buf, strlen("refs/remotes/"), strlen(rename.old),
+ rename.new, strlen(rename.new));
+ strbuf_reset(&buf2);
+ strbuf_addstr(&buf2, item->util);
+ strbuf_splice(&buf2, strlen("refs/remotes/"), strlen(rename.old),
+ rename.new, strlen(rename.new));
+ strbuf_reset(&buf3);
+ strbuf_addf(&buf3, "remote: renamed %s to %s",
+ item->string, buf.buf);
+ if (create_symref(buf.buf, buf2.buf, buf3.buf))
+ die("creating '%s' failed", buf.buf);
+ }
+ return 0;
+}
+
static int remove_branches(struct string_list *branches)
{
int i, result = 0;
@@ -695,6 +846,8 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
result = show_all();
else if (!strcmp(argv[0], "add"))
result = add(argc, argv);
+ else if (!strcmp(argv[0], "rename"))
+ result = mv(argc, argv);
else if (!strcmp(argv[0], "rm"))
result = rm(argc, argv);
else if (!strcmp(argv[0], "show"))
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index c4380c7..0c956ba 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -328,4 +328,19 @@ test_expect_success 'reject adding remote with an invalid name' '
'
+# The first three test if the tracking branches are properly renamed,
+# the last two ones check if the config is updated.
+
+test_expect_success 'rename a remote' '
+
+ git clone one four &&
+ (cd four &&
+ git remote rename origin upstream &&
+ rmdir .git/refs/remotes/origin &&
+ test "$(git symbolic-ref refs/remotes/upstream/HEAD)" = "refs/remotes/upstream/master" &&
+ test "$(git rev-parse upstream/master)" = "$(git rev-parse master)" &&
+ test "$(git config remote.upstream.fetch)" = "+refs/heads/*:refs/remotes/upstream/*" &&
+ test "$(git config branch.master.remote)" = "upstream")
+
+'
test_done
--
1.6.0.2
^ permalink raw reply related
* Re: git bisect v2.6.27 v2.6.26 problem/bug
From: Alejandro Riveira @ 2008-11-03 18:23 UTC (permalink / raw)
To: git
In-Reply-To: <20081103173911.GA12363@xs4all.net>
El Mon, 03 Nov 2008 18:39:15 +0100, Miquel van Smoorenburg escribió:
> I'm trying to nail down a disk statistics issue that was introduced in
> 2.6.27, while 2.6.26 was working OK. So I decided to use git bisect.
>
> However, sometimes I end up with a version before 2.6.26:
>
> $ cat .git/BISECT_LOG
> git-bisect start
> # good: [bce7f793daec3e65ec5c5705d2457b81fe7b5725] Linux 2.6.26
> git-bisect good bce7f793daec3e65ec5c5705d2457b81fe7b5725 # bad:
> [3fa8749e584b55f1180411ab1b51117190bac1e5] Linux 2.6.27 git-bisect bad
> 3fa8749e584b55f1180411ab1b51117190bac1e5 # bad:
> [dd9ca5d9be7eba99d685d733e23d5be7110e9556] USB: usb-serial: fix a sparse
> warning about different signedness git-bisect bad
> dd9ca5d9be7eba99d685d733e23d5be7110e9556 # good:
> [84c3d4aaec3338201b449034beac41635866bddf] Merge commit 'origin/master'
> git-bisect good 84c3d4aaec3338201b449034beac41635866bddf
>
> $ head -4 Makefile
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 26
> EXTRAVERSION = -rc8
>
> If at this point I do a 'git bisect good' I end up in a 2.6.26 branch,
> which is good, but after a few bisects I end up at a version before
> v2.6.26 (2.6.26-rc5) again, which should be impossible right ?
Afaik it is not imposible with git you do not get a linear history
>
> Anyway - at the end I end up with a 'good' version that is
> 2.6.26-rc<something> which is kind of useless. I know that version up to
> 2.6.26 are good ...
>
> What am I doing wrong ?
>
> (git version 1.5.6.5 from debian/lenny)
>
> Mike.
^ permalink raw reply
* Re: [PATCH] Make Pthread link flags configurable
From: David Syzdek @ 2008-11-03 18:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David M. Syzdek, git
In-Reply-To: <m3hc6pf8k6.fsf@localhost.localdomain>
On Mon, Nov 3, 2008 at 12:44 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> david.syzdek@acsalaska.net writes:
>
>> From: David M. Syzdek <david.syzdek@acsalaska.net>
>>
>> FreeBSD 4.x systems use the linker flags `-pthread' instead of the
>> linker flags `-lpthread' when linking against the pthread library.
>>
>> Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net>
>> ---
>> Makefile | 4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> Would it be possible to add support for this also to configure.ac
> (and config.mak.in)?
>
I just sent a patch to the list that adds autoconf tests for pthreads.
If the test is able to determine which flag to use, then it also sets
THREADED_DELTA_SEARCH.
^ permalink raw reply
* [PATCH] Add autoconf tests for pthreads
From: david.syzdek @ 2008-11-03 18:14 UTC (permalink / raw)
To: git; +Cc: jnareb, David M. Syzdek
From: David M. Syzdek <david.syzdek@acsalaska.net>
Sets the value of PTHREAD_LIBS to the correct flags for linking pthreads on
the current environment. If the correct flags can be determined then
THREADED_DELTA_SEARCH is set. If the correct flags cannot be determined,
then THREADED_DELTA_SEARCH is unset.
Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net>
---
config.mak.in | 2 ++
configure.ac | 20 ++++++++++++++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index 7170729..3d3fbcd 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -51,3 +51,5 @@ OLD_ICONV=@OLD_ICONV@
NO_DEFLATE_BOUND=@NO_DEFLATE_BOUND@
FREAD_READS_DIRECTORIES=@FREAD_READS_DIRECTORIES@
SNPRINTF_RETURNS_BOGUS=@SNPRINTF_RETURNS_BOGUS@
+THREADED_DELTA_SEARCH=@THREADED_DELTA_SEARCH@
+PTHREAD_LIBS=@PTHREAD_LIBS@
diff --git a/configure.ac b/configure.ac
index 9dfc0d3..3bf5d15 100644
--- a/configure.ac
+++ b/configure.ac
@@ -489,6 +489,26 @@ AC_SUBST(NO_MKDTEMP)
#
# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
# Enable it on Windows. By default, symrefs are still used.
+#
+# Define PTHREAD_LIBS to the linker flag used for Pthread support and define
+# THREADED_DELTA_SEARCH if Pthreads are available.
+AC_LANG_CONFTEST([AC_LANG_PROGRAM(
+ [[#include <pthread.h>]],
+ [[pthread_mutex_t test_mutex;]]
+)])
+${CC} -pthread conftest.c -o conftest.o > /dev/null 2>&1
+if test $? -eq 0;then
+ PTHREAD_LIBS="-pthread"
+ THREADED_DELTA_SEARCH=YesPlease
+else
+ ${CC} -lpthread conftest.c -o conftest.o > /dev/null 2>&1
+ if test $? -eq 0;then
+ PTHREAD_LIBS="-lpthread"
+ THREADED_DELTA_SEARCH=YesPlease
+ fi
+fi
+AC_SUBST(PTHREAD_LIBS)
+AC_SUBST(THREADED_DELTA_SEARCH)
## Site configuration (override autodetection)
## --with-PACKAGE[=ARG] and --without-PACKAGE
--
1.6.0.2.GIT
^ permalink raw reply related
* git bisect v2.6.27 v2.6.26 problem/bug
From: Miquel van Smoorenburg @ 2008-11-03 17:39 UTC (permalink / raw)
To: git; +Cc: mikevs
I'm trying to nail down a disk statistics issue that was introduced
in 2.6.27, while 2.6.26 was working OK. So I decided to use git bisect.
However, sometimes I end up with a version before 2.6.26:
$ cat .git/BISECT_LOG
git-bisect start
# good: [bce7f793daec3e65ec5c5705d2457b81fe7b5725] Linux 2.6.26
git-bisect good bce7f793daec3e65ec5c5705d2457b81fe7b5725
# bad: [3fa8749e584b55f1180411ab1b51117190bac1e5] Linux 2.6.27
git-bisect bad 3fa8749e584b55f1180411ab1b51117190bac1e5
# bad: [dd9ca5d9be7eba99d685d733e23d5be7110e9556] USB: usb-serial: fix a sparse warning about different signedness
git-bisect bad dd9ca5d9be7eba99d685d733e23d5be7110e9556
# good: [84c3d4aaec3338201b449034beac41635866bddf] Merge commit 'origin/master'
git-bisect good 84c3d4aaec3338201b449034beac41635866bddf
$ head -4 Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 26
EXTRAVERSION = -rc8
If at this point I do a 'git bisect good' I end up in a 2.6.26
branch, which is good, but after a few bisects I end up at
a version before v2.6.26 (2.6.26-rc5) again, which should be
impossible right ?
Anyway - at the end I end up with a 'good' version that is
2.6.26-rc<something> which is kind of useless. I know that
version up to 2.6.26 are good ...
What am I doing wrong ?
(git version 1.5.6.5 from debian/lenny)
Mike.
^ permalink raw reply
* Re: [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Francis Galiegue @ 2008-11-03 17:45 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <bb6f213e0811030926n32c1befcj5d9add6378f7dce4@mail.gmail.com>
Le Monday 03 November 2008 18:26:44 Alexander Gavrilov, vous avez écrit :
> On Mon, Nov 3, 2008 at 7:54 PM, Francis Galiegue <fg@one2team.net> wrote:
> > It just seems to me that this is emulating functionality that multiple Web servers already provide...
> >
> > What's more, knowledge about these Web servers are _much_ more widespread than knowledge about gitweb.
> >
> > Why reinvent the wheel?
>
> If you are speaking of web servers as in 'GitHub', then it is
> irrelevant, because its server software is nonfree.
>
I didn't even account for these.
> If you are speaking of web servers as in 'Apache', then how would it
> know which files are going to be accessed when it executes
> cgi-bin/gitweb.cgi?p=very/private/project.git to check permissions?
>
Well, as far as Apache is concerned, it can do:
* basic .htpasswd authentication,
* LDAP,
* PAM,
* SSL certificate check (via mod_ssl),
* probably others.
Plenty of possibilities.
Well, that's just mho. But if ever I complete my current work on
git-cvsimport (or using git2(svn|git)), I'll go for option 2: my LDAP
database has all the info, and Apache knows about Cache-Control, not
gitweb...
NOTE: I'm just saying here that your patch is of no use as far as _I_
am concerned. I'm basically saying that git cannot account for all
authentication schemes out there. Neither can Apache, but it supports a
buckload of them already.
--
fge
^ permalink raw reply
* Re: [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Alexander Gavrilov @ 2008-11-03 17:26 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811031754.00545.fg@one2team.net>
On Mon, Nov 3, 2008 at 7:54 PM, Francis Galiegue <fg@one2team.net> wrote:
> It just seems to me that this is emulating functionality that multiple Web servers already provide...
>
> What's more, knowledge about these Web servers are _much_ more widespread than knowledge about gitweb.
>
> Why reinvent the wheel?
If you are speaking of web servers as in 'GitHub', then it is
irrelevant, because its server software is nonfree.
If you are speaking of web servers as in 'Apache', then how would it
know which files are going to be accessed when it executes
cgi-bin/gitweb.cgi?p=very/private/project.git to check permissions?
Alexander
^ permalink raw reply
* Re: [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Francis Galiegue @ 2008-11-03 16:54 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200811031943.30033.angavrilov@gmail.com>
Le Monday 03 November 2008 17:43:29, vous avez écrit :
> Some environments may require selective limiting of read access to
> repositories. While even dumb http transport supports it through .htaccess
> files, gitweb currently does not implement discretionary access control.
>
> This patch adds a configuration-contolled check that matches simple
> 'Reguire user'/'Reguire group' lines in the .htaccess files with the
> authenticated user name. Using group authentication requires specifying
> a path to the Apache group file in the configuration.
>
> Using htaccess has an additional bonus that the same authentication
> data can be used both for gitweb and the dumb http transport.
>
> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
It just seems to me that this is emulating functionality that multiple Web servers already provide...
What's more, knowledge about these Web servers are _much_ more widespread than knowledge about gitweb.
Why reinvent the wheel?
Just a thought,
--
fge
^ permalink raw reply
* Re: CRLF support bugs (was: Re: .gitattributes glob matching broken)
From: Dmitry Potapov @ 2008-11-03 16:46 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git, Jeff King
In-Reply-To: <83y700alzf.fsf_-_@kalahari.s2.org>
On Mon, Nov 03, 2008 at 05:05:24PM +0200, Hannu Koivisto wrote:
>
> Actually, even if .gitattributes were applied in checkout, I think
> the whole CRLF support is broken by design because people will have
> to remember to use -n in clone, then enable core.autocrlf support
> and then checkout. This makes it unneccessarily complicated to
> create "quick local clones" as well. You might suggest that
> Windows users should enable core.autocrlf globally but it may not
> be the right thing to do for all projects/repositories either.
core.autocrlf was exactly meant to be set globally. Basically,
it says what end-of-line should be on your system. It is strange
to have it different for different repositories.
>
> I think CRLF conversion support should have some attribute (be it
> .gitattributes attribute or something else) that is somehow
> inherited from the parent repository. It would basically say that
> "you should use platform's native line end type for text files with
> this repository and its children".
It is already so. All text files are treated accordingly to users
preferences, and for those files where automatic heuristic produces
undesirable result, it can be disabled using .gitattributes. (Alas,
there is a bug with checkout that you encountered earlier).
> To go with that, one would
> maybe have a configuration option to tell what that platform
> default line end type is (just in case someone wants to pretend
> Cygwin is Unix or something like that).
That is exactly what core.autocrlf is about. One user may want to
have LF on Windows and another wants CRLF. So, core.autocrlf defines
how text files should be treated. It is what each user may have in
his/her own ~/.gitconfig.
>
> I also observed this problem:
>
> # Pretend someone does this on Unix
> mkdir test1
> cd test1
> git init
> echo "*.c crlf" > .gitattributes
> echo -en "foo\r\nfoo\r\nfoo\r\n" > kala.c
The 'crlf' attribute means that the file should be treated as 'text'
without applying heuristic. The correct ending for text files on Unix
is '\n', not '\r\n'. So, you put a text file with incorrect ending,
not surprisingly it causes problems for Windows users later.
Dmitry
^ permalink raw reply
* [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Alexander Gavrilov @ 2008-11-03 16:43 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Giuseppe Bilotta
Some environments may require selective limiting of read access to
repositories. While even dumb http transport supports it through .htaccess
files, gitweb currently does not implement discretionary access control.
This patch adds a configuration-contolled check that matches simple
'Reguire user'/'Reguire group' lines in the .htaccess files with the
authenticated user name. Using group authentication requires specifying
a path to the Apache group file in the configuration.
Using htaccess has an additional bonus that the same authentication
data can be used both for gitweb and the dumb http transport.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
I also created a gitosis fork that can generate the necessary files:
http://repo.or.cz/w/gitosis/httpauth.git
-- Alexander
gitweb/INSTALL | 14 ++++++++++
gitweb/gitweb.perl | 68 +++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 79 insertions(+), 3 deletions(-)
diff --git a/gitweb/INSTALL b/gitweb/INSTALL
index 26967e2..0841db6 100644
--- a/gitweb/INSTALL
+++ b/gitweb/INSTALL
@@ -166,6 +166,20 @@ Gitweb repositories
shows repositories only if this file exists in its object database
(if directory has the magic file named $export_ok).
+- Finally, it is possible to use primitive .htaccess authentication by
+ enabling the $check_htaccess variable in the config file. Gitweb
+ recognizes the following htaccess commands:
+
+ Require user name1 name2 ... # grant access to the listed users
+ Require group group1 group2 ... # grant access to the listed groups
+ Deny from all # deny unless overridden by a Require
+
+ Access is granted if the currently authenticated user matches one
+ of the Require lines, or if the file does not contain any of the listed
+ commands, or if .htaccess does not exist. If the file exists but cannot
+ be opened, access is denied. To use group authentication you have to
+ point $auth_group_file to the group list in Apache format.
+
Generating projects list using gitweb
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 63c793e..4b962c3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -98,6 +98,12 @@ our $export_ok = "++GITWEB_EXPORT_OK++";
# only allow viewing of repositories also shown on the overview page
our $strict_export = "++GITWEB_STRICT_EXPORT++";
+# check basic authentication rules in .htaccess
+our $check_htaccess = 0;
+
+# name of the file that lists groups for htaccess check
+our $auth_group_file = "";
+
# list of git base URLs used for URL to where fetch project from,
# i.e. full URL is "$git_base_url/$project"
our @git_base_url_list = grep { $_ ne '' } ("++GITWEB_BASE_URL++");
@@ -397,10 +403,64 @@ sub check_head_link {
(-l $headfile && readlink($headfile) =~ /^refs\/heads\//));
}
+# set of htaccess groups for the current user
+our %cur_auth_groups = ();
+
+sub find_current_groups($$) {
+ my ($gfile, $user) = @_;
+ return () unless $gfile && $user;
+
+ my @groups;
+ open my $gf, $gfile or return ();
+
+ while(<$gf>) {
+ next unless /^\s*(\S+)\s*:\s*(\S.*\S)\s*$/;
+ my ($grp, $usrs) = ($1, $2);
+ push @groups, $grp if grep { $_ eq $user } split (' ', $usrs);
+ }
+
+ close $gf;
+ return @groups;
+}
+
+sub check_htaccess_files($) {
+ my ($dir) = @_;
+ my $user = $cgi->remote_user() || ' ';
+
+ while (length $dir >= length $projectroot) {
+ my $file = "$dir/.htaccess";
+ next unless -e $file;
+ open my $htf, $file or return 0;
+
+ my $ok = 0;
+ my $need_ok = 0;
+ while (<$htf>) {
+ if (/^\s*Require\s+user\s+(\S.*\S)\s*$/i) {
+ $ok++ if grep { $_ eq $user; } split (' ', $1);
+ $need_ok++;
+ } elsif (/^\s*Require\s+group\s+(\S.*\S)\s*$/i) {
+ $ok++ if grep { $cur_auth_groups{$_}; } split(' ', $1);
+ $need_ok++;
+ } elsif (/^\s*Deny\s+from\s+all\s*$/ix) {
+ $need_ok++;
+ }
+ }
+ close $htf;
+
+ return $ok if $need_ok;
+ last;
+ } continue {
+ $dir =~ s/\/[^\/]*$// or last;
+ }
+
+ return 1;
+}
+
sub check_export_ok {
my ($dir) = @_;
return (check_head_link($dir) &&
- (!$export_ok || -e "$dir/$export_ok"));
+ (!$export_ok || -e "$dir/$export_ok") &&
+ (!$check_htaccess || check_htaccess_files($dir)));
}
# process alternate names for backward compatibility
@@ -626,6 +686,9 @@ if (defined $action) {
}
}
+# compute authenticated groups
+$cur_auth_groups{$_}++ for find_current_groups($auth_group_file, $cgi->remote_user());
+
# parameters which are pathnames
our $project = $input_params{'project'};
if (defined $project) {
@@ -853,8 +916,7 @@ sub validate_project {
my $input = shift || return undef;
if (!validate_pathname($input) ||
!(-d "$projectroot/$input") ||
- !check_head_link("$projectroot/$input") ||
- ($export_ok && !(-e "$projectroot/$input/$export_ok")) ||
+ !check_export_ok("$projectroot/$input") ||
($strict_export && !project_in_list($input))) {
return undef;
} else {
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* Re: [PATCH] Avoid using non-portable `echo -n` in tests.
From: Mike Ralphson @ 2008-11-03 16:30 UTC (permalink / raw)
To: Jeff King; +Cc: Brian Gernhardt, Git List, Shawn O Pearce
In-Reply-To: <20081031182456.GC3230@sigill.intra.peff.net>
2008/10/31 Jeff King <peff@peff.net>:
> On Fri, Oct 31, 2008 at 01:09:13AM -0400, Brian Gernhardt wrote:
>
>> Not all /bin/sh have a builtin echo that recognizes -n. Using printf
>> is far more portable.
>>
>> Discovered on OS X 10.5.5 in t4030-diff-textconv.sh and changed in all
>> the test scripts.
>
> Hmph. I think this is a good patch, and there is precedent in the past
> (20fa04ea, 2aad957, 9754563). But I am surprised this was not caught by
> our recent autobuilding project.
>
> However, it seems to work on FreeBSD (which makes it doubly weird that
> it is broken on OS X). On Solaris, the /bin/sh is so horribly broken
> that I have to use bash anyway. Commit 9754563 claims breakage on AIX,
> but it looks like Mike is doing the AIX builds with bash.
I've just retested with AIX's standard sh (ksh) instead of bash and
there were only two issues.
Oddly enough, one was with the (original) printfs in
t4030-diff-textconv.sh. AIX seems to ship with a perfectly good
printf, but if you install the GNU tools from the 'IBM toolbox for
AIX' (and prepend them to your PATH) it replaces that printf with one
which doesn't grok the "\\1\\n" syntax, but I think wants it to be
"\\01\\n".
The other problem is the 'trap exit' one discussed here:
http://thread.gmane.org/gmane.comp.version-control.git/92748/focus=92944
Mike
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-11-03 16:20 UTC (permalink / raw)
To: David Brown; +Cc: Scott Chacon, Nicolas Pitre, Pierre Habouzit, david, git
In-Reply-To: <20081102050917.GA26634@linode.davidb.org>
David Brown <git@davidb.org> wrote:
> On Sat, Nov 01, 2008 at 06:07:04PM -0700, Scott Chacon wrote:
>
>> Think about trying to incorporate this into something proprietary,
>> Shawn - how much of a pain is it going to be to get that license
>> reviewed in Google? However, LGPL I'm sure there is already a
>> reviewed policy. Now, since that may be a pain, time that Shawn could
>> have been spending being paid to work on the library is lost because
>> they can't use it, or it takes weeks/months to review it. That's my
>> concern.
>
> The gcc exception license should have been reviewed by anyone who has
> ever build anything proprietary out of gcc.
Indeed. And gcc is a *very* popular compiler on Linux distributions.
A lot of commerical software is built under it, and distributed in
binary-only form. Those companies have already done the legal review
they felt necessary before shipping (and selling) that software.
--
Shawn.
^ permalink raw reply
* Re: error: packfile while git fsck
From: Nicolas Ferre @ 2008-11-03 16:18 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0810221323270.26244@xanadu.home>
Nicolas Pitre :
> On Wed, 22 Oct 2008, Nicolas Ferre wrote:
>
>> Nicolas Pitre :
>>> On Wed, 22 Oct 2008, Nicolas Ferre wrote:
>>>
>>>> Hi all,
>>>> (please cc me on response)
>>>>
>>>> I am facing error during git status & git fsck on my tree.
>>>> This tree is cloned from various linux kernel trees.
>>>>
>>>> Here are a sample of the error I see :
>>>>
>>>> $ git fsck
>>>> error: packfile
>>>> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does
>>>> not
>>>> match index
>>>> error: packfile
>>>> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack
>>>> cannot be
>>>> accessed
>>> [...]
>>>
>>> What git version?
>> $ git --version
>> git version 1.5.3.7
>
> OK. Since this is not bleeding edge, it is pretty unlikely that the
> corruption is due to git itself. Furthermore, the git packs are always
> read only once they've been created, meaning that if they weren't
> corrupted at some point then something outside of git caused the
> corruption. You really should consider the possible causes for that
> (dying disk, pilot error, etc).
>
> As to recovery... That really depends if you have personal work
> committed to your repository. If not then the easiest solution is
> simply to recreate it by refetching from upstream. If you have
> personal work in there then you could try to fetch your work branch into
> the newly created repository. The latest git version could help with
> the extraction of non-corrupted objects out of a bad pack, but if the
> objects you are interested in are themselves corrupted then your only
> hope is to have a copy of those objects somewhere else.
Nicolas,
Thanks for your help. I will consider migrating to a brand new git tree
with my work imported in (it seems that my local work is not affected).
Just to know, as the object I try to access is not present, is there a
way to rebuild the index to match this mater of fact ?
Regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 3/3] pack-objects: honor '.keep' files
From: Shawn O. Pearce @ 2008-11-03 16:17 UTC (permalink / raw)
To: drafnel; +Cc: git, gitster, nico
In-Reply-To: <4002818.1225643406819.JavaMail.teamon@b303.teamon.com>
drafnel@gmail.com wrote:
> From: Brandon Casey <drafnel@gmail.com>
>
> By default, pack-objects creates a pack file with every object specified by
> the user. There are two options which can be used to exclude objects which
> are accessible by the repository.
>
> 1) --incremental
> This excludes any object which already exists in an accessible pack.
>
> 2) --local
> This excludes any object which exists in a non-local pack.
>
> With this patch, both arguments also cause objects which exist in packs
> marked with a .keep file to be excluded. Only the --local option requires
> an explicit check for the .keep file. If the user doesn't want the objects
> in a pack marked with .keep to be exclude, then the .keep file should be
> removed.
>
> Additionally, this fixes the repack bug which allowed porcelain repack to
> create packs which contained objects already contained in existing packs
> marked with a .keep file.
This looks sane to me, but I'm holding off on the ack because
I don't like the way the flags are managed in struct packed_git.
(See my reply to 1/3 in the series.)
> Signed-off-by: Brandon Casey <drafnel@gmail.com>
> ---
>
>
> This seems to be the correct fix.
>
> I thought about two alternatives:
>
> 1) New option to pack-objects which causes it to honor .keep files
>
> I didn't think this was necessary since that is why we have .keep
> files in the first place.
>
> So, now there are three variants:
>
> Neither --incremental or --local is used)
> Ignore repo packs, pack is created using all objects specified by
> user.
> --incremental is used)
> Look at repo packs, exclude already packed objects (including those
> marked with .keep file)
> --local is used)
> Look at repo packs, exclude objects in non-local packs (including local
> objects marked with .keep file)
>
> 2) Always honor .keep files, even when --incremental or --local is
> not specified.
>
> I think this may be counter-intuitive, since if you specify all of
> the objects explicitly, without using any other options, you expect
> all of those objects to be placed into the created pack file. If
> .keep is always honored, then a new option would be required to
> indicate ignoring .keep files, or we would adopt the platform that
> "the user must just remove the .keep file".
>
>
> So, honoring .keep files only with --incremental (which is a side effect) or
> --local seems to be the most appropriate.
>
> Comments welcome.
>
> -brandon
>
>
> builtin-pack-objects.c | 2 +-
> t/t7700-repack.sh | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index 6a8b9bf..5199e54 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -701,7 +701,7 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
> break;
> if (incremental)
> return 0;
> - if (local && !ispacklocal(p))
> + if (local && (!ispacklocal(p) || haspackkeep(p)))
> return 0;
> }
> }
> diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
> index 1489e68..b6b02da 100755
> --- a/t/t7700-repack.sh
> +++ b/t/t7700-repack.sh
> @@ -4,7 +4,7 @@ test_description='git repack works correctly'
>
> . ./test-lib.sh
>
> -test_expect_failure 'objects in packs marked .keep are not repacked' '
> +test_expect_success 'objects in packs marked .keep are not repacked' '
> echo content1 > file1 &&
> echo content2 > file2 &&
> git add . &&
> --
> 1.6.0.2.588.g3102
>
> --
> 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
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/3] packed_git: convert pack_local flag into generic bit mask
From: Shawn O. Pearce @ 2008-11-03 16:12 UTC (permalink / raw)
To: drafnel; +Cc: git, gitster, nico
In-Reply-To: <6141358.1225643400587.JavaMail.teamon@b303.teamon.com>
drafnel@gmail.com wrote:
> This is in preparation for adding a flag indicating whether a .keep file is
> present.
Good idea.
> diff --git a/cache.h b/cache.h
> index b0edbf9..0cb9350 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -679,12 +679,15 @@ extern struct packed_git {
> int index_version;
> time_t mtime;
> int pack_fd;
> - int pack_local;
> + unsigned int flags;
Hmm, isn't this a smaller change to make?
- int pack_local;
+ unsigned pack_local:1;
Then later you can do:
- unsigned pack_local:1;
+ unsigned pack_local:1,
+ pack_keep:1;
and the compiler handles all the bitmask stuff for you?
In general in git.git we like to use the struct bitmask stuff when
possible as the code is easier to follow. We only use explicit
mask constants and mask operations when the data is being stored
on disk or written over the network and we need to ensure it is
consistent across compilers. But for in-core only stuff, struct
bitmasks are easier.
--
Shawn.
^ 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