* [ANNOUNCE] GIT 1.0.0
From: Junio C Hamano @ 2005-12-21 8:00 UTC (permalink / raw)
To: git, linux-kernel
GIT 1.0.0 is found at the usual places:
Tarball http://www.kernel.org/pub/software/scm/git/
RPM http://www.kernel.org/pub/software/scm/git/RPMS/
Debian http://www.kernel.org/pub/software/scm/git/debian/
GIT git://git.kernel.org/pub/scm/git/git.git/
The name "1.0.0" ought to mean a significant milestone, but
actually it is not. Pre 1.0 version has been in production use
by the kernel folks for quite some time, and the changes since
1.0rc are pretty small and primarily consist of documenation
updates, clone/fetch enhancements and miscellaneous bugfixes.
Thank you all who gave patches, comments and time.
Happy hacking, and a little early ho-ho-ho.
^ permalink raw reply
* Re: Pushing git patches to a subversion project
From: Junio C Hamano @ 2005-12-21 7:25 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List, Matthias Urlichs, Kalle Valo
In-Reply-To: <46a038f90512202137w772a3fe9p8e9e68345e39654a@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> I am starting to work an svn-based upstream. In order to make life
> easy for me and for them I am trying to figure out a way for them to
> be able to merge my (emailed) patches atomically and preserving my
> comments.
>
> Something like git-am for svn.
Many building blocks git-am uses should be usable for this.
* git-mailsplit you already know about due to earlier "non UNIX
mbox" discussion.
* git-mailinfo can be used to parse out commit message, title
and authorship information, and actual patch.
* git-apply without --index option can be used to apply patch
to the working tree, but normal "patch -p1" would do the same
unless it is a git renaming patch. git-apply would also be
useful for its --summary option to find out mode changes
(if it is a git patch) and file creation and deletion.
So probably you could script something like this:
$ git mailinfo .msg .patch <e-mail-file >.info
$ (sed -ne 's/^Subject: //p' .info ; echo ; cat .msg) >.final-msg
$ git apply --summary <.patch |
while read cd mo de file
do
case "$cd" in
create)
svn add "$file" ;;
delete)
svn rm "$file" ;;
esac
done
$ svn commit -F .final-msg
^ permalink raw reply
* Re: [PATCH] gqit: enable compiler warnings
From: Marco Costalba @ 2005-12-21 7:11 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Marco Costalba, git
In-Reply-To: <1135131068.1183.6.camel@dv>
Pavel Roskin wrote:
> The "-O2" flag should be separated from the threading support. Besides,
> it belongs to CCFLAGS (compile flags common to C and C++), not to
> CPPFLAGS (preprocessor flags). While at that, enable all warnings by
> -Wall, except those about non-virtual destructors, which are "inherited"
> from Qt. Portability is not affected since -O2 was already
> gcc-specific.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
>
Thanks applied.
___________________________________
Yahoo! Messenger: chiamate gratuite in tutto il mondo
http://it.messenger.yahoo.com
^ permalink raw reply
* Pushing git patches to a subversion project
From: Martin Langhoff @ 2005-12-21 5:37 UTC (permalink / raw)
To: Git Mailing List, Matthias Urlichs, Kalle Valo
I am starting to work an svn-based upstream. In order to make life
easy for me and for them I am trying to figure out a way for them to
be able to merge my (emailed) patches atomically and preserving my
comments.
Something like git-am for svn.
Ideally, it should keep the patch as free of corruption as possible,
as the results will be echoed back into my branches via git-svnimport
and later "cg-update upstream" and I want git-cherry to have a fair go
at matching them.
There doesn't seem to be much. SVN-based projects ask for unified
diffs mostly, and I can't find indication of patch trading that
includes commit messages.
Any hints?
cheers,
martin
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Martin Langhoff @ 2005-12-21 5:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmmvc9l1.fsf@assigned-by-dhcp.cox.net>
On 12/21/05, Junio C Hamano <junkio@cox.net> wrote:
> Martin Langhoff <martin.langhoff@gmail.com> writes:
>
> > Could git-shell also be used by a SourceForge-like project, offering
> > per-developer git repositories? If they are using the (BSDish?)
> > convention of not having a group per user this could backfire.
>
> Fair enough. And I realize that the initial umask should be
> configurable by the administrator who prepares ssh accounts
> somehow (I do not know exactly how though).
Something like rssh, which supports rsync, cvs and sftp (and should
support git!), can set the umask based on a config. I think
/etc/bashrc would work too. In Eduforge, I think we have /etc/skel
with a group-friendly umask.
cheers,
martin
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Junio C Hamano @ 2005-12-21 5:17 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90512202115o652d8e00v86182302513d1319@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Could git-shell also be used by a SourceForge-like project, offering
> per-developer git repositories? If they are using the (BSDish?)
> convention of not having a group per user this could backfire.
Fair enough. And I realize that the initial umask should be
configurable by the administrator who prepares ssh accounts
somehow (I do not know exactly how though).
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Martin Langhoff @ 2005-12-21 5:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacevdoti.fsf@assigned-by-dhcp.cox.net>
On 12/21/05, Junio C Hamano <junkio@cox.net> wrote:
> [PATCH] Force group writable umask in git-shell
>
> Usually I do not like hardcoded policy in programs, but use of
> git-shell is already a policy decision by the repository
> administrator to use the shared repository style of development,
> and I cannot think of a reason to forbid group (and self, but
> that is obvious) writability in such use scenario.
Could git-shell also be used by a SourceForge-like project, offering
per-developer git repositories? If they are using the (BSDish?)
convention of not having a group per user this could backfire.
Does any unix these days _not_ use a group per user?
cheers,
martin
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Martin Langhoff @ 2005-12-21 5:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr787dp9r.fsf@assigned-by-dhcp.cox.net>
On 12/21/05, Junio C Hamano <junkio@cox.net> wrote:
> Martin Langhoff <martin.langhoff@gmail.com> writes:
>
> > I think I owe you an apology and a couple of beers...
>
> Nah, you do not owe me anything. Does something like this look
> good?
Yup, makes sense to me. I often explain it as "same file permissions
and access model as you'd use with CVS".
cheers,
martin
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Junio C Hamano @ 2005-12-21 5:03 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90512201828w618a64dexc22a64b8b6bc2b70@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
>> If so, do your developers use git-shell?
>
> no...
While we established that your problem did not have anything to
do with git-shell, I am tempted to do something like this.
Thoughts?
-- >8 --
[PATCH] Force group writable umask in git-shell
Usually I do not like hardcoded policy in programs, but use of
git-shell is already a policy decision by the repository
administrator to use the shared repository style of development,
and I cannot think of a reason to forbid group (and self, but
that is obvious) writability in such use scenario.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/shell.c b/shell.c
index cd31618..40a2a97 100644
--- a/shell.c
+++ b/shell.c
@@ -52,6 +52,10 @@ int main(int argc, char **argv)
default:
continue;
}
+ /* Make sure myself and my group members can write
+ * into what I create.
+ */
+ umask(umask(0) & ~0770);
exit(cmd->exec(cmd->name, arg));
}
die("unrecognized command '%s'", prog);
^ permalink raw reply related
* Re: git /objects directory created 755 by default?
From: Junio C Hamano @ 2005-12-21 4:53 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90512201828w618a64dexc22a64b8b6bc2b70@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> I think I owe you an apology and a couple of beers...
Nah, you do not owe me anything. Does something like this look
good?
-- >8 --
[PATCH] A shared repository should be writable by members.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 1683f0b..1b85cab 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -1625,7 +1625,9 @@ cooperation you are probably more famili
For this, set up a public repository on a machine that is
reachable via SSH by people with "commit privileges". Put the
committers in the same user group and make the repository
-writable by that group.
+writable by that group. Make sure their umasks are set up to
+allow group members to write into directories other members
+have created.
You, as an individual committer, then:
^ permalink raw reply related
* Random notes about qgit
From: Pavel Roskin @ 2005-12-21 2:48 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
Hello, Marco!
Here's some assorted notes about current qgit.
Thanks for making the range dialog optional, but now I don't see any way
to see the local changes unless I re-enable the dialog. I think it
should be an action activated from the menu - "diff local files to this
revision". Or maybe the "local" radio button in the diff pane.
Current qgit seems to have another crash, also annotation related. Run
qgit on its own repository. Select "Add range select dialog options",
then double click on src/commitimpl.cpp in the file list. Sometimes it
works, sometimes it crashes like this:
ASSERT getFileAnnotation: no revision
9771bea705024b3d0a59e1b9144adf5d77ca82d1
Sometimes you need to select other revisions and double click on other
files. Another assert I got was:
ASSERT getFileAnnotation: no revision
bbf2abcbcafc2e458343034c8f249ac4956ec4fb
"git-cat-file commit" works fine on both revisions. Just in case, I'm
seeing this on x86_64.
"View->Revision Diff" and "View->Archive Tree" work differently. The
former doesn't allow to turn the pane off. I'd like it to work like
"View->Archive Tree". Neither can "Revision Diff" be closed from the
popup menu.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Martin Langhoff @ 2005-12-21 2:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkyffcxp.fsf@assigned-by-dhcp.cox.net>
On 12/21/05, Junio C Hamano <junkio@cox.net> wrote:
> Martin, is this happening when your developers push into the
> shared repo?
yes...
> If so, do your developers use git-shell?
no...
> Do their
> umask set properly even when they come over ssh and gets into
> noninteractive shell?
Oh DUH. PEBKAK. .bash_profile != .bashrc
I think I owe you an apology and a couple of beers -- I'm an idiot. No
wonder I feel "at home" with "git"...
cheers,
martin
^ permalink raw reply
* Make "git-send-pack" less verbose by default
From: Linus Torvalds @ 2005-12-21 2:13 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
It used to make sense to have git-send-pack talk about the things it sent
when (a) it was a new program and (b) nobody had a lot of tags and
branches.
These days, it's just distracting to see tons of
'refs/tags/xyz': up-to-date
...
when updating a remote repo.
So shut it up by default, and add a "--verbose" flag for those who really
want to see it.
Also, since this makes he case of everything being up-to-date just totally
silent, make it say "Everything up-to-date" if no refs needed updating.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/send-pack.c b/send-pack.c
index 6ce0d9f..a41bbe5 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -8,6 +8,7 @@ static const char send_pack_usage[] =
"git-send-pack [--all] [--exec=git-receive-pack] <remote> [<head>...]\n"
" --all and explicit <head> specification are mutually exclusive.";
static const char *exec = "git-receive-pack";
+static int verbose = 0;
static int send_all = 0;
static int force_update = 0;
@@ -206,7 +207,8 @@ static int send_pack(int in, int out, in
if (!ref->peer_ref)
continue;
if (!memcmp(ref->old_sha1, ref->peer_ref->new_sha1, 20)) {
- fprintf(stderr, "'%s': up-to-date\n", ref->name);
+ if (verbose)
+ fprintf(stderr, "'%s': up-to-date\n", ref->name);
continue;
}
@@ -270,6 +272,8 @@ static int send_pack(int in, int out, in
packet_flush(out);
if (new_refs)
pack_objects(out, remote_refs);
+ else
+ fprintf(stderr, "Everything up-to-date\n");
close(out);
return ret;
}
@@ -301,6 +305,10 @@ int main(int argc, char **argv)
force_update = 1;
continue;
}
+ if (!strcmp(arg, "--verbose")) {
+ verbose = 1;
+ continue;
+ }
usage(send_pack_usage);
}
if (!dest) {
^ permalink raw reply related
* [PATCH] gqit: enable compiler warnings
From: Pavel Roskin @ 2005-12-21 2:11 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
The "-O2" flag should be separated from the threading support. Besides,
it belongs to CCFLAGS (compile flags common to C and C++), not to
CPPFLAGS (preprocessor flags). While at that, enable all warnings by
-Wall, except those about non-virtual destructors, which are "inherited"
from Qt. Portability is not affected since -O2 was already
gcc-specific.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/SConstruct b/SConstruct
index 55fd206..b0b5d0f 100644
--- a/SConstruct
+++ b/SConstruct
@@ -27,8 +27,10 @@ env['ENV']['HOME'] = os.environ['HOME']
installDir = env['HOME']+'/bin'
+env.Append( CCFLAGS = ['-O2', '-Wall' ,'-Wno-non-virtual-dtor'] )
+
## Uncomment the following if you need threading support threading
-env.Append( CPPFLAGS = ['-O2', '-DQT_THREAD_SUPPORT', '-D_REENTRANT', '-I/usr/include/qt3'] )
+env.Append( CPPFLAGS = ['-DQT_THREAD_SUPPORT', '-D_REENTRANT', '-I/usr/include/qt3'] )
if os.uname()[0] == "FreeBSD":
env.Append(LINKFLAGS=["-pthread"])
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: git /objects directory created 755 by default?
From: Junio C Hamano @ 2005-12-21 1:37 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <7vacevgwqr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Martin Langhoff <martin.langhoff@gmail.com> writes:
>
>> Since git changed to creating the objects subdirectories "on demand",
>> these are created 755 regardless of the user's umask. This is quite
>> inconvenient in ("cvs style") team-shared repositories, which work
>> great otherwise.
>
> Hmph.
>
> I have 002 as umask. .git/objects or .git/objects/[0-9a-f]{2}
> directories are created 0775 for me.
Martin, is this happening when your developers push into the
shared repo? If so, do your developers use git-shell? Do their
umask set properly even when they come over ssh and gets into
noninteractive shell? What do they see when they do this?
$ ssh shared.repo.machine.example.com umask
the answer may wall be "What do you think I am, A shell?", or
0022.
The git-shell command is designed to be not git aware (it does
not know how a git repository looks like, nor does not know all
the commands it can handle right now happen to take the
repository directory as their first parameter). If we do not
mind butchering things, we could introduce:
[shell]
umask = 0002
to the configuration file, and do something like this (not even
compile tested, and I am not sure what else it breaks):
---
diff --git a/shell.c b/shell.c
index cd31618..33898f8 100644
--- a/shell.c
+++ b/shell.c
@@ -1,15 +1,34 @@
#include "cache.h"
#include "quote.h"
-static int do_generic_cmd(const char *me, char *arg)
+static int shell_umask = 0002; /* default */
+
+static int slurp_repository_umask(const char *var, const char *value)
+{
+ if (!strcmp(var, "shell.umask"))
+ shell_umask = git_config_int(value);
+ else
+ return git_default_config(var, value);
+ return 0;
+}
+
+/*
+ * These commands take arg == git repository directory.
+ */
+static int do_git_repo_cmd(const char *me, char *arg)
{
const char *my_argv[4];
if (!arg || !(arg = sq_dequote(arg)))
die("bad argument");
+ if (!enter_repo(arg, 0))
+ die("'%s': Nah -- not a git repository", arg);
+ git_config(slurp_repository_umask);
+ umask(shell_umask);
+
my_argv[0] = me;
- my_argv[1] = arg;
+ my_argv[1] = ".";
my_argv[2] = NULL;
return execvp(me, (char**) my_argv);
@@ -19,8 +38,8 @@ static struct commands {
const char *name;
int (*exec)(const char *me, char *arg);
} cmd_list[] = {
- { "git-receive-pack", do_generic_cmd },
- { "git-upload-pack", do_generic_cmd },
+ { "git-receive-pack", do_git_repo_cmd },
+ { "git-upload-pack", do_git_repo_cmd },
{ NULL },
};
^ permalink raw reply related
* Re: git /objects directory created 755 by default?
From: Junio C Hamano @ 2005-12-20 23:43 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90512201525k5eb7cf62u65de2cd51424df37@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Since git changed to creating the objects subdirectories "on demand",
> these are created 755 regardless of the user's umask. This is quite
> inconvenient in ("cvs style") team-shared repositories, which work
> great otherwise.
Hmph.
I have 002 as umask. .git/objects or .git/objects/[0-9a-f]{2}
directories are created 0775 for me.
Do we have hardcoded 0755 that we need to change to 0777
somewhere? sha1_file.c::safe_create_leading_directories() is
the primary code that creates directories lazily, and we mkdir
with 0777 there.
^ permalink raw reply
* git /objects directory created 755 by default?
From: Martin Langhoff @ 2005-12-20 23:25 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
Junio,
Since git changed to creating the objects subdirectories "on demand",
these are created 755 regardless of the user's umask. This is quite
inconvenient in ("cvs style") team-shared repositories, which work
great otherwise.
Didn't find any relevant discussion in the archives... I am not sure
if this is by design. In any case it is something we could work around
with a post-update hook on the server side (and I'd be happy to
document).
cheers,
martin
^ permalink raw reply
* Re: [PATCH] git-pack-redundant: speed and memory usage improvements
From: Lukas Sandström @ 2005-12-20 21:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7virtjh479.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Lukas Sandström <lukass@etek.chalmers.se> writes:
>
>
>>This might be post-1.0 material, but I have tested it on a couple of
>>different repositories and it appears to work as before, only faster
>>and using less memory.
>
>
> Thanks.
>
> I had an impression that somehow we already had this slabbish
> allocation but apparently we didn't.
>
> Any particular area you have worries/uncertainty about, that
> makes you mark this post-1.0?
>
No, as far as I can see, there should be no problems with the patch.
It is non-trivial though so, according to history, there might be
bugs that only show on certain repositories.
/Lukas
^ permalink raw reply
* Re: [PATCH] git-pack-redundant: speed and memory usage improvements
From: Junio C Hamano @ 2005-12-20 21:02 UTC (permalink / raw)
To: Lukas Sandström; +Cc: Git Mailing List
In-Reply-To: <43A86422.3090909@etek.chalmers.se>
Lukas Sandström <lukass@etek.chalmers.se> writes:
> This might be post-1.0 material, but I have tested it on a couple of
> different repositories and it appears to work as before, only faster
> and using less memory.
Thanks.
I had an impression that somehow we already had this slabbish
allocation but apparently we didn't.
Any particular area you have worries/uncertainty about, that
makes you mark this post-1.0?
^ permalink raw reply
* [PATCH] git-pack-redundant: speed and memory usage improvements
From: Lukas Sandström @ 2005-12-20 20:05 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Lukas Sandström
Slab allocation of llist entries gives some speed improvements.
Not computing the pack_list permutaions all at once reduces memory
usage greatly on repositories with many packs.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
This might be post-1.0 material, but I have tested it on a couple of
different repositories and it appears to work as before, only faster
and using less memory.
pack-redundant.c | 147 +++++++++++++++++++++++++-----------------------------
1 files changed, 68 insertions(+), 79 deletions(-)
e21c29b79531a98d52dcaf647968cde8e9a462d9
diff --git a/pack-redundant.c b/pack-redundant.c
index 0a43278..1869b38 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -8,6 +8,8 @@
#include "cache.h"
+#define BLKSIZE 512
+
static const char pack_redundant_usage[] =
"git-pack-redundant [ --verbose ] [ --alt-odb ] < --all | <.pack filename> ...>";
@@ -33,29 +35,32 @@ static struct pack_list {
struct pll {
struct pll *next;
struct pack_list *pl;
- size_t pl_size;
};
static struct llist_item *free_nodes = NULL;
+static inline void llist_item_put(struct llist_item *item)
+{
+ item->next = free_nodes;
+ free_nodes = item;
+}
+
static inline struct llist_item *llist_item_get()
{
struct llist_item *new;
if ( free_nodes ) {
new = free_nodes;
free_nodes = free_nodes->next;
- } else
- new = xmalloc(sizeof(struct llist_item));
-
+ } else {
+ int i = 1;
+ new = xmalloc(sizeof(struct llist_item) * BLKSIZE);
+ for(;i < BLKSIZE; i++) {
+ llist_item_put(&new[i]);
+ }
+ }
return new;
}
-static inline void llist_item_put(struct llist_item *item)
-{
- item->next = free_nodes;
- free_nodes = item;
-}
-
static void llist_free(struct llist *list)
{
while((list->back = list->front)) {
@@ -270,77 +275,58 @@ static void cmp_two_packs(struct pack_li
}
}
-static void pll_insert(struct pll **pll, struct pll **hint_table)
+void pll_free(struct pll *l)
{
- struct pll *prev;
- int i = (*pll)->pl_size - 1;
+ struct pll *old;
+ struct pack_list *opl;
- if (hint_table[i] == NULL) {
- hint_table[i--] = *pll;
- for (; i >= 0; --i) {
- if (hint_table[i] != NULL)
- break;
+ while (l) {
+ old = l;
+ while (l->pl) {
+ opl = l->pl;
+ l->pl = opl->next;
+ free(opl);
}
- if (hint_table[i] == NULL) /* no elements in list */
- die("Why did this happen?");
+ l = l->next;
+ free(old);
}
-
- prev = hint_table[i];
- while (prev->next && prev->next->pl_size < (*pll)->pl_size)
- prev = prev->next;
-
- (*pll)->next = prev->next;
- prev->next = *pll;
}
/* all the permutations have to be free()d at the same time,
* since they refer to each other
*/
-static struct pll * get_all_permutations(struct pack_list *list)
+static struct pll * get_permutations(struct pack_list *list, int n)
{
- struct pll *subset, *pll, *new_pll = NULL; /*silence warning*/
- static struct pll **hint = NULL;
- if (hint == NULL)
- hint = xcalloc(pack_list_size(list), sizeof(struct pll *));
-
- if (list == NULL)
+ struct pll *subset, *ret = NULL, *new_pll = NULL, *pll;
+
+ if (list == NULL || pack_list_size(list) < n || n == 0)
return NULL;
- if (list->next == NULL) {
- new_pll = xmalloc(sizeof(struct pll));
- hint[0] = new_pll;
- new_pll->next = NULL;
- new_pll->pl = list;
- new_pll->pl_size = 1;
- return new_pll;
+ if (n == 1) {
+ while (list) {
+ new_pll = xmalloc(sizeof(pll));
+ new_pll->pl = NULL;
+ pack_list_insert(&new_pll->pl, list);
+ new_pll->next = ret;
+ ret = new_pll;
+ list = list->next;
+ }
+ return ret;
}
- pll = subset = get_all_permutations(list->next);
- while (pll) {
- if (pll->pl->pack == list->pack) {
- pll = pll->next;
- continue;
+ while (list->next) {
+ subset = get_permutations(list->next, n - 1);
+ while (subset) {
+ new_pll = xmalloc(sizeof(pll));
+ new_pll->pl = subset->pl;
+ pack_list_insert(&new_pll->pl, list);
+ new_pll->next = ret;
+ ret = new_pll;
+ subset = subset->next;
}
- new_pll = xmalloc(sizeof(struct pll));
-
- new_pll->pl = xmalloc(sizeof(struct pack_list));
- memcpy(new_pll->pl, list, sizeof(struct pack_list));
- new_pll->pl->next = pll->pl;
- new_pll->pl_size = pll->pl_size + 1;
-
- pll_insert(&new_pll, hint);
-
- pll = pll->next;
- }
- /* add ourself */
- new_pll = xmalloc(sizeof(struct pll));
- new_pll->pl = xmalloc(sizeof(struct pack_list));
- memcpy(new_pll->pl, list, sizeof(struct pack_list));
- new_pll->pl->next = NULL;
- new_pll->pl_size = 1;
- pll_insert(&new_pll, hint);
-
- return hint[0];
+ list = list->next;
+ }
+ return ret;
}
static int is_superset(struct pack_list *pl, struct llist *list)
@@ -428,6 +414,7 @@ static void minimize(struct pack_list **
struct pll *perm, *perm_all, *perm_ok = NULL, *new_perm;
struct llist *missing;
size_t min_perm_size = (size_t)-1, perm_size;
+ int n;
pl = local_packs;
while (pl) {
@@ -441,8 +428,7 @@ static void minimize(struct pack_list **
missing = llist_copy(all_objects);
pl = unique;
while (pl) {
- llist_sorted_difference_inplace(missing,
- pl->all_objects);
+ llist_sorted_difference_inplace(missing, pl->all_objects);
pl = pl->next;
}
@@ -453,19 +439,21 @@ static void minimize(struct pack_list **
}
/* find the permutations which contain all missing objects */
- perm_all = perm = get_all_permutations(non_unique);
- while (perm) {
- if (perm_ok && perm->pl_size > perm_ok->pl_size)
- break; /* ignore all larger permutations */
- if (is_superset(perm->pl, missing)) {
- new_perm = xmalloc(sizeof(struct pll));
- memcpy(new_perm, perm, sizeof(struct pll));
- new_perm->next = perm_ok;
- perm_ok = new_perm;
+ for (n = 1; n <= pack_list_size(non_unique) && !perm_ok; n++) {
+ perm_all = perm = get_permutations(non_unique, n);
+ while (perm) {
+ if (is_superset(perm->pl, missing)) {
+ new_perm = xmalloc(sizeof(struct pll));
+ memcpy(new_perm, perm, sizeof(struct pll));
+ new_perm->next = perm_ok;
+ perm_ok = new_perm;
+ }
+ perm = perm->next;
}
- perm = perm->next;
+ if (perm_ok)
+ break;
+ pll_free(perm_all);
}
-
if (perm_ok == NULL)
die("Internal error: No complete sets found!\n");
@@ -537,6 +525,7 @@ static void scan_alt_odb_packs(void)
alt->all_objects);
local = local->next;
}
+ llist_sorted_difference_inplace(all_objects, alt->all_objects);
alt = alt->next;
}
}
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] Racy GIT
From: Junio C Hamano @ 2005-12-20 19:28 UTC (permalink / raw)
To: git; +Cc: pasky, torvalds
In-Reply-To: <7vwti0go2w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> This fixes the longstanding "Racy GIT" problem,...
Sorry, it does not really.
> If you run the following sequence of commands:
>
> echo frotz >infocom
> git update-index --add infocom
> echo xyzzy >infocom
The patch deals with the above sequence correctly, but it breaks
down with:
echo frotz >infocom
git update-index --add infocom
echo xyzzy >infocom
sleep 3 ;# a little while later
echo nitfol >activision
git update-index --add activision
git diff-files infocom
We need to detect the false clean entries just before we write
out index in the second update-index and mark them out of date.
^ permalink raw reply
* Re: [PATCH] xread/xwrite: do not worry about EINTR at calling sites.
From: Linus Torvalds @ 2005-12-20 18:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <Pine.LNX.4.63.0512201136430.29711@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 20 Dec 2005, Johannes Schindelin wrote:
>
> In another project I'm working on, a user insisted that on Solaris 2.7,
> write(2) sometimes returns ENOENT when it really means "try again". I
> cannot verify, since I don't have Solaris 2.7.
That would be either a very confused user or a terminally sick Solaris
kernel. In either case, not worth fixing.
Linus
^ permalink raw reply
* [PATCH] Fix unconditional early exit in cg-fetch v2
From: Paolo 'Blaisorblade' Giarrusso @ 2005-12-20 15:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
When invoking cg-fetch, after fetching tags it exits here, for an overlooked
error handling. Replace the exit with an early return.
This means, for instance, we exit without reporting the tag updates and without
removing the "fetch in progress" marker - leading to unconditional "Recovering
from interrupted fetch" at the very beginning with rsync transport. Indeed, this
is fixed by this patch.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
cg-fetch | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/cg-fetch b/cg-fetch
index a2865ae..074aa14 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -189,9 +189,10 @@ fetch_tags()
[ -d "$_git/refs/tags" ] || mkdir -p "$_git/refs/tags"
if [ "$get" = "get_rsync" ]; then
- $get -i -s -u -d "$uri/refs/tags" "$_git/refs/tags" ||
+ if ! $get -i -s -u -d "$uri/refs/tags" "$_git/refs/tags"; then
echo "unable to get tags list (non-fatal)" >&2
- exit $?
+ return $?
+ fi
fi
git-ls-remote --tags "$uri" |
^ permalink raw reply related
* Re: [PATCH] Fix unconditional early exit in cg-fetch
From: Blaisorblade @ 2005-12-20 15:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vpsnso9g8.fsf@assigned-by-dhcp.cox.net>
On Tuesday 20 December 2005 02:15, Junio C Hamano wrote:
> Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> writes:
> > if [ "$get" = "get_rsync" ]; then
> > $get -i -s -u -d "$uri/refs/tags" "$_git/refs/tags" ||
> > - echo "unable to get tags list (non-fatal)" >&2
> > - exit $?
> > + (echo "unable to get tags list (non-fatal)" >&2;
> > + exit $?)
> > fi
> Why would you want a subshell that exits with a non-zero status
> when nobody is checking that status anyway?
Argh, I should have used a proper conditional statement... I always forget
bash is not Perl.
> I suspect removing "exit $?" would suffice, if that condition is
> non-fatal as the message says...
Likely you need to skip git-ls-remote (not sure however, but it's an
exceptional condition).
return $? would be IMHO also fine - the caller is then free to ignore the
return code.
I'm then resending the patch done the second way - feel free to merge any
version.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: [ANNOUNCE qgit-1.0rc1]
From: Marco Costalba @ 2005-12-20 12:55 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1135047865.2259.46.camel@dv>
> OK, here you go. qgit just crashed on me. I opened the patch pane, the
> tree pane and the annotate window. While the annotate window was
> focused, I tried to select multiple files in the tree pane.
Hi Pavel,
thanks for crash report, I will investigate it.
>
> Also, qgit doesn't look well with large fonts (not excessively large,
> mind you, just with Sans 12):
>
> http://red-bean.com/proski/qgit/
>
> I see sizes are hardcoded in the *.ui files. Probably there should be a
> way to make the widgets resize together with the font.
>
I will investigate what Qt designer allows abot font resizing.
> I don't want to be asked about range every time I start qgit. Can it be
> an option? In half of the cases I just want to see commits in the last
> 2-4 days. In other cases, I want to see the whole history. Tags are
> usually irrelevant.
>
I know what you mean ;-)
To avoid range select dialog simply call qgit with some command line option (arguments are feeded
to git-rev-parse, so the same options of gitk are allowed), qgit shows the dialog only if called
with no arguments.
If you don't want to type options just call qgit and press enter as soon as range select appears,
by default you will see commits from HEAD to latest tag.
If, instead, you want to see whole the history, press "Canc" to delete "to" field tag and then
press enter. That's the reason the focus is on "to" field by default ;-)
An option at startup to bybass range select could be an idea tough.
> The "Show All" checkbox in the range select dialog doesn't seem to have
> any effect. I think it should disable "top" and "bottom" comboboxes.
>
"Show All" is simply a shortcut for git-rev-parse --show-all option, to see all the branches
between selected commit range.
Tags selection is to define selected commit range
Peraphs it should be better call it "Show all branches" and add a new check "Show whole history"
Thanks for your feedback.
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ 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