* Re: bash completions code for git+porcelain
From: Petr Baudis @ 2005-12-05 0:16 UTC (permalink / raw)
To: Ben Clifford; +Cc: Git Mailing List
In-Reply-To: <0039D3CD-8254-4E29-8563-D60487719378@hawaga.org.uk>
Dear diary, on Sun, Dec 04, 2005 at 03:05:01AM CET, I got a letter
where Ben Clifford <benc@hawaga.org.uk> said that...
> just a note that I'm still plodding along slowly adding bits to the
> bash completion code available by typing:
>
> cg clone http://www.hawaga.org.uk/gitcompletion.git
>
> handles (some of) git, gitk, cg, stg commands - enough to be useful
> for me, at least ;-)
Thanks a lot. I've added the Cogito-related stuff to its contrib/
directory (just with a bit saner filenames). I will try to update them
as new changes appear in, but I would be grateful if you could please
notify me when you think I really should. ;-)
Thanks again,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* announce: git browser
From: Artem Khodush @ 2005-12-05 0:23 UTC (permalink / raw)
To: Git Mailing List
Hello,
I'd like to announce experimental web interface for git,
complementary to gitweb. It visualizes commit history graph
and shows commit diffs.
See http://straytree.com/git-browser/GitBrowser.html?r=git
Artem.
^ permalink raw reply
* Re: [PATCH] Document the --(no-)edit switch of git-revert and git-cherry-pick
From: Petr Baudis @ 2005-12-05 0:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20051126221244.5131.65509.stgit@machine.or.cz>
Dear diary, on Sat, Nov 26, 2005 at 11:12:44PM CET, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> This switch was not documented properly. I decided not to mention
> the --no-edit switch in the git-cherry-pick documentation since
> we always default to no editing.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
All right, please disregard my previous patch question - I'm sorry,
this is the patch I actually wanted to inquire about. ;-)
I'll better go get some proper sleep now before I manage to do some
worse damage.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Junio C Hamano @ 2005-12-05 0:27 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <7v7jawmkpo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> It is just silly to start the file called "config" with a
> comment that says "This is the config file."
Any likes or dislikes?
^ permalink raw reply
* Re: [PATCH] Document the --(no-)edit switch of git-revert and git-cherry-pick
From: Junio C Hamano @ 2005-12-05 0:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051205002535.GD22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> All right, please disregard my previous patch question - I'm sorry,
> this is the patch I actually wanted to inquire about. ;-)
Ah, thanks for the reminder, and goodnight.
^ permalink raw reply
* Re: announce: git browser
From: Petr Baudis @ 2005-12-05 0:42 UTC (permalink / raw)
To: Artem Khodush; +Cc: Git Mailing List
In-Reply-To: <40b2b7d90512041623g1e22fecai9470ffcb94f40a58@mail.gmail.com>
Hello,
Dear diary, on Mon, Dec 05, 2005 at 01:23:24AM CET, I got a letter
where Artem Khodush <greenkaa@gmail.com> said that...
> I'd like to announce experimental web interface for git,
> complementary to gitweb. It visualizes commit history graph
> and shows commit diffs.
>
> See http://straytree.com/git-browser/GitBrowser.html?r=git
quite interesting! I always dreamt (not intensively enough to go
myself and do it) about gitweb having gitk-like visualization, possibly
this might help. ;-)
Couple of initial notes:
* I would find it much nicer if you wouldn't "squeeze" all the day's
(except merge) commits together, but left them separate. Possibly a
switch to squeeze them, but I'm really not sure if it's even useful to
have.
* The line graphics etc. might be more colourful and prettier. ;-)
* Then it could have a "gitk mode" where the time flows vertically and
author+title+time is shown in each line. It turns out that this might
not be the prettiest, but it's really the most informative and useful
view, IMHO.
* When I click on the little black box, the commit window disappears
before I manage to click on anything inside; I would intuitively expect
the reverse behaviour - that this happens when I don't click on the box.
Or that clicking on the box does not matter. *shrug* The web interface
with those windows popping up admitelly makes my mind somewhat
uncomfortable, but it's hard to pin-point down why.
* Possibly, the commit information could be shown in a dedicated
screen area altogether. It also wouldn't obscure the view of the actual
diagram, and it would be more visible that it cutely highlights the
appropriate box based on the current commit you have your cursor on.
* It looks too much like Feynman diagrams when the merge arrow
points slightly backwards; perhaps you could try to avoid that.
* It doesn't seem to handle the UTF8 characters properly.
Quite nice for starters, though! The diff viewer looks pretty slick,
too.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH gitweb] Visually indicating patch size with horizontal bars
From: Chris Shoemaker @ 2005-12-05 1:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff, Kay Sievers, git
In-Reply-To: <20051205000442.GB22159@pasky.or.cz>
On Mon, Dec 05, 2005 at 01:04:42AM +0100, Petr Baudis wrote:
> Dear diary, on Wed, Nov 02, 2005 at 01:12:06AM CET, I got a letter
> where Chris Shoemaker <c.shoemaker@cox.net> said that...
> > On Wed, Nov 02, 2005 at 12:33:38PM +1300, Martin Langhoff wrote:
> > > On 11/2/05, Petr Baudis <pasky@suse.cz> wrote:
> > > > What about having the color indicate the number of affected files (let's
> > > > say on a blue..red scale) and the width the size of patch?
> > >
> > > I'm a /little bit/ colour blind on the red scale -- so I vote for 2
> > > bars, each half the heigth of the current bar. ;-)
> >
> > I was going to use two bars for add vs. delete, but this could work,
> > too. I'm intending on getting back to this ASAP, but for now my
> > cvsimport problems are higher priority (see other post).
>
> Is there any progress, by the way?
A little. I decided to follow Junio's suggestion of caching the
result of "git-diff-tree -r -p $commit | git-apply --numstat" in a
BerkeleyDB. (I liked the idea of reusing the cached results on the
commit page, too.) I got a script to populate the cache, then I
suspect could be easily adapting into a commit-hook. Then I started
working on the gitweb part and tried to follow another suggestion
(Kay's, I think.) to use CSS instead of (yet another) embedded .png.
This is where I got hung up: I discovered something strange (to me, at
least) about CSS/html: I'm using the <td></td> in the fifth column of
the shortlog. I tried to use an anchor tag for the added count and
one for the deleted count. Setting "display:block" and the different
background-colors works (produces stacked horizontal bars), as does
setting various widths (an essential point), but *ONLY* using "width"
in the CSS. Using width anchor attribute simply doesn't work.
Honestly, html/css is not my strong suit and neither is perl, although
the BerkeleyDB perl API seemed simple enough.
> If you didn't manage to finish it, no big deal - but it would be great
> to have at least the last version you screenshotted, since IIRC I
> couldn't find that one either, and I would like to play with it a bit.
I'm happy for anyone to take this over. Since my excursion into css
didn't really work, I'd suggest starting with the gitweb-difftreeP.cgi
version. I will send you (and anyone else who asks) that file and the
cache population script.
-chris
^ permalink raw reply
* Re: announce: git browser
From: Artem Khodush @ 2005-12-05 1:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20051205004238.GE22159@pasky.or.cz>
On 12/5/05, Petr Baudis <pasky@suse.cz> wrote:
> > See http://straytree.com/git-browser/GitBrowser.html?r=git
>
> quite interesting! I always dreamt (not intensively enough to go
> myself and do it) about gitweb having gitk-like visualization, possibly
> this might help. ;-)
>
> Couple of initial notes:
>
> * I would find it much nicer if you wouldn't "squeeze" all the day's
> (except merge) commits together, but left them separate. Possibly a
> switch to squeeze them, but I'm really not sure if it's even useful to
> have.
Well it's easy to do, but then, in Linus tree, a single day would not fit
on my screen :-) So 'squeezed' mode is helpful for me, at least,
to get big picture at a glance - in git tree, for example, I can see
the 0.99.5 release branch to begin and end on a single screen.
> * The line graphics etc. might be more colourful and prettier. ;-)
And the question is: the colours are assigned to what:
branches ? authors ? committers ? repositories ?
> * Then it could have a "gitk mode" where the time flows vertically and
> author+title+time is shown in each line. It turns out that this might
> not be the prettiest, but it's really the most informative and useful
> view, IMHO.
But in this view, you can have only the number-of-lines-on-the-screen
commits visible. And with graphics done in javascript, scrolling is
painfully slow, at least in mozilla. And I think that implementing
quick search in a diagram will provide much more information
than one can get by 'visual grep' :-). So I don't know, need to think
a bit more .
> * When I click on the little black box, the commit window disappears
> before I manage to click on anything inside; I would intuitively expect
> the reverse behaviour - that this happens when I don't click on the box.
> Or that clicking on the box does not matter. *shrug* The web interface
> with those windows popping up admitelly makes my mind somewhat
> uncomfortable, but it's hard to pin-point down why.
Yep, the boxes intentionally are not clickable, I think it makes navigation
easier, perhaps it could be made as a preference..
> * Possibly, the commit information could be shown in a dedicated
> screen area altogether. It also wouldn't obscure the view of the actual
> diagram, and it would be more visible that it cutely highlights the
> appropriate box based on the current commit you have your cursor on.
Yes I also think about it. Initially the boxes were semi-transparent so
you could track the highlihgt under the box, it looked very nice,
but that was too slow to be usable on my computer, and opera
does not have that 'opacity' thing..
> * It looks too much like Feynman diagrams when the merge arrow
> points slightly backwards; perhaps you could try to avoid that.
If I find a way to do it without further complicating placement algorightm,
maybe..
> * It doesn't seem to handle the UTF8 characters properly
> Quite nice for starters, though! The diff viewer looks pretty slick,
> too.
Thanks! Btw, I took the diff viewer pretty much unmodified from gitweb.
Artem.
^ permalink raw reply
* Re: bash completions code for git+porcelain
From: Ben Clifford @ 2005-12-05 3:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20051205001616.GC22159@pasky.or.cz>
On 5 Dec 2005, at 11:16, Petr Baudis wrote:
>
> Thanks a lot. I've added the Cogito-related stuff to its contrib/
> directory (just with a bit saner filenames).
>
>
>
- and you modified the # intro commentary a tiny bit too.
To make it hopefully a tiny bit easier to track what has changed,
I pulled the # intro changes over in my repo.
The relevant files in my commit
32f77e7c2e6c670f747f82d1ce99c3f6526e044f should be bytewise identical
to the ones in your commit c10cc1d2a99b01ed3bf45d5f2ad6157940a22365
(though still with different names).
--
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS number(s) at above URL.
^ permalink raw reply
* Re: [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Andreas Ericsson @ 2005-12-05 11:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vu0docrqz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>
>>It is just silly to start the file called "config" with a
>>comment that says "This is the config file."
>
>
> Any likes or dislikes?
>
I believe we all agree in silent consensus.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* make gitfakemmap standalone to fix linking error in git.c
From: Alex Riesen @ 2005-12-05 13:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 225 bytes --]
The patch is to fix linking error because of gitfakemmap referencing
die living in usage.c, and git.c not linking in the file. Instead of
hardcoding usage.o in git.c prerequisites, I separated mmap from the
main sources.
[-- Attachment #2: 0001-make-fakemmap-standalone-to-fix-linking-error-because-of-gitfakemmap.txt --]
[-- Type: text/plain, Size: 2720 bytes --]
Subject: [PATCH] make fakemmap standalone to fix linking error because of gitfakemmap
referencing die living in usage.c, and git.c not linking in the file.
Instead of hardcoding usage.o in git.c prerequisites, I separated mmap.
Signed-off-by: Alex Riesen <fork0@gmail.com>
---
cache.h | 18 +++---------------
compat/mmap.c | 11 +++++++----
compat/mmap.h | 15 +++++++++++++++
3 files changed, 25 insertions(+), 19 deletions(-)
create mode 100644 compat/mmap.h
e1e24d29b684d468a7be5d097ba3e1679170e7db
diff --git a/cache.h b/cache.h
index f9b367f..c70a467 100644
--- a/cache.h
+++ b/cache.h
@@ -11,7 +11,9 @@
#include <string.h>
#include <errno.h>
#include <limits.h>
-#ifndef NO_MMAP
+#ifdef NO_MMAP
+#include "compat/mmap.h"
+#else
#include <sys/mman.h>
#endif
#include <sys/param.h>
@@ -373,20 +375,6 @@ extern void packed_object_info_detail(st
/* Dumb servers support */
extern int update_server_info(int);
-#ifdef NO_MMAP
-
-#ifndef PROT_READ
-#define PROT_READ 1
-#define PROT_WRITE 2
-#define MAP_PRIVATE 1
-#define MAP_FAILED ((void*)-1)
-#endif
-
-extern void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);
-extern int gitfakemunmap(void *start, size_t length);
-
-#endif
-
typedef int (*config_fn_t)(const char *, const char *);
extern int git_default_config(const char *, const char *);
extern int git_config_from_file(config_fn_t fn, const char *);
diff --git a/compat/mmap.c b/compat/mmap.c
index a051c47..98cf3cb 100644
--- a/compat/mmap.c
+++ b/compat/mmap.c
@@ -2,21 +2,24 @@
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
-#include "../cache.h"
+#include <string.h>
+#include "mmap.h"
void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset)
{
int n = 0;
- if (start != NULL || !(flags & MAP_PRIVATE))
- die("Invalid usage of gitfakemmap.");
+ if (!start || !(flags & MAP_PRIVATE)) {
+ fprintf(stderr, "Invalid usage of gitfakemmap.\n");
+ exit(128); /* see die() in ../usage.c */
+ }
if (lseek(fd, offset, SEEK_SET) < 0) {
errno = EINVAL;
return MAP_FAILED;
}
- start = xmalloc(length);
+ start = malloc(length);
if (start == NULL) {
errno = ENOMEM;
return MAP_FAILED;
diff --git a/compat/mmap.h b/compat/mmap.h
new file mode 100644
index 0000000..08d7f99
--- /dev/null
+++ b/compat/mmap.h
@@ -0,0 +1,15 @@
+#ifndef MMAP_H
+#define MMAP_H
+
+#ifndef PROT_READ
+#define PROT_READ 1
+#define PROT_WRITE 2
+#define MAP_PRIVATE 1
+#define MAP_FAILED ((void*)-1)
+#endif
+
+extern void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);
+extern int gitfakemunmap(void *start, size_t length);
+
+#endif
+
--
0.99.9.GIT
^ permalink raw reply related
* Re: make gitfakemmap standalone to fix linking error in git.c
From: Alex Riesen @ 2005-12-05 13:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <81b0412b0512050519k5ed80035x9eb4907f569e0a4b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 465 bytes --]
The patch is to fix the error introduced by previous patch, which
inverted condition of checking for the supported case (start must be
NULL).
On 12/5/05, Alex Riesen <raa.lkml@gmail.com> wrote:
> The patch is to fix linking error because of gitfakemmap referencing
> die living in usage.c, and git.c not linking in the file. Instead of
> hardcoding usage.o in git.c prerequisites, I separated mmap from the
> main sources.
Why does it always happen...
[-- Attachment #2: 0002-fix-bug-introduced-by-previous-change.txt --]
[-- Type: text/plain, Size: 623 bytes --]
Subject: [PATCH] fix bug introduced by previous change
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
compat/mmap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
58d38f03086fe30f3f758f2f27fde0ad05107b4a
diff --git a/compat/mmap.c b/compat/mmap.c
index 98cf3cb..cfa1f25 100644
--- a/compat/mmap.c
+++ b/compat/mmap.c
@@ -9,7 +9,7 @@ void *gitfakemmap(void *start, size_t le
{
int n = 0;
- if (!start || !(flags & MAP_PRIVATE)) {
+ if (start || !(flags & MAP_PRIVATE)) {
fprintf(stderr, "Invalid usage of gitfakemmap.\n");
exit(128); /* see die() in ../usage.c */
}
--
0.99.9.GIT
^ permalink raw reply related
* Re: make gitfakemmap standalone to fix linking error in git.c
From: Petr Baudis @ 2005-12-05 14:11 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0512050524w7b632651n93c836fda41a39d@mail.gmail.com>
Dear diary, on Mon, Dec 05, 2005 at 02:24:47PM CET, I got a letter
where Alex Riesen <raa.lkml@gmail.com> said that...
> The patch is to fix the error introduced by previous patch, which
> inverted condition of checking for the supported case (start must be
> NULL).
>
> On 12/5/05, Alex Riesen <raa.lkml@gmail.com> wrote:
> > The patch is to fix linking error because of gitfakemmap referencing
> > die living in usage.c, and git.c not linking in the file. Instead of
> > hardcoding usage.o in git.c prerequisites, I separated mmap from the
> > main sources.
>
> Why does it always happen...
Possibly not worth yet another patch submission now, but in general I
believe it's better to send new revision of the original patch rather
than another patch on top of the previous one.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: More merge questions (why doesn't this work?)
From: Sven Verdoolaege @ 2005-12-05 15:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q5r2qb2.fsf@assigned-by-dhcp.cox.net>
On Fri, Dec 02, 2005 at 12:32:17PM -0800, Junio C Hamano wrote:
> Sven Verdoolaege <skimo@kotnet.org> writes:
> > I do. git commit won't let me commit an empty tree, or at
> > least I haven't figured out how to make it do that.
>
> You are right, at least for the initial commit (for subsequent
> commits it happily commits an empty tree).
>
> Now why anybody would want to it is a different matter. Is it
> because you would want to record that your project started from
> scratch, as opposed to some import from an existing non
> versioned (or versioned by another SCM) working tree?
Something like that, yes.
In the beginning there as nothing and git commited the nothingness.
skimo
^ permalink raw reply
* Re: make gitfakemmap standalone to fix linking error in git.c
From: Alex Riesen @ 2005-12-05 15:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Junio C Hamano
In-Reply-To: <20051205141141.GF22159@pasky.or.cz>
On 12/5/05, Petr Baudis <pasky@suse.cz> wrote:
> > The patch is to fix the error introduced by previous patch, which
> > inverted condition of checking for the supported case (start must be
> > NULL).
>
> Possibly not worth yet another patch submission now, but in general I
> believe it's better to send new revision of the original patch rather
> than another patch on top of the previous one.
Yes, of course. Sorry... I will not resend, it's trivial, but I
promise to get better.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9l aka 1.0rc4
From: Gerrit Pape @ 2005-12-05 17:26 UTC (permalink / raw)
To: git
In-Reply-To: <7vy831p69i.fsf@assigned-by-dhcp.cox.net>
On Sun, Dec 04, 2005 at 01:21:13AM -0800, Junio C Hamano wrote:
> *1* It appears Debian finally has an official maintainer, so I
Yes, I've taken over maintainership, and introduced the git-core package
into Debian/unstable, the git tools previously were included in the
cogito package.
> am inclined to stop building and supplying the debs starting
> from the next version --- one less thing to worry about for me.
> I hope the Debian side splits the packages along the same line
> as we do RPMs.
I'll do so and split off git-arch, git-cvs, git-svn, git-email from the
git-core package, as already done with gitk. Additionally I have the
webdocs in a separate git-doc package, maybe that's a good idea for the
rpms also.
Regards, Gerrit.
^ permalink raw reply
* Re: make gitfakemmap standalone to fix linking error in git.c
From: Junio C Hamano @ 2005-12-05 17:40 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0512050524w7b632651n93c836fda41a39d@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> Why does it always happen...
Because you touched you did not absolutely have to ;-).
When I took setenv patch for git.c, I was thinking about
something similar. It may be cleaner to split out the pieces so
that the functions like usage(), die(), xmalloc() and friends
could be linkable in git.c and others that want to link in only
the minimum set without including "cache.h" which has more
intimate knowledge of other git internals.
^ permalink raw reply
* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: Jason Riedy @ 2005-12-05 18:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr78sebp8.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- putenv(3) says
- The string pointed to by string becomes part of the environment,
- so altering the string changes the environment.
Good catch, thanks. The Solaris man page first says the
string space is "no longer used", but at the very end warns
against using an automatic variable. Chalk one up for lousy
docs.
(And sizeof(char) is just habit; 99% of my mallocs aren't of
char... Sorry.)
Jason
^ permalink raw reply
* [PATCH] Document config.mak in INSTALL.
From: Jason Riedy @ 2005-12-05 18:38 UTC (permalink / raw)
To: git
The existing config.mak should satisfy almost everyone... You
can change the prefix and other vars catch the new setting
anyways. I had forgotten that ?= acts as = (lazy value binding)
and as not := (immediate value binding).
Signed-off-by: E. Jason Riedy <ejr@cs.berkeley.edu>
---
INSTALL | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
f03c45f49ffff74df1699444612ff7b3a75bd653
diff --git a/INSTALL b/INSTALL
index 63ccf62..916ddd4 100644
--- a/INSTALL
+++ b/INSTALL
@@ -87,3 +87,6 @@ Issues of note:
have all the libraries/tools needed, or you may have
necessary libraries at unusual locations. Please look at the
top of the Makefile to see what can be adjusted for your needs.
+ You can place local settings in config.mak and the Makefile
+ will include them. Note that config.mak is not distributed;
+ the name is reserved for local settings.
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: H. Peter Anvin @ 2005-12-05 18:39 UTC (permalink / raw)
To: Jason Riedy; +Cc: Junio C Hamano, git
In-Reply-To: <14404.1133806037@lotus.CS.Berkeley.EDU>
Jason Riedy wrote:
> And Junio C Hamano writes:
> - putenv(3) says
> - The string pointed to by string becomes part of the environment,
> - so altering the string changes the environment.
>
> Good catch, thanks. The Solaris man page first says the
> string space is "no longer used", but at the very end warns
> against using an automatic variable. Chalk one up for lousy
> docs.
>
> (And sizeof(char) is just habit; 99% of my mallocs aren't of
> char... Sorry.)
>
Personally I consider it a serious bug in the C language that
sizeof(char) == 1 by definition. It basically prohibits a whole lot of
useful machine models.
-hpa
^ permalink raw reply
* Re: [PATCH 7/9] Add the accurate changeset applyer
From: Martin Langhoff @ 2005-12-05 18:53 UTC (permalink / raw)
To: Eric Wong; +Cc: git list, Martin Langhoff
In-Reply-To: <20051203025150.GA13179@mail.yhbt.net>
On 12/3/05, Eric Wong <normalperson@yhbt.net> wrote:
> Rerunning it doesn't seem to pull anymore. IIRC, My previous times
> only imported around ~150 patchsets. The time it took to run this
> was certainly longer than the last run (~4 hours here, vs ~2 hours
> I mentioned in <20051124074605.GA4789@mail.yhbt.net>, so there may
> be a bug somewhere... Unfortunately, I no longer have those old
> trees around.
>
> I've imported several trees with >1000 revisions without problems,
> mpd-uclinux is among them:
>
> http://mpd.bogomips.org/mpd-uclinux.git/
Haven't been able to retest an import and have it finished without my
ssh session dropping (should have used gnu screen). I'll be able to
test it more thoroughly in a couple of days. Very sorry about the
delay.
cheers,
martin
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9l aka 1.0rc4
From: Junio C Hamano @ 2005-12-05 20:16 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20051205172601.4980.qmail@67565db8368c55.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> On Sun, Dec 04, 2005 at 01:21:13AM -0800, Junio C Hamano wrote:
>> *1* It appears Debian finally has an official maintainer, so I
>
> Yes, I've taken over maintainership, and introduced the git-core package
> into Debian/unstable, the git tools previously were included in the
> cogito package.
This question is probably relevant only to you and people who
want to build deb themselves until you package the updated
upstream, but what is your (and others') preference on debian/
directory in what _I_ ship?
I see three possibilities:
- Do not care, and keep them as they are as they bitrot.
- Remove debian/ from the upstream tree.
- You feed patches to me, and I promise you not to touch
debian/ area, except adding a new -0 entry at the top of the
changelog when bumping the version number up, and perhaps
adjusting to the main Makefile changes if the solution is
obvious.
I am neutral between the second and the third.
^ permalink raw reply
* [PATCH] Clean up compatibility definitions.
From: Junio C Hamano @ 2005-12-05 20:22 UTC (permalink / raw)
To: git; +Cc: Alex Riesen
In-Reply-To: <7vfyp7cuii.fsf@assigned-by-dhcp.cox.net>
This attempts to clean up the way various compatibility
functions are defined and used.
- A new header file, git-compat-util.h, is introduced. This
looks at various NO_XXX and does necessary function name
replacements, equivalent of -Dstrcasestr=gitstrcasestr in the
Makefile.
- Those function name replacements are removed from the Makefile.
- Common features such as usage(), die(), xmalloc() are moved
from cache.h to git-compat-util.h; cache.h includes
git-compat-util.h itself.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> When I took setenv patch for git.c, I was thinking about
> something similar. It may be cleaner to split out the pieces so
> that the functions like usage(), die(), xmalloc() and friends
> could be linkable in git.c and others that want to link in only
> the minimum set without including "cache.h" which has more
> intimate knowledge of other git internals.
Maybe something like this...
Makefile | 16 ++++---
cache.h | 96 -------------------------------------------
compat/mmap.c | 2 -
compat/strcasestr.c | 3 -
git-compat-util.h | 113 +++++++++++++++++++++++++++++++++++++++++++++++++++
git.c | 15 +++----
mailinfo.c | 4 --
usage.c | 2 -
8 files changed, 132 insertions(+), 119 deletions(-)
create mode 100644 git-compat-util.h
2823be66bb4a1f6a6b4240e24dfd402e4146c43c
diff --git a/Makefile b/Makefile
index df3c6eb..1f1088e 100644
--- a/Makefile
+++ b/Makefile
@@ -162,7 +162,7 @@ LIB_FILE=libgit.a
LIB_H = \
blob.h cache.h commit.h count-delta.h csum-file.h delta.h \
diff.h epoch.h object.h pack.h pkt-line.h quote.h refs.h \
- run-command.h strbuf.h tag.h tree.h
+ run-command.h strbuf.h tag.h tree.h git-compat-util.h
DIFF_OBJS = \
diff.o diffcore-break.o diffcore-order.o diffcore-pathspec.o \
@@ -174,9 +174,11 @@ LIB_OBJS = \
object.o pack-check.o patch-delta.o path.o pkt-line.o \
quote.o read-cache.o refs.o run-command.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
- tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
+ tag.o tree.o config.o environment.o copy.o \
$(DIFF_OBJS)
+COMPAT_OBJS = usage.o ctype.o
+
LIBS = $(LIB_FILE)
LIBS += -lz
@@ -320,15 +322,15 @@ ifdef NEEDS_NSL
SIMPLE_LIB += -lnsl
endif
ifdef NO_STRCASESTR
- COMPAT_CFLAGS += -Dstrcasestr=gitstrcasestr -DNO_STRCASESTR=1
+ COMPAT_CFLAGS += -DNO_STRCASESTR
COMPAT_OBJS += compat/strcasestr.o
endif
ifdef NO_SETENV
- COMPAT_CFLAGS += -Dsetenv=gitsetenv -DNO_SETENV=1
+ COMPAT_CFLAGS += -DNO_SETENV
COMPAT_OBJS += compat/setenv.o
endif
ifdef NO_MMAP
- COMPAT_CFLAGS += -Dmmap=gitfakemmap -Dmunmap=gitfakemunmap -DNO_MMAP
+ COMPAT_CFLAGS += -DNO_MMAP
COMPAT_OBJS += compat/mmap.o
endif
ifdef NO_IPV6
@@ -363,9 +365,9 @@ all: $(ALL_PROGRAMS)
all:
$(MAKE) -C templates
-git$(X): git.c $(COMPAT_OBJS) Makefile
+git$X: git.c $(LIB_FILE) Makefile
$(CC) -DGIT_EXEC_PATH='"$(bindir)"' -DGIT_VERSION='"$(GIT_VERSION)"' \
- $(CFLAGS) $(COMPAT_CFLAGS) -o $@ $(filter %.c,$^) $(filter %.o,$^)
+ $(CFLAGS) $(COMPAT_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE)
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
rm -f $@
diff --git a/cache.h b/cache.h
index f9b367f..86fc250 100644
--- a/cache.h
+++ b/cache.h
@@ -1,23 +1,7 @@
#ifndef CACHE_H
#define CACHE_H
-#include <unistd.h>
-#include <stdio.h>
-#include <sys/stat.h>
-#include <fcntl.h>
-#include <stddef.h>
-#include <stdlib.h>
-#include <stdarg.h>
-#include <string.h>
-#include <errno.h>
-#include <limits.h>
-#ifndef NO_MMAP
-#include <sys/mman.h>
-#endif
-#include <sys/param.h>
-#include <netinet/in.h>
-#include <sys/types.h>
-#include <dirent.h>
+#include "git-compat-util.h"
#include SHA1_HEADER
#include <zlib.h>
@@ -36,15 +20,6 @@
#define DTYPE(de) DT_UNKNOWN
#endif
-#ifdef __GNUC__
-#define NORETURN __attribute__((__noreturn__))
-#else
-#define NORETURN
-#ifndef __attribute__
-#define __attribute__(x)
-#endif
-#endif
-
/*
* Intensive research over the course of many years has shown that
* port 9418 is totally unused by anything else. Or
@@ -250,11 +225,6 @@ extern const char *resolve_ref(const cha
extern int create_symref(const char *git_HEAD, const char *refs_heads_master);
extern int validate_symref(const char *git_HEAD);
-/* General helper functions */
-extern void usage(const char *err) NORETURN;
-extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
-extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
-
extern int base_name_compare(const char *name1, int len1, int mode1, const char *name2, int len2, int mode2);
extern int cache_name_compare(const char *name1, int len1, const char *name2, int len2);
@@ -272,30 +242,6 @@ extern int setup_ident(void);
extern const char *git_author_info(void);
extern const char *git_committer_info(void);
-static inline void *xmalloc(size_t size)
-{
- void *ret = malloc(size);
- if (!ret)
- die("Out of memory, malloc failed");
- return ret;
-}
-
-static inline void *xrealloc(void *ptr, size_t size)
-{
- void *ret = realloc(ptr, size);
- if (!ret)
- die("Out of memory, realloc failed");
- return ret;
-}
-
-static inline void *xcalloc(size_t nmemb, size_t size)
-{
- void *ret = calloc(nmemb, size);
- if (!ret)
- die("Out of memory, calloc failed");
- return ret;
-}
-
struct checkout {
const char *base_dir;
int base_dir_len;
@@ -373,20 +319,6 @@ extern void packed_object_info_detail(st
/* Dumb servers support */
extern int update_server_info(int);
-#ifdef NO_MMAP
-
-#ifndef PROT_READ
-#define PROT_READ 1
-#define PROT_WRITE 2
-#define MAP_PRIVATE 1
-#define MAP_FAILED ((void*)-1)
-#endif
-
-extern void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);
-extern int gitfakemunmap(void *start, size_t length);
-
-#endif
-
typedef int (*config_fn_t)(const char *, const char *);
extern int git_default_config(const char *, const char *);
extern int git_config_from_file(config_fn_t fn, const char *);
@@ -404,31 +336,5 @@ extern char git_default_name[MAX_GITNAME
#define MAX_ENCODING_LENGTH 64
extern char git_commit_encoding[MAX_ENCODING_LENGTH];
-/* Sane ctype - no locale, and works with signed chars */
-#undef isspace
-#undef isdigit
-#undef isalpha
-#undef isalnum
-#undef tolower
-#undef toupper
-extern unsigned char sane_ctype[256];
-#define GIT_SPACE 0x01
-#define GIT_DIGIT 0x02
-#define GIT_ALPHA 0x04
-#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
-#define isspace(x) sane_istest(x,GIT_SPACE)
-#define isdigit(x) sane_istest(x,GIT_DIGIT)
-#define isalpha(x) sane_istest(x,GIT_ALPHA)
-#define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
-#define tolower(x) sane_case((unsigned char)(x), 0x20)
-#define toupper(x) sane_case((unsigned char)(x), 0)
-
-static inline int sane_case(int x, int high)
-{
- if (sane_istest(x, GIT_ALPHA))
- x = (x & ~0x20) | high;
- return x;
-}
-
extern int copy_fd(int ifd, int ofd);
#endif /* CACHE_H */
diff --git a/compat/mmap.c b/compat/mmap.c
index a051c47..55cb120 100644
--- a/compat/mmap.c
+++ b/compat/mmap.c
@@ -2,7 +2,7 @@
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
-#include "../cache.h"
+#include "../git-compat-util.h"
void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset)
{
diff --git a/compat/strcasestr.c b/compat/strcasestr.c
index b96414d..26896de 100644
--- a/compat/strcasestr.c
+++ b/compat/strcasestr.c
@@ -1,5 +1,4 @@
-#include <string.h>
-#include <ctype.h>
+#include "../git-compat-util.h"
char *gitstrcasestr(const char *haystack, const char *needle)
{
diff --git a/git-compat-util.h b/git-compat-util.h
new file mode 100644
index 0000000..4185b12
--- /dev/null
+++ b/git-compat-util.h
@@ -0,0 +1,113 @@
+#ifndef GIT_COMPAT_UTIL_H
+#define GIT_COMPAT_UTIL_H
+
+#include <unistd.h>
+#include <stdio.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <stddef.h>
+#include <stdlib.h>
+#include <stdarg.h>
+#include <string.h>
+#include <errno.h>
+#include <limits.h>
+#include <sys/param.h>
+#include <netinet/in.h>
+#include <sys/types.h>
+#include <dirent.h>
+
+#ifdef __GNUC__
+#define NORETURN __attribute__((__noreturn__))
+#else
+#define NORETURN
+#ifndef __attribute__
+#define __attribute__(x)
+#endif
+#endif
+
+/* General helper functions */
+extern void usage(const char *err) NORETURN;
+extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
+extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
+
+#ifdef NO_MMAP
+
+#ifndef PROT_READ
+#define PROT_READ 1
+#define PROT_WRITE 2
+#define MAP_PRIVATE 1
+#define MAP_FAILED ((void*)-1)
+#endif
+
+#define mmap gitfakemmap
+#define munmap gitfakemunmap
+extern void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);
+extern int gitfakemunmap(void *start, size_t length);
+
+#else /* NO_MMAP */
+
+#include <sys/mman.h>
+
+#endif /* NO_MMAP */
+
+#ifdef NO_SETENV
+#define setenv gitsetenv
+extern int gitsetenv(const char *, const char *, int);
+#endif
+
+#ifdef NO_STRCASESTR
+#define strcasestr gitstrcasestr
+extern char *gitstrcasestr(const char *haystack, const char *needle);
+#endif
+
+static inline void *xmalloc(size_t size)
+{
+ void *ret = malloc(size);
+ if (!ret)
+ die("Out of memory, malloc failed");
+ return ret;
+}
+
+static inline void *xrealloc(void *ptr, size_t size)
+{
+ void *ret = realloc(ptr, size);
+ if (!ret)
+ die("Out of memory, realloc failed");
+ return ret;
+}
+
+static inline void *xcalloc(size_t nmemb, size_t size)
+{
+ void *ret = calloc(nmemb, size);
+ if (!ret)
+ die("Out of memory, calloc failed");
+ return ret;
+}
+
+/* Sane ctype - no locale, and works with signed chars */
+#undef isspace
+#undef isdigit
+#undef isalpha
+#undef isalnum
+#undef tolower
+#undef toupper
+extern unsigned char sane_ctype[256];
+#define GIT_SPACE 0x01
+#define GIT_DIGIT 0x02
+#define GIT_ALPHA 0x04
+#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
+#define isspace(x) sane_istest(x,GIT_SPACE)
+#define isdigit(x) sane_istest(x,GIT_DIGIT)
+#define isalpha(x) sane_istest(x,GIT_ALPHA)
+#define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
+#define tolower(x) sane_case((unsigned char)(x), 0x20)
+#define toupper(x) sane_case((unsigned char)(x), 0)
+
+static inline int sane_case(int x, int high)
+{
+ if (sane_istest(x, GIT_ALPHA))
+ x = (x & ~0x20) | high;
+ return x;
+}
+
+#endif
diff --git a/git.c b/git.c
index ee5048a..c26cac6 100644
--- a/git.c
+++ b/git.c
@@ -8,15 +8,12 @@
#include <errno.h>
#include <limits.h>
#include <stdarg.h>
+#include "git-compat-util.h"
#ifndef PATH_MAX
# define PATH_MAX 4096
#endif
-#ifdef NO_SETENV
-extern int gitsetenv(const char *, const char *, int);
-#endif
-
static const char git_usage[] =
"Usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ ARGS ]";
@@ -156,10 +153,10 @@ static void list_commands(const char *ex
}
#ifdef __GNUC__
-static void usage(const char *exec_path, const char *fmt, ...)
+static void cmd_usage(const char *exec_path, const char *fmt, ...)
__attribute__((__format__(__printf__, 2, 3), __noreturn__));
#endif
-static void usage(const char *exec_path, const char *fmt, ...)
+static void cmd_usage(const char *exec_path, const char *fmt, ...)
{
if (fmt) {
va_list ap;
@@ -254,12 +251,12 @@ int main(int argc, char **argv, char **e
else if (!strcmp(arg, "help"))
show_help = 1;
else if (!show_help)
- usage(NULL, NULL);
+ cmd_usage(NULL, NULL);
}
if (i >= argc || show_help) {
if (i >= argc)
- usage(exec_path, NULL);
+ cmd_usage(exec_path, NULL);
show_man_page(argv[i]);
}
@@ -297,7 +294,7 @@ int main(int argc, char **argv, char **e
execve(git_command, &argv[i], envp);
if (errno == ENOENT)
- usage(exec_path, "'%s' is not a git-command", argv[i]);
+ cmd_usage(exec_path, "'%s' is not a git-command", argv[i]);
fprintf(stderr, "Failed to run command '%s': %s\n",
git_command, strerror(errno));
diff --git a/mailinfo.c b/mailinfo.c
index 890e348..3b97a89 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -10,10 +10,6 @@
#include <iconv.h>
#include "cache.h"
-#ifdef NO_STRCASESTR
-extern char *gitstrcasestr(const char *haystack, const char *needle);
-#endif
-
static FILE *cmitmsg, *patchfile;
static int keep_subject = 0;
diff --git a/usage.c b/usage.c
index dfa87fe..1fa924c 100644
--- a/usage.c
+++ b/usage.c
@@ -3,7 +3,7 @@
*
* Copyright (C) Linus Torvalds, 2005
*/
-#include "cache.h"
+#include "git-compat-util.h"
static void report(const char *prefix, const char *err, va_list params)
{
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] config.c: remove unnecessary header in minimum configuration file.
From: Johannes Schindelin @ 2005-12-05 20:25 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4394255D.1030009@op5.se>
Hi,
On Mon, 5 Dec 2005, Andreas Ericsson wrote:
> Junio C Hamano wrote:
> > Junio C Hamano <junkio@cox.net> writes:
> >
> >
> > > It is just silly to start the file called "config" with a
> > > comment that says "This is the config file."
> >
> >
> > Any likes or dislikes?
> >
>
> I believe we all agree in silent consensus.
I don't really care, since I know very well that it is a config file...
However, you should also remove the header which is generated in init-db.c
when it is determined that the file system does not respect the executable
flag.
Ciao,
Dscho
^ permalink raw reply
* Weirdness with port-update hook and local push
From: Daniel Barkalow @ 2005-12-05 20:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
I have the following post-update hook:
-----
#!/bin/sh
unset GIT_DIR
cd /home/barkalow/auto-working/web
if ! git pull /home/barkalow/git/web.git/
then
exit 1
fi
make
-----
>From that "git pull", I'm getting:
/home/barkalow/bin/git-pull: line 108: 30608 Broken pipe git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
It works fine when pushing over ssh, and when I just run the hook
directly. (It does a fast forward merge without any trouble.) Any ideas on
what's confusing it?
-Daniel
*This .sig left intentionally blank*
^ 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