* Re: q: git-fetch a tad slow?
From: Shawn O. Pearce @ 2008-07-31 4:45 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080730190657.GC26389@elte.hu>
Ingo Molnar <mingo@elte.hu> wrote:
> alas, fetching still seems to be slow:
>
> titan:~/tip> time git-fetch origin
>
> real 0m5.112s
> user 0m0.972s
> sys 0m3.380s
What version of git are dealing with on the client side?
I only have a MacBook Pro (2.4 GHz Intel Core 2 Duo) and I'm getting
fetch times of ~472 ms over git:// to your -tip.git tree and ~128
ms for strictly local fetch. If your SSH overhead is ~300 ms this
is only a ~700 ms real time for `git fetch origin`, not 5100 ms.
Is your git-fetch a shell script? Or a compiled binary? The port
into C made it go _much_ faster, even though it is still a naive
O(N^2) matching algorithm. Yea, we still should fix that, but
I think an upgrade to 1.5.4 or later would make the client side
improve consideribly.
--
Shawn.
^ permalink raw reply
* Re: git citool/gui bug
From: Shawn O. Pearce @ 2008-07-31 3:23 UTC (permalink / raw)
To: Leandro Lucarella; +Cc: git
In-Reply-To: <20080730185306.GV7616@integratech.com.ar>
Leandro Lucarella <llucarella@integratech.com.ar> wrote:
> Hi! I think I've hit a really silly bug in citool/gui:
>
> git citool shows:
>
> new file mode 100644 # black
> @@ -0,0 +1,5 @@ # blue
> + # green
> =============== # orange
> +Hello World!!!! # green
> =============== # orange
> + # green
Hmph. Don't put 7 = on a line together. Or 7 < or 7 > for that
matter. It confuses some git related tools like git-rerere,
the template pre-commit hook, and git-gui.
In this case we think these are the lines between two hunks in a
merge conflict, so we are showing them specially to you. Just in
case you staged a conflicted hunk by accident during a merge you
want it to stand out to help you notice the error.
Yes, it would be nice if git-gui knew this wasn't actually a merge
conflict but was instead proper text. Sadly it isn't that smart.
--
Shawn.
^ permalink raw reply
* [PATCH] documentation: user-manual: update "using-bisect" section
From: Christian Couder @ 2008-07-31 3:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Since version 1.5.6 "git bisect" doesn't use a "bisect" branch any
more, but the user manual had not been updated to reflect this.
So this patch does that and while at it also adds a few words about
"git bisect skip" and points user to the "git bisect" man page for
more information.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/user-manual.txt | 27 +++++++++++++++++++++------
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c5641af..50bf85f 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -479,10 +479,10 @@ Bisecting: 3537 revisions left to test after this
-------------------------------------------------
If you run "git branch" at this point, you'll see that git has
-temporarily moved you to a new branch named "bisect". This branch
-points to a commit (with commit id 65934...) that is reachable from
-"master" but not from v2.6.18. Compile and test it, and see whether
-it crashes. Assume it does crash. Then:
+temporarily moved you in "(no branch)". HEAD is now detached from any
+branch and points directly to a commit (with commit id 65934...) that
+is reachable from "master" but not from v2.6.18. Compile and test it,
+and see whether it crashes. Assume it does crash. Then:
-------------------------------------------------
$ git bisect bad
@@ -504,8 +504,7 @@ report with the commit id. Finally, run
$ git bisect reset
-------------------------------------------------
-to return you to the branch you were on before and delete the
-temporary "bisect" branch.
+to return you to the branch you were on before.
Note that the version which git-bisect checks out for you at each
point is just a suggestion, and you're free to try a different
@@ -528,6 +527,22 @@ $ git reset --hard fb47ddb2db...
then test, run "bisect good" or "bisect bad" as appropriate, and
continue.
+Instead of "git bisect visualize" and then "git reset --hard
+fb47ddb2db...", you might just want to tell git that you want to skip
+the current commit:
+
+-------------------------------------------------
+$ git bisect skip
+-------------------------------------------------
+
+In this case, though, git may not eventually be able to tell the first
+bad one between some first skipped commits and a latter bad commit.
+
+There are also ways to automate the bisecting process if you have a
+test script that can tell a good from a bad commit. See
+linkgit:git-bisect[1] for more information about this and other "git
+bisect" features.
+
[[naming-commits]]
Naming commits
--------------
--
1.6.0.rc0.42.g186458.dirty
^ permalink raw reply related
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-31 0:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Roman Zippel, Martin Langhoff, Tim Harper, Git Mailing List,
Johannes Sixt
In-Reply-To: <7vej5b3ozz.fsf@gitster.siamese.dyndns.org>
On Wed, 30 Jul 2008, Junio C Hamano wrote:
>
> I am not Roman, but so I do not know if I did what Roman wanted to, but
> here is a quick hack. "gitk --post-simplify -- kernel/printk.c" is
> slightly more readable than --full-history with this patch.
.. and if by "slightly", you mean "a lot", then yes.
Patch looks fine to me. I didn't look at the code logic very closely, but
I suspect that it's actually hard to get the right answer with broken
code, and the logic doesn't look broken. So Ack.
The filter-branch thing should probably be taught about this at least as
an option. I think it was Johannes Sixt that worried about that one. Added
to cc.
Linus
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Boyd Lynn Gerber @ 2008-07-31 0:32 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: Junio C Hamano, git
In-Reply-To: <20080731001112.GP10399@yugib.highrise.ca>
On Wed, 30 Jul 2008, Aidan Van Dyk wrote:
> * Boyd Lynn Gerber <gerberb@zenez.com> [080730 20:00]:
> > So what do you think we need to have. I really do not see the need for
> > __OPENSERVER__. Do you?
>
> No, I think I saw that long ago, when I said:
> > Sorry, a bit premature on my end...
>
> With SNPRINTF_RETURNS_BOGUS and NO_MKDTEMP and CFLAGS set for make, I
> don't need any source code changes to compile on SCO.
>
> And as long as I have GNU bash and diff available, the test suite passes
> as well. Well, all except for t9500-gitweb-standalone-no-errors.sh:
> [Thu Jul 31 00:08:46 2008] gitweb.perl: -T and -B not implemented on filehandles at /u/aidan/git/t/trash directory/../../gitweb/gitweb.perl line 2444.
>
> Perl claims:
> This is perl, v5.8.8 built for i586-pc-sysv5
>
> But again, I don't plan on running gitweb on this SCO box either...
OK, thanks, I did not want to not respond if things were needed.
Thanks,
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Junio C Hamano @ 2008-07-31 0:30 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, Julian Phillips, Scott Chacon, Petr Baudis,
git list
In-Reply-To: <B7697630-DF9C-4EF0-9D63-9E362CEE125B@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> Funnily enough, he chose to title it the "Git Community Book". Hard to
> match Scott's enthusiasm; this is the second major initiative we've
> seen from him in the last few days (the other being git-scm.com
> itself) which to the casual onlooker might look like the "official"
> Git homepage and documentation, but in both cases development occurred
> behind the scenes and the list was only notified after the fact.
I think your "Behind the scenes, after the fact" is being unnecessarily
harsh.
What counts is what happens now after the launch, when there are issues
identified that he could address on his side if he wanted to work with the
community. "Ignore and fork forever" may be to further fracture the
community, but for a book like his that has quite different aim than the
official manual set, it might be a sensible approach. You have to weigh
the pros and cons.
We've seen other comments raised to both the book and the git-scm.com site
on this list after they were announced. We'll see how they are addressed
in coming weeks. I think it is not too late to voice your negative
judgements only after seeing what happens.
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Junio C Hamano @ 2008-07-31 0:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vej5b3ozz.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The idea is to compute, for each commit in the "full history" result set,
> the commit that should replace it in the simplified history. This
> replacement commit is defined as follows:
>
> * In any case, we first figure out the replacement commits of parents of
> the commit we are looking at. The commit we are looking at is
> rewritten as if its parents are replacement commits of its original
> parents.
>
> * If the commit is marked as TREESAME (i.e. it modifies the paths we are
> interested in), then the replacement commit is itself. IOW, the commit
> is not dropped from the final result.
A typo here. This comment should have said !TREESAME (the code is correct).
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Scott Chacon @ 2008-07-31 0:13 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git list
In-Reply-To: <B7697630-DF9C-4EF0-9D63-9E362CEE125B@wincent.com>
On Wed, Jul 30, 2008 at 4:48 PM, Wincent Colaiuta <win@wincent.com> wrote:
> El 30/7/2008, a las 21:32, Junio C Hamano escribió:
>
>> That's one valid approach. I or you might have taken a different avenue,
>> but after all, it's his book, not mine, not yours, nor git list's book.
>
> Funnily enough, he chose to title it the "Git Community Book". Hard to match
> Scott's enthusiasm; this is the second major initiative we've seen from him
> in the last few days (the other being git-scm.com itself) which to the
> casual onlooker might look like the "official" Git homepage and
> documentation, but in both cases development occurred behind the scenes and
> the list was only notified after the fact. Better late than never I suppose.
Not sure what else I could have done - I announced that I was starting
a documentation project like this about a week ago on this list, then
I started the book 3 days ago
(http://github.com/schacon/gitscm/commits/book) and announced it here
for initial review yesterday. I haven't told very many people about
it yet and I haven't linked to it from git-scm.com yet either. It's
been open source from the first minute on GitHub, and the link to the
source was on the website I posted here.
Same for the git-scm site - I started it on the 23rd and emailed Pasky
about it the next day, and the day after that he began submitting
patches to me for it and I announced it on this list. Am I missing
something here? Do you think I've been working on these secretly for
months, or something? If there is a better communication workflow, I
would be happy to do so.
I appreciate that you notice my enthusiasm, though. :)
Scott
>> We originally hoped (well, at least I did) that Scott's effort on his book
>> might help us in improving the User Manual as well, but the approach seems
>> to make it unlikely. But that is nothing to hold against him --- he is
>> doing his own thing in a way he feels is the best, and that's perfectly
>> fine. We lost nothing, perhaps except for a chance to cooperate a bit
>> better and to widen the community.
>
> Even though there might not be an automated way to get changes back from the
> fork, if there are clear improvements made then there is at least no legal
> obstacle to incorporating them back in, the only obstacle would be time and
> willingness to do so manually.
>
>>
> Cheers,
> Wincent
>
>
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Aidan Van Dyk @ 2008-07-31 0:11 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.10.0807301747160.13032@xenau.zenez.com>
[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]
* Boyd Lynn Gerber <gerberb@zenez.com> [080730 20:00]:
> So what do you think we need to have. I really do not see the need for
> __OPENSERVER__. Do you?
No, I think I saw that long ago, when I said:
> Sorry, a bit premature on my end...
With SNPRINTF_RETURNS_BOGUS and NO_MKDTEMP and CFLAGS set for make, I
don't need any source code changes to compile on SCO.
And as long as I have GNU bash and diff available, the test suite passes
as well. Well, all except for t9500-gitweb-standalone-no-errors.sh:
[Thu Jul 31 00:08:46 2008] gitweb.perl: -T and -B not implemented on filehandles at /u/aidan/git/t/trash directory/../../gitweb/gitweb.perl line 2444.
Perl claims:
This is perl, v5.8.8 built for i586-pc-sysv5
But again, I don't plan on running gitweb on this SCO box either...
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git help broken
From: Miklos Vajna @ 2008-07-31 0:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kevin Ballard, Git Mailing List
In-Reply-To: <alpine.LSU.1.00.0807310144040.3486@wbgn129.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
On Thu, Jul 31, 2008 at 01:44:36AM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > And from the patch, it is pretty obvious that it does not come close to
> > the "man" code path.
>
> Oh, so it was involved?
Yes. The command list is no longer loaded automatically and the default
for non-git commands on git help foo was 'gitfoo', I guess for
gittutorial and such manpages.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Boyd Lynn Gerber @ 2008-07-31 0:00 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: Junio C Hamano, git
In-Reply-To: <20080730234455.GN10399@yugib.highrise.ca>
On Wed, 30 Jul 2008, Aidan Van Dyk wrote:
> * Boyd Lynn Gerber <gerberb@zenez.com> [080730 19:30]:
> > I have m4-1.4.3 at
> >
> > ftp://ftp.zenez.com/pub/zenez/prgms/m4-1.4.3-osr6-all.tar.gz
> >
> > I really have to be able to use configure for most of my OpenSource
> > Projects for SCO OS's.
> >
> > I made the changes so that most things work with the auto tools.
>
> I'm not a SCO guru by any means...
>
> I'm just a user on someone else's SCO machine, just trying to make sure
> that the software I write is "fairly portable"...
>
> I'm willing to carry a good and useful tool (like git) in my home
> directory in that endeavour, but I'm not carrying all of the GNU stack
> in my home directory so I can run configure git is a bit much ;-)
That make sense. All though m4 is
test5 > l /usr/local/bin/m4
-rwxr-xr-x 1 gerberb zenez 280524 Jul 23 2005 /usr/local/bin/m4
Which is not that big. I have it in my ~/.bin/ on my clients machines.
You really need a good m4 for most things. Sendmail expecially. Also for
the latest bind with the DNS security fix. I some times need bc as well.
test5 > l /usr/local/bin/bc
-rwxr-xr-x 1 bin bin 85088 May 19 17:20 /usr/local/bin/bc
> > I did a VM install of OpenServer 6 to try things out. I was able to get
> > your -Wall failure, but once I ran the CC=cc CXX=CC ./configure I was able
> > to run gmake without any errors. I did have to install the M4 from above
> > to get configure to work. So, the straight out of the box install has to
> > have gnu m4 to run configure.
>
> So configure.ac must have some magic in it that allows configure to
> notice -Wall doesn't work. You can see what it choose in
> config.mak.autogen I think. But I'm pretty glad for the kbuild style
> Makefile in git not requiring autoconf/automake/etc.
I do not see anything really obvious, but below is config.mak.autogen
test5 > cat config.mak.autogen
# git Makefile configuration, included in main Makefile
# config.mak.autogen. Generated from config.mak.in:config.mak.append by
configure.
CC = cc
CFLAGS = -Kalloca -Kthread
AR = gar
TAR = gtar
#INSTALL = @INSTALL@ # needs install-sh or install.sh in
sources
TCLTK_PATH = wish
prefix = /usr/local
exec_prefix = ${prefix}
bindir = ${exec_prefix}/bin
#gitexecdir = ${exec_prefix}/libexec/git-core/
datarootdir = @datarootdir@
template_dir = ${prefix}/share/git-core/templates/
mandir=${prefix}/man
srcdir = .
export exec_prefix mandir
export srcdir VPATH
ASCIIDOC8=
NEEDS_SSL_WITH_CRYPTO=
NO_OPENSSL=
NO_CURL=
NO_EXPAT=
NEEDS_LIBICONV=
NEEDS_SOCKET=YesPlease
NO_SYS_SELECT_H=
NO_D_INO_IN_DIRENT=
NO_D_TYPE_IN_DIRENT=YesPlease
NO_SOCKADDR_STORAGE=
NO_IPV6=
NO_C99_FORMAT=
NO_STRCASESTR=YesPlease
NO_MEMMEM=YesPlease
NO_STRLCPY=
NO_STRTOUMAX=
NO_SETENV=
NO_UNSETENV=
NO_MKDTEMP=YesPlease
NO_ICONV=
OLD_ICONV=
NO_DEFLATE_BOUND=
FREAD_READS_DIRECTORIES=UnfortunatelyYes
SNPRINTF_RETURNS_BOGUS=UnfortunatelyYes
# config.mak.append. Generated by configure.
> > -g and -O2 are mutually exclusive. You can have either one but not both.
>
> Yes, and I think the default to cc matches -g, not -O2, hence my
> failures unless setting -O2.
>
> > I do have tcl and tk
>
> I'm sure... I might even find it burried somewhere on this machine too,
> but I have no real need for it.
OK.
So what do you think we need to have. I really do not see the need for
__OPENSERVER__. Do you?
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Junio C Hamano @ 2008-07-30 23:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807291738280.3334@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But the reverse isn't true: the current primary formats cannot be
> generated from your preferred format without losing something important
> (performance).
>
> But I'll make you a deal: if you actually write the filter in C form, I
> can pretty much guarantee that we can easily add it as a new flag. It
> really should be pretty easy to integrate it into the revision parsing
> machinery alongside --topo-order, since it's really the same kind of
> operation.
I am not Roman, but so I do not know if I did what Roman wanted to, but
here is a quick hack. "gitk --post-simplify -- kernel/printk.c" is
slightly more readable than --full-history with this patch.
-- >8 --
Subject: [PATCH] revision traversal: teach --post-simplify
The --full-history traversal keeps all merges and non-merge commits that
touch paths in the given pathspec. This is useful to view both sides of a
merge in a topology like this:
A---M---o
/ /
---O---B
when A and B makes identical change to the given paths. The revision
traversal without --full-history aims to come up with a simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.
The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in. --full-history reduces the
topology to:
---O---M---o
in such a case, without removing M.
This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.
The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history. This
replacement commit is defined as follows:
* In any case, we first figure out the replacement commits of parents of
the commit we are looking at. The commit we are looking at is
rewritten as if its parents are replacement commits of its original
parents.
* If the commit is marked as TREESAME (i.e. it modifies the paths we are
interested in), then the replacement commit is itself. IOW, the commit
is not dropped from the final result.
* Otherwise, we examine the parents of the commit.
- If they replace to the same commit, because the commit we are looking
at itself does not touch the interesting paths, we replace the commit
we are looking at with the replacement commit of its parents.
- If some of the parents replace to one commit, and some other parents
replace to another different commit, the commit we are looking at
needs to stay as a merge in the final result.
The algorithm outlined above alone does not quite work; the reason is
because "all parents are replaced by the same commit" rule is too strict.
It needs to be relaxed to remove parents that are ancestor of some other
parents, and that is why post_simplify_one() calls a rather expensive
reduce_heads().
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++++----------
revision.h | 1 +
2 files changed, 106 insertions(+), 20 deletions(-)
diff --git a/revision.c b/revision.c
index 3897fec..a843c42 100644
--- a/revision.c
+++ b/revision.c
@@ -1045,6 +1045,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
} else if (!strcmp(arg, "--topo-order")) {
revs->lifo = 1;
revs->topo_order = 1;
+ } else if (!strcmp(arg, "--post-simplify")) {
+ revs->post_simplify = 1;
+ revs->topo_order = 1;
+ revs->simplify_history = 0;
} else if (!strcmp(arg, "--date-order")) {
revs->lifo = 0;
revs->topo_order = 1;
@@ -1378,6 +1382,105 @@ static void add_child(struct rev_info *revs, struct commit *parent, struct commi
l->next = add_decoration(&revs->children, &parent->object, l);
}
+static int remove_duplicate_parents(struct commit *commit)
+{
+ struct commit_list **pp, *p;
+ int surviving_parents;
+
+ /* Examine existing parents while marking ones we have seen... */
+ pp = &commit->parents;
+ while ((p = *pp) != NULL) {
+ struct commit *parent = p->item;
+ if (parent->object.flags & TMP_MARK) {
+ *pp = p->next;
+ continue;
+ }
+ parent->object.flags |= TMP_MARK;
+ pp = &p->next;
+ }
+ /* count them while clearing the temporary mark */
+ surviving_parents = 0;
+ for (p = commit->parents; p; p = p->next) {
+ p->item->object.flags &= ~TMP_MARK;
+ surviving_parents++;
+ }
+ return surviving_parents;
+}
+
+static int post_simplify_one(struct commit *commit)
+{
+ struct commit_list *p;
+ int num_parents;
+
+ for (p = commit->parents; p; p = p->next)
+ if (!p->item->util)
+ return 0;
+
+ /* All of our parents know what they should be rewritten to */
+ for (p = commit->parents; p; p = p->next)
+ p->item = p->item->util;
+ num_parents = remove_duplicate_parents(commit);
+
+ if (1 < num_parents) {
+ struct commit_list *h = reduce_heads(commit->parents);
+ num_parents = commit_list_count(h);
+ free_commit_list(commit->parents);
+ commit->parents = h;
+ }
+
+ /*
+ * We stand for ourselves if we are root, if we change the tree,
+ * or if we are a merge and our parents simplify to different
+ * commits. Otherwise we can be replaced by the commit our
+ * sole parent is replaced by.
+ */
+ if (!num_parents ||
+ !(commit->object.flags & TREESAME) ||
+ (1 < num_parents))
+ commit->util = commit;
+ else
+ commit->util = commit->parents->item->util;
+
+ return 1;
+}
+
+static void post_simplify(struct rev_info *revs)
+{
+ struct commit_list *list;
+ struct commit_list *yet_to_do, **tail;
+
+ /* feed the list reversed */
+ yet_to_do = NULL;
+ for (list = revs->commits; list; list = list->next)
+ commit_list_insert(list->item, &yet_to_do);
+ while (yet_to_do) {
+ list = yet_to_do;
+ yet_to_do = NULL;
+ tail = &yet_to_do;
+ while (list) {
+ struct commit *commit = list->item;
+ struct commit_list *next = list->next;
+ free(list);
+ list = next;
+ if (!post_simplify_one(commit))
+ tail = &commit_list_insert(commit, tail)->next;
+ }
+ }
+
+ /* clean up the result, removing the simplified ones */
+ list = revs->commits;
+ revs->commits = NULL;
+ tail = &revs->commits;
+ while (list) {
+ struct commit *commit = list->item;
+ struct commit_list *next = list->next;
+ free(list);
+ list = next;
+ if (commit->util == commit)
+ tail = &commit_list_insert(commit, tail)->next;
+ }
+}
+
static void set_children(struct rev_info *revs)
{
struct commit_list *l;
@@ -1418,6 +1521,8 @@ int prepare_revision_walk(struct rev_info *revs)
return -1;
if (revs->topo_order)
sort_in_topological_order(&revs->commits, revs->lifo);
+ if (revs->post_simplify)
+ post_simplify(revs);
if (revs->children.name)
set_children(revs);
return 0;
@@ -1450,26 +1555,6 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp
}
}
-static void remove_duplicate_parents(struct commit *commit)
-{
- struct commit_list **pp, *p;
-
- /* Examine existing parents while marking ones we have seen... */
- pp = &commit->parents;
- while ((p = *pp) != NULL) {
- struct commit *parent = p->item;
- if (parent->object.flags & TMP_MARK) {
- *pp = p->next;
- continue;
- }
- parent->object.flags |= TMP_MARK;
- pp = &p->next;
- }
- /* ... and clear the temporary mark */
- for (p = commit->parents; p; p = p->next)
- p->item->object.flags &= ~TMP_MARK;
-}
-
static int rewrite_parents(struct rev_info *revs, struct commit *commit)
{
struct commit_list **pp = &commit->parents;
diff --git a/revision.h b/revision.h
index f64e8ce..953e69b 100644
--- a/revision.h
+++ b/revision.h
@@ -41,6 +41,7 @@ struct rev_info {
simplify_history:1,
lifo:1,
topo_order:1,
+ post_simplify:1,
tag_objects:1,
tree_objects:1,
blob_objects:1,
--
1.6.0.rc1.29.gc4aca
^ permalink raw reply related
* Re: markdown 2 man, was Re: Git Community Book
From: Wincent Colaiuta @ 2008-07-30 23:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Julian Phillips, Scott Chacon, Petr Baudis,
git list
In-Reply-To: <7vy73j418t.fsf@gitster.siamese.dyndns.org>
El 30/7/2008, a las 21:32, Junio C Hamano escribió:
> That's one valid approach. I or you might have taken a different
> avenue,
> but after all, it's his book, not mine, not yours, nor git list's
> book.
Funnily enough, he chose to title it the "Git Community Book". Hard to
match Scott's enthusiasm; this is the second major initiative we've
seen from him in the last few days (the other being git-scm.com
itself) which to the casual onlooker might look like the "official"
Git homepage and documentation, but in both cases development occurred
behind the scenes and the list was only notified after the fact.
Better late than never I suppose.
> We originally hoped (well, at least I did) that Scott's effort on
> his book
> might help us in improving the User Manual as well, but the approach
> seems
> to make it unlikely. But that is nothing to hold against him --- he
> is
> doing his own thing in a way he feels is the best, and that's
> perfectly
> fine. We lost nothing, perhaps except for a chance to cooperate a bit
> better and to widen the community.
Even though there might not be an automated way to get changes back
from the fork, if there are clear improvements made then there is at
least no legal obstacle to incorporating them back in, the only
obstacle would be time and willingness to do so manually.
>
Cheers,
Wincent
^ permalink raw reply
* Re: git help broken
From: Kevin Ballard @ 2008-07-30 23:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.LSU.1.00.0807310141060.3486@wbgn129.biozentrum.uni-wuerzburg.de>
On Jul 30, 2008, at 4:42 PM, Johannes Schindelin wrote:
> On Wed, 30 Jul 2008, Kevin Ballard wrote:
>
>> `git help diff` no longer finds the git-diff manpage (as of tip of
>> next
>> branch). I haven't tested, but I suspect
>> 940208a771066229bc6a486f6a058e332b71cfe4 is responsible.
>
> Just to save everybody else and her dog the trouble: that commit's
> oneline
> is "builtin-help: make some internal functions available to other
> builtins".
>
> And from the patch, it is pretty obvious that it does not come close
> to
> the "man" code path.
I suspected it because it was the only non-merge commit since my last
pull that mentioned "help" in the message. Regardless, Miklos has
posted a patch that works.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Aidan Van Dyk @ 2008-07-30 23:44 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.10.0807301700500.13032@xenau.zenez.com>
[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]
* Boyd Lynn Gerber <gerberb@zenez.com> [080730 19:30]:
> I have m4-1.4.3 at
>
> ftp://ftp.zenez.com/pub/zenez/prgms/m4-1.4.3-osr6-all.tar.gz
>
> I really have to be able to use configure for most of my OpenSource
> Projects for SCO OS's.
>
> I made the changes so that most things work with the auto tools.
I'm not a SCO guru by any means...
I'm just a user on someone else's SCO machine, just trying to make sure
that the software I write is "fairly portable"...
I'm willing to carry a good and useful tool (like git) in my home
directory in that endeavour, but I'm not carrying all of the GNU stack
in my home directory so I can run configure git is a bit much ;-)
> I did a VM install of OpenServer 6 to try things out. I was able to get
> your -Wall failure, but once I ran the CC=cc CXX=CC ./configure I was able
> to run gmake without any errors. I did have to install the M4 from above
> to get configure to work. So, the straight out of the box install has to
> have gnu m4 to run configure.
So configure.ac must have some magic in it that allows configure to
notice -Wall doesn't work. You can see what it choose in
config.mak.autogen I think. But I'm pretty glad for the kbuild style
Makefile in git not requiring autoconf/automake/etc.
> -g and -O2 are mutually exclusive. You can have either one but not both.
Yes, and I think the default to cc matches -g, not -O2, hence my
failures unless setting -O2.
> I do have tcl and tk
I'm sure... I might even find it burried somewhere on this machine too,
but I have no real need for it.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git help broken
From: Johannes Schindelin @ 2008-07-30 23:44 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Git Mailing List
In-Reply-To: <alpine.LSU.1.00.0807310141060.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Hi,
On Thu, 31 Jul 2008, Johannes Schindelin wrote:
> On Wed, 30 Jul 2008, Kevin Ballard wrote:
>
> > `git help diff` no longer finds the git-diff manpage (as of tip of next
> > branch). I haven't tested, but I suspect
> > 940208a771066229bc6a486f6a058e332b71cfe4 is responsible.
>
> Just to save everybody else and her dog the trouble: that commit's oneline
> is "builtin-help: make some internal functions available to other
> builtins".
>
> And from the patch, it is pretty obvious that it does not come close to
> the "man" code path.
Oh, so it was involved?
Oh, well,
Dscho
^ permalink raw reply
* Re: git help broken
From: Johannes Schindelin @ 2008-07-30 23:42 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Git Mailing List
In-Reply-To: <C0DB03B0-8AF5-4B6A-A9DB-16608128EB31@sb.org>
Hi,
On Wed, 30 Jul 2008, Kevin Ballard wrote:
> `git help diff` no longer finds the git-diff manpage (as of tip of next
> branch). I haven't tested, but I suspect
> 940208a771066229bc6a486f6a058e332b71cfe4 is responsible.
Just to save everybody else and her dog the trouble: that commit's oneline
is "builtin-help: make some internal functions available to other
builtins".
And from the patch, it is pretty obvious that it does not come close to
the "man" code path.
Ciao,
Dscho
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Boyd Lynn Gerber @ 2008-07-30 23:30 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: Junio C Hamano, git
In-Reply-To: <20080730225635.GM10399@yugib.highrise.ca>
On Wed, 30 Jul 2008, Aidan Van Dyk wrote:
> * Boyd Lynn Gerber <gerberb@zenez.com> [080730 17:28]:
> > How about doing a fresh
> >
> > working directory. And just for the fun of it try...
>
> Unfortunately, I can't use configure, apparently that SCO box does'nt
> have a new enough toolc change for M4/autoconf/etc...
>
> But I've never had to use configure before, I've always just built with
> make (gmake on boxes with borked make)
I did have to install m4 and have /usr/local/bin before /usr/bin and /bin
so it uses the gnu m4.
I have m4-1.4.3 at
ftp://ftp.zenez.com/pub/zenez/prgms/m4-1.4.3-osr6-all.tar.gz
I really have to be able to use configure for most of my OpenSource
Projects for SCO OS's.
I made the changes so that most things work with the auto tools.
> > tech0 > CC=cc CXX=CC CFLAGS="-Kalloca -Kthread" CPPFLAGS="-Kalloca
> > -Kthread" ./configure
> > tech0 > gmake
>
> So, with gmake, that "generally" works. I still need to add:
> SNPRINTF_RETURNS_BOGUS=1 NO_MKDTEMP=1
>
> > tech0 > CC=cc CXX=CC ./configure
> > tech0 > gmake
>
> And here, until I rid CFLAGS of -Wall, it fails.
I did a VM install of OpenServer 6 to try things out. I was able to get
your -Wall failure, but once I ran the CC=cc CXX=CC ./configure I was able
to run gmake without any errors. I did have to install the M4 from above
to get configure to work. So, the straight out of the box install has to
have gnu m4 to run configure.
> > > Unfortunately, I have access to only that one SCO box, so I have no idea
> > > of mkdtemp and sprintf problems are on all SCO, or just R=5 ones.
> > >
> > > That allows me to build with NO_POSIX_ONLY_PROGRAMS=1, because for some reason, the
> > > linker complains on linking git-shell:
> > > Undefined first referenced
> > > symbol in file
> > > hexval_table abspath.o
> > > null_sha1 abspath.o
> > > trust_executable_bit abspath.o
> > > has_symlinks abspath.o
> > > UX:ld: ERROR: Symbol referencing errors. No output written to git-shell
> > >
> > > These are all extern varualbes declared in cache.h, but no defined in
> > > any of the objects git-shell links, normally not a problem, but this is SCO.
> >
> > I do not see the problem on my systems.
>
> aidan@jpradley:~/git$ touch abspath.c
> aidan@jpradley:~/git$ gmake V=1 git-shell
> cc -o abspath.o -c -Kalloca -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM abspath.c
> cc -g -Kalloca -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM -o git-shell -L/usr/local/lib abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o compat/lib.a
> Undefined first referenced
> symbol in file
> hexval_table abspath.o
> null_sha1 abspath.o
> trust_executable_bit abspath.o
> has_symlinks abspath.o
> UX:ld: ERROR: Symbol referencing errors. No output written to git-shell
> gmake: *** [git-shell] Error 1
> aidan@jpradley:~/git$ cat config.mak
> NO_OENSSL=1
> NO_MKDTEMP=1
> SHELL=/bin/bash
> SNPRINTF_RETURNS_BOGUS=1
> CFLAGS=-Kalloca
> CPPFLAGS=-Kalloca
>
> I've found that if I set CFLAGS to -O2, it links properly:
> aidan@jpradley:~/git$ touch abspath.c
> aidan@jpradley:~/git$ gmake V=1 git-shell
> cc -o abspath.o -c -Kalloca -O2 -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM abspath.c
> cc -Kalloca -O2 -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM -o git-shell -L/usr/local/lib abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o compat/lib.a
>
> So I think it's "not inlining" stuff like:
> static inline unsigned int hexval(unsigned char c)
> {
> return hexval_table[c];
> }
>
> So, finally, it pretty much works on SCO out of the box - here's my
> settings, which which the test suite passed (well, is passing, I'm at
> t5400, but I expect it to all pass again with these settings):
>
> aidan@jpradley:~/git$ cat config.mak
> NO_TCLTK=1
> NO_MKDTEMP=1
> SHELL=/bin/bash
> SNPRINTF_RETURNS_BOGUS=1
> CFLAGS=-O2
-g and -O2 are mutually exclusive. You can have either one but not both.
I do have tcl and tk
drwxr-xr-x 12 gerberb zenez 2048 Jun 10 17:30 tcl8.5.2
drwxr-xr-x 12 gerberb zenez 2048 Jun 10 17:30 tk8.5.2
So I am not sure what the best option should be. There is a patch for
UnixWare 7 MP4 that has to be installed to MP4 for so failures, but it
works even with ksh with it.
Also on UnixWare 7.1.4 I could not get any m4 greater than 1.4.9 to
compile and work. I finally just used
drwxr-xr-x 8 gerberb zenez 2048 May 19 03:05 m4-1.4.9
drwxrwxrwx 9 gerberb zenez 4096 Apr 3 00:11 make-3.81
drwxr-xr-x 12 gerberb zenez 2048 Jun 10 16:43 tcl8.5.2
drwxr-xr-x 12 gerberb zenez 2048 Jun 10 16:44 tk8.5.2
drwxr-xr-x 9 gerberb zenez 4096 May 19 03:18 sed-4.1.4
On UnixWare 7.1.4 MP4 with ptf9055a.
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: Merging submodules (was Re: Feature suggestion: git-hist)
From: Brian Gernhardt @ 2008-07-30 23:03 UTC (permalink / raw)
To: H Merjin Brand; +Cc: Git List, Lars Noschinski
This message got eaten by a syntax error somewhere. This is a re-send, sorry for any duplicate messages.
On Jul 30, 2008, at 12:26 PM, H.Merijn Brand wrote:
> On Wed, 30 Jul 2008 11:15:55 -0400, Brian Gernhardt
> <benji@silverinsanity.com> wrote:
>
> > Then you do something like:
> >
> > rm -rf module_{a,b,c}/.git # Do this in a test repository, obviously...
> > git add module_a module_b module_c
> > git commit # Needed because '-s ours' uses current HEAD, not index
>
> So far so good.
>
> > git merge --no-commit -s ours module_a/master module_b/master module_c/master
>
> $ git merge --no-commit -s ours fnc/master i00f000/master
> i99f000/master include/master l00m000/master l01f000/master
> l02f000/master l03f000/master l06f000/master l90z000/master
> leerpl/master mutbev/master prtabel/master rpt/master tabellen/master
> zoomen/master Automatic merge went well; stopped before committing as
> requested
>
> > git commit --amend
>
> $ git commit --amend
> fatal: You are in the middle of a merge -- cannot amend.
Hm. I did mention this was completely untested, yes? The problem comes
from the fact that '-s ours' wants to use HEAD, not the index. But you
can't amend a normal commit into a merge, apparently. And I don't think
you want a commit that adds the files and a commit that "does the merge"
as two separate steps.
Well, I don't know how to make the porcelain do this then. But the
plumbing can definitely do it. Hopefully someone more used to doing
strange things like this can give a simpler recipe, but this should
work.
# First reset to the commit you made with all the modules added.
vim commit-message # Create a merge message
commit=$(git commit-tree HEAD: -p HEAD^ -p module_a/master -p
module_b/master -p module_c/master < commit-message)
git update-ref HEAD $commit # Update your current ref
~~ Brian
^ permalink raw reply
* [FUN PATCH] Remove "git clone" parameters if they are the first in a git clone call
From: Pieter de Bie @ 2008-07-30 23:02 UTC (permalink / raw)
To: Git Mailinglist; +Cc: Pieter de Bie
This removes accidental duplicate "git clone" parameters, for example
when typing:
git clone git clone git://repo.or.cz/git.git
---
OK, so it happens often to me that I copy a line that already starts with "git
clone", and then type it myself again, paste, and hit enter. I thought it
might happen to others too, hence this patch.
builtin-clone.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 4b1ab36..9e4c7c2 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -350,6 +350,11 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
junk_pid = getpid();
+ if (argc > 3 && !strcmp(argv[1], "git") && !strcmp(argv[2], "clone")) {
+ argv += 2;
+ argc -= 2;
+ }
+
argc = parse_options(argc, argv, builtin_clone_options,
builtin_clone_usage, 0);
--
1.6.0.rc1.163.g8ec19
^ permalink raw reply related
* Merging submodules
From: Brian Gernhardt @ 2008-07-30 22:59 UTC (permalink / raw)
To: H Merjin Brand; +Cc: Git List, Lars Noschinski
This message got eaten by a syntax error somewhere. This is a re-send, sorry for any duplicate messages.
On Jul 30, 2008, at 9:58 AM, H.Merijn Brand wrote:
> One (very) big disadvantage of SCCS is that commits are on a per-file
> basis, and only in a single directory. This drawback still haunts me in
> git, as my first attempts to convert were successful in a single folder
> and git cannot merge folders into a single project.
>
> Say I now have
>
> /work/src/project/.git
> /work/src/project/module_a/.git
> /work/src/project/module_b/.git
> /work/src/project/module_c/.git
>
> Which are all converted repos from SCCS, I'd like to merge the three
> module_# repos into the top level repo.
Following the example of Linus, the following is completely untested.
First you fetch all of the heads/tags/etc into the superproject with commands like
git fetch module_a refs/heads/*:refs/remotes/module_a/*
git fetch module_b
refs/heads/*:refs/remotes/module_b/*
git fetch module_c
refs/heads/*:refs/remotes/module_c/*
Then you do something like:
rm -rf module_{a,b,c}/.git # Do this in a test repository, obviously...
git add module_a module_b module_c
git commit # Needed because '-s ours' uses current HEAD, not index
git merge --no-commit -s ours module_a/master module_b/master module_c/master
git commit --amend
>From this point on, the project repository has a merged history of the sub-projects, and if anyone doesn't catch up and still makes a commit on a subproject you can use "git merge -s subtree" to merge it in anyway.
You may need to "git rm --cached" some files after the "git add" step if your .gitignore files aren't perfect.
~~ Brian
^ permalink raw reply
* Re: Compile fix for SCO OPenServer
From: Aidan Van Dyk @ 2008-07-30 22:56 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.10.0807301522140.13032@xenau.zenez.com>
[-- Attachment #1: Type: text/plain, Size: 3980 bytes --]
* Boyd Lynn Gerber <gerberb@zenez.com> [080730 17:28]:
> How about doing a fresh
>
> working directory. And just for the fun of it try...
Unfortunately, I can't use configure, apparently that SCO box does'nt
have a new enough toolc change for M4/autoconf/etc...
But I've never had to use configure before, I've always just built with
make (gmake on boxes with borked make)
> tech0 > CC=cc CXX=CC CFLAGS="-Kalloca -Kthread" CPPFLAGS="-Kalloca
> -Kthread" ./configure
> tech0 > gmake
So, with gmake, that "generally" works. I still need to add:
SNPRINTF_RETURNS_BOGUS=1 NO_MKDTEMP=1
> tech0 > CC=cc CXX=CC ./configure
> tech0 > gmake
And here, until I rid CFLAGS of -Wall, it fails.
> > Unfortunately, I have access to only that one SCO box, so I have no idea
> > of mkdtemp and sprintf problems are on all SCO, or just R=5 ones.
> >
> > That allows me to build with NO_POSIX_ONLY_PROGRAMS=1, because for some reason, the
> > linker complains on linking git-shell:
> > Undefined first referenced
> > symbol in file
> > hexval_table abspath.o
> > null_sha1 abspath.o
> > trust_executable_bit abspath.o
> > has_symlinks abspath.o
> > UX:ld: ERROR: Symbol referencing errors. No output written to git-shell
> >
> > These are all extern varualbes declared in cache.h, but no defined in
> > any of the objects git-shell links, normally not a problem, but this is SCO.
>
> I do not see the problem on my systems.
aidan@jpradley:~/git$ touch abspath.c
aidan@jpradley:~/git$ gmake V=1 git-shell
cc -o abspath.o -c -Kalloca -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM abspath.c
cc -g -Kalloca -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM -o git-shell -L/usr/local/lib abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o compat/lib.a
Undefined first referenced
symbol in file
hexval_table abspath.o
null_sha1 abspath.o
trust_executable_bit abspath.o
has_symlinks abspath.o
UX:ld: ERROR: Symbol referencing errors. No output written to git-shell
gmake: *** [git-shell] Error 1
aidan@jpradley:~/git$ cat config.mak
NO_OENSSL=1
NO_MKDTEMP=1
SHELL=/bin/bash
SNPRINTF_RETURNS_BOGUS=1
CFLAGS=-Kalloca
CPPFLAGS=-Kalloca
I've found that if I set CFLAGS to -O2, it links properly:
aidan@jpradley:~/git$ touch abspath.c
aidan@jpradley:~/git$ gmake V=1 git-shell
cc -o abspath.o -c -Kalloca -O2 -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM abspath.c
cc -Kalloca -O2 -Kthread -I/usr/local/include -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DSNPRINTF_RETURNS_BOGUS -DNO_STRCASESTR -DNO_MKDTEMP -DNO_HSTRERROR -DNO_MEMMEM -o git-shell -L/usr/local/lib abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o compat/lib.a
So I think it's "not inlining" stuff like:
static inline unsigned int hexval(unsigned char c)
{
return hexval_table[c];
}
So, finally, it pretty much works on SCO out of the box - here's my
settings, which which the test suite passed (well, is passing, I'm at
t5400, but I expect it to all pass again with these settings):
aidan@jpradley:~/git$ cat config.mak
NO_TCLTK=1
NO_MKDTEMP=1
SHELL=/bin/bash
SNPRINTF_RETURNS_BOGUS=1
CFLAGS=-O2
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] builtin-help: always load_command_list() in cmd_help()
From: Kevin Ballard @ 2008-07-30 22:50 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <1217457487-6509-1-git-send-email-vmiklos@frugalware.org>
This patch works great for me.
Heck, after these help changes, git-help behaves even better in its
error message.
> git help merge-recursive
No manual entry for git-merge-recursive
> git help sdfkjl
No manual entry for gitsdfkjl
It used to complain No manual entry for gitmerge-recursive.
Acked-by: Kevin Ballard <kevin@sb.org>
-Kevin Ballard
On Jul 30, 2008, at 3:38 PM, Miklos Vajna wrote:
> When cmd_help() is called, we always need the list of main and other
> commands, not just when the list of all commands is shown. Before this
> patch 'git help diff' invoked 'man gitdiff' because cmd_to_page()
> thought 'diff' is not a git command.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Wed, Jul 30, 2008 at 01:52:26PM -0700, Kevin Ballard
> <kevin@sb.org> wrote:
>> `git help diff` no longer finds the git-diff manpage (as of tip of
>> next branch). I haven't tested, but I suspect
>> 940208a771066229bc6a486f6a058e332b71cfe4 is responsible.
>
> This fixed the issue for me.
>
> Thanks!
>
> help.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/help.c b/help.c
> index 88c0d5b..968f368 100644
> --- a/help.c
> +++ b/help.c
> @@ -690,6 +690,7 @@ int cmd_help(int argc, const char **argv, const
> char *prefix)
> {
> int nongit;
> const char *alias;
> + unsigned int longest = load_command_list("git-", &main_cmds,
> &other_cmds);
>
> setup_git_directory_gently(&nongit);
> git_config(git_help_config, NULL);
> @@ -698,7 +699,6 @@ int cmd_help(int argc, const char **argv, const
> char *prefix)
> builtin_help_usage, 0);
>
> if (show_all) {
> - unsigned int longest = load_command_list("git-", &main_cmds,
> &other_cmds);
> printf("usage: %s\n\n", git_usage_string);
> list_commands("git commands", longest, &main_cmds, &other_cmds);
> printf("%s\n", git_more_info_string);
> --
> 1.6.0.rc0.14.g95f8.dirty
>
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: q: git-fetch a tad slow?
From: Shawn O. Pearce @ 2008-07-30 22:38 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080730190657.GC26389@elte.hu>
Ingo Molnar <mingo@elte.hu> wrote:
> * Shawn O. Pearce <spearce@spearce.org> wrote:
> >
> > What does `find .git/refs -type f | wc -l` give for the repository on
> > the central server? If its more than a handful (~20) I would suggest
> > running git-gc before testing again.
>
> ah, you are right, it gave 275, then git-gc brought it down to two:
>
> earth4:~/tip> find .git/refs -type f | wc -l
> 275
> earth4:~/tip> git gc
> earth4:~/tip> find .git/refs -type f | wc -l
> 2
>
> alas, fetching still seems to be slow:
>
> titan:~/tip> time git-fetch origin
>
> real 0m5.112s
> user 0m0.972s
> sys 0m3.380s
Yea, OK, there's definately performance problems there. And it
should be fast. Its too common of a case (fetching small deltas).
> > I'll try to find some time to reproduce the issue and look at the
> > bottleneck here. I'm two days into a new job so my git time has been
> > really quite short this week. :-|
>
> fetching the -tip repo:
>
> http://people.redhat.com/mingo/tip.git/README
>
> and then running 'git remote update' will i think already show this
> problem for you too. People have been complaining about how slow the
> update is.
Thanks. I'll try to poke at it this evening and see what I find.
git-fetch should be running faster than this.
--
Shawn.
^ permalink raw reply
* [PATCH] builtin-help: always load_command_list() in cmd_help()
From: Miklos Vajna @ 2008-07-30 22:38 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <C0DB03B0-8AF5-4B6A-A9DB-16608128EB31@sb.org>
When cmd_help() is called, we always need the list of main and other
commands, not just when the list of all commands is shown. Before this
patch 'git help diff' invoked 'man gitdiff' because cmd_to_page()
thought 'diff' is not a git command.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Wed, Jul 30, 2008 at 01:52:26PM -0700, Kevin Ballard <kevin@sb.org> wrote:
> `git help diff` no longer finds the git-diff manpage (as of tip of
> next branch). I haven't tested, but I suspect
> 940208a771066229bc6a486f6a058e332b71cfe4 is responsible.
This fixed the issue for me.
Thanks!
help.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/help.c b/help.c
index 88c0d5b..968f368 100644
--- a/help.c
+++ b/help.c
@@ -690,6 +690,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
{
int nongit;
const char *alias;
+ unsigned int longest = load_command_list("git-", &main_cmds, &other_cmds);
setup_git_directory_gently(&nongit);
git_config(git_help_config, NULL);
@@ -698,7 +699,6 @@ int cmd_help(int argc, const char **argv, const char *prefix)
builtin_help_usage, 0);
if (show_all) {
- unsigned int longest = load_command_list("git-", &main_cmds, &other_cmds);
printf("usage: %s\n\n", git_usage_string);
list_commands("git commands", longest, &main_cmds, &other_cmds);
printf("%s\n", git_more_info_string);
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
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