* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Petr Baudis @ 2005-07-22 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Catalin Marinas, Bryan larsen, git
In-Reply-To: <7vr7dqpmm4.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Jul 22, 2005 at 11:16:51PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Wonderful start.
>
> Later on, Porcelains could agree on what @TOKEN@ are generally
> available, and even start using a common script to pre-fill the
> templates, like:
>
> $ git-fill-template-script <template> <output-file> var=val var=val...
>
> In your example, I see AUTHOR_NAME, AUTHOR_EMAIL, and
> AUTHOR_DATE (I'd use GIT_AUTHOR_NAME etc to match existing
> environment variables, though) would be something that are
> probably common across Porcelains, and the Porcelain would not
> even have to bother passing them as the command argument to
> fill-template.
Good idea. More interesting exercise would be to make a script which
extracts the values back after the user had a chance to touch it.
> About FILELIST, the default would be to do "git-diff-cache --name-only
> HEAD", but if a Porcelain keeps track of "modified" files differently
> it can be overridden by passing FILELIST as an explicit parameter.
Cogito shows '[NMD] filename' in place of @FILELIST@.
This brings me to another subject, M and N are pretty hard to
distinguish visually without close inspection of the output. What about
switching to use A instead of N everywhere?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH 1/2] GIT: Try all addresses for given remote name
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-07-22 21:26 UTC (permalink / raw)
To: pasky; +Cc: git, yoshfuji
In-Reply-To: <20050722210913.GH11916@pasky.ji.cz>
In article <20050722210913.GH11916@pasky.ji.cz> (at Fri, 22 Jul 2005 23:09:13 +0200), Petr Baudis <pasky@suse.cz> says:
> > -}
> > +#define STR_(s) # s
> > +#define STR(s) STR_(s)
>
> Uh-huh? Why two macros? Well, why any macros at all?
>
:
> > + char *colon, *end;
> > + char *port = STR(DEFAULT_GIT_PORT);
> > + struct addrinfo hints, *ai0, *ai;
The macro is used here.
This is trick.
After preprocess,
/* --- cut here --- */
#define TEST 12345
#define STR_(s) # s
#define STR(s) STR_(s)
test(STR(TEST));
test(STR_(TEST));
test(# TEST);
/* --- cut here --- */
becomes
test("12345");
test("TEST");
test(# 12345);
> > if (sockfd < 0)
> > die("unable to create socket (%s)", strerror(errno));
> > - if (connect(sockfd, (void *)&addr, sizeof(addr)) < 0)
> > - die("unable to connect (%s)", strerror(errno));
:
> You are saying that you were unable to create socket while you just were
> unable to connect. Not any biggie, but it saves the user the trouble of
> one strace after being confused by an error message. :-)
In fact, I don't think it is really worng, because it says that
it could not create (connected) socket or endpoint of connection.
Anyway, I agree that it would be confusing.
Better ideas / wordings?
--yoshfuji
^ permalink raw reply
* Re: [PATCH 2/2] GIT: Listen on IPv6 as well, if available.
From: Petr Baudis @ 2005-07-22 21:21 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: git, yoshfuji
In-Reply-To: <20050721.091049.46807257.yoshfuji@linux-ipv6.org>
Dear diary, on Thu, Jul 21, 2005 at 03:10:49PM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <yoshfuji@linux-ipv6.org> told me that...
> Hello.
Hello from an IPv6 fan,
> Listen on IPv6 as well, if available.
>
> Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
>
> diff --git a/daemon.c b/daemon.c
> --- a/daemon.c
> +++ b/daemon.c
> @@ -219,37 +219,102 @@ static void child_handler(int signo)
>
> static int serve(int port)
> {
..snip..
this whole getaddrinfo() magic looks horribly complicated. What's wrong
on just adding a similar code (or factoring it out to a function) for
IPv6 as there is for IPv4, just s/INET/INET6/?
> for (;;) {
> - struct sockaddr_in in;
> - socklen_t addrlen = sizeof(in);
> - int incoming = accept(sockfd, (void *)&in, &addrlen);
> -
> - if (incoming < 0) {
> - switch (errno) {
> - case EAGAIN:
> - case EINTR:
> - case ECONNABORTED:
> - continue;
> - default:
> - die("accept returned %s", strerror(errno));
> + struct sockaddr_storage ss;
> + socklen_t sslen = sizeof(ss);
Perhaps move those to the most inner block. (All right, I'm nitpicking
too much again, sorry.)
> +
> + int i;
> + fds = fds_init;
> +
> + if (select(maxfd + 1, &fds, NULL, NULL, NULL) == -1) {
> + /* warning? */
Certainly a warning and at least sleep(1) to avoid cpuburn-like
behaviour in case of anything going wrong.
> + continue;
> + }
> +
> + for (i = 0; i < socknum; i++) {
> + int sockfd = socklist[i];
> +
> + if (FD_ISSET(sockfd, &fds)) {
> + int incoming = accept(sockfd, (struct sockaddr *)&ss, &sslen);
> + if (incoming < 0) {
> + switch (errno) {
> + case EAGAIN:
> + case EINTR:
> + case ECONNABORTED:
> + continue;
> + default:
> + die("accept returned %s", strerror(errno));
> + }
> + }
> + handle(incoming, (struct sockaddr *)&ss, sslen);
> }
> }
> - handle(incoming, &in, addrlen);
> }
> }
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH 0/2] apply.c: a fix and an enhancement
From: Junio C Hamano @ 2005-07-22 21:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: A Large Angry SCM, Ryan Anderson, git
In-Reply-To: <Pine.LNX.4.58.0507221340450.6074@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Just teach "parse_commit()" to look at a ".git/fake_parents" file, and
> insert fake extra parents for commits that way - you can graft any tree on
> top of any other tree that way, and it's probably a nice idea for testing
> things out.
Nicely put, thanks. That was exactly what I meant by
"grafting".
And the file would obviously be per-project, so according to
Pasky's suggestion that would be ".gitinfo/fake_parents" ;-).
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Junio C Hamano @ 2005-07-22 21:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: Catalin Marinas, Bryan larsen, git
In-Reply-To: <20050722204120.GD11916@pasky.ji.cz>
Wonderful start.
Later on, Porcelains could agree on what @TOKEN@ are generally
available, and even start using a common script to pre-fill the
templates, like:
$ git-fill-template-script <template> <output-file> var=val var=val...
In your example, I see AUTHOR_NAME, AUTHOR_EMAIL, and
AUTHOR_DATE (I'd use GIT_AUTHOR_NAME etc to match existing
environment variables, though) would be something that are
probably common across Porcelains, and the Porcelain would not
even have to bother passing them as the command argument to
fill-template. About FILELIST, the default would be to do
"git-diff-cache --name-only HEAD", but if a Porcelain keeps
track of "modified" files differently it can be overridden by
passing FILELIST as an explicit parameter.
^ permalink raw reply
* Re: [PATCH 1/2] GIT: Try all addresses for given remote name
From: Petr Baudis @ 2005-07-22 21:09 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: git
In-Reply-To: <20050721.091036.01119516.yoshfuji@linux-ipv6.org>
Dear diary, on Thu, Jul 21, 2005 at 03:10:36PM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <yoshfuji@linux-ipv6.org> told me that...
> Hello.
Hello,
> Try all addresses for given remote name until it succeeds.
> Also supports IPv6.
>
> Signed-of-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
>
> diff --git a/connect.c b/connect.c
> --- a/connect.c
> +++ b/connect.c
> @@ -96,42 +96,57 @@ static enum protocol get_protocol(const
> die("I don't handle protocol '%s'", name);
> }
>
> -static void lookup_host(const char *host, struct sockaddr *in)
> -{
> - struct addrinfo *res;
> - int ret;
> -
> - ret = getaddrinfo(host, NULL, NULL, &res);
> - if (ret)
> - die("Unable to look up %s (%s)", host, gai_strerror(ret));
> - *in = *res->ai_addr;
> - freeaddrinfo(res);
> -}
> +#define STR_(s) # s
> +#define STR(s) STR_(s)
Uh-huh? Why two macros? Well, why any macros at all?
> static int git_tcp_connect(int fd[2], const char *prog, char *host, char *path)
> {
> - struct sockaddr addr;
> - int port = DEFAULT_GIT_PORT, sockfd;
> - char *colon;
> -
> - colon = strchr(host, ':');
> - if (colon) {
> - char *end;
> - unsigned long n = strtoul(colon+1, &end, 0);
> - if (colon[1] && !*end) {
> - *colon = 0;
> - port = n;
> + int sockfd = -1;
> + char *colon, *end;
> + char *port = STR(DEFAULT_GIT_PORT);
> + struct addrinfo hints, *ai0, *ai;
> + int gai;
> +
> + if (host[0] == '[') {
> + end = strchr(host + 1, ']');
> + if (end) {
> + *end = 0;
> + end++;
> + host++;
> + } else
> + end = host;
> + } else
> + end = host;
> + colon = strchr(end, ':');
> +
> + if (colon)
> + port = colon + 1;
> +
> + memset(&hints, 0, sizeof(hints));
> + hints.ai_socktype = SOCK_STREAM;
> + hints.ai_protocol = IPPROTO_TCP;
> +
> + gai = getaddrinfo(host, port, &hints, &ai);
> + if (gai)
> + die("Unable to look up %s (%s)", host, gai_strerror(gai));
> +
> + for (ai0 = ai; ai; ai = ai->ai_next) {
> + sockfd = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
> + if (sockfd < 0)
> + continue;
> + if (connect(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
> + close(sockfd);
> + sockfd = -1;
> + continue;
> }
> + break;
> }
>
> - lookup_host(host, &addr);
> - ((struct sockaddr_in *)&addr)->sin_port = htons(port);
> + freeaddrinfo(ai0);
>
> - sockfd = socket(PF_INET, SOCK_STREAM, IPPROTO_IP);
> if (sockfd < 0)
> die("unable to create socket (%s)", strerror(errno));
> - if (connect(sockfd, (void *)&addr, sizeof(addr)) < 0)
> - die("unable to connect (%s)", strerror(errno));
> +
> fd[0] = sockfd;
> fd[1] = sockfd;
> packet_write(sockfd, "%s %s\n", prog, path);
You are saying that you were unable to create socket while you just were
unable to connect. Not any biggie, but it saves the user the trouble of
one strace after being confused by an error message. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: Should cg-mkpatch output be usable with cg-patch?
From: Petr Baudis @ 2005-07-22 21:03 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20050720234904.B3ED735267C@atlas.denx.de>
Dear diary, on Thu, Jul 21, 2005 at 01:49:04AM CEST, I got a letter
where Wolfgang Denk <wd@denx.de> told me that...
> I wander what I should do with "cg-mkpatch" generated output; I had
> the impression that this should be usable with "cg-patch", but these
> are incompatible with each other.
They certainly aren't.
> Forexample. if a commit contains permission changes, my generated
> patch may look like this:
>
> ...
> diff --git a/MAKEALL b/MAKEALL
> old mode 100644
> new mode 100755
> diff --git a/mkconfig b/mkconfig
> old mode 100644
> new mode 100755
> diff --git a/tools/img2brec.sh b/tools/img2brec.sh
> old mode 100644
> new mode 100755
> ...
>
> If I feed this into "cg-patch", I get:
>
> patch: **** Only garbage was found in the patch input.
And did the changes apply? :-)
The message is surely confusing, but appeared to be rather corner-casy
and after I imagined the required complexity of filtering this, I
decided to spend my time on something more useful for the time being. :)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: Should cg-mkpatch output be usable with cg-patch?
From: Petr Baudis @ 2005-07-22 21:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wolfgang Denk, git
In-Reply-To: <7vackgerpe.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jul 21, 2005 at 05:57:49AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> I only briefly looked at cg-patch, but I suspect that it can
> lose 90% lines of its code by just using "git-apply --index".
Can git-apply already deal with fuzzy patches?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Catalin Marinas @ 2005-07-22 21:00 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Junio C Hamano, Bryan larsen, git
In-Reply-To: <20050722192424.GB8556@mars.ravnborg.org>
On Fri, 2005-07-22 at 19:24 +0000, Sam Ravnborg wrote:
> > I would use a neutral commit template, only that it should have a
> > neutral prefix as well for the lines to be removed (neither STG nor CG
> > but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.
>
> How about $GIT_DIR/commit-template-`basename $EDITOR`
> Then we could have different templates for vim, emacs, kade etc.
I'm not sure this is worth the hassle since a person usually sticks with
one editor, I don't see why one would use different $EDITOR variables
with the same project.
--
Catalin
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Petr Baudis @ 2005-07-22 20:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Catalin Marinas, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <7vy87yr2xh.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Jul 22, 2005 at 10:39:06PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Porcelains need to agree on what is placed where and used in
> what way.
Yes, I always try to make things as Cogito-unspecific as possible.
> - Per user. A user may want to use different environment
> settings for different projects [*4*].
>
> - Per repository (or work tree). A user may have more than
> one work tree for the same project, and want to use
> different "preference" items per tree.
I wouldn't distinct between those two. You as a user can copy things
around when you clone the repositories (if you ever do so), or the
Porcelain can do it, but having global per-user _combined with
per-project settings sounds nightmarish. After all, how do you identify
a project? What if projects merge? I wouldn't open this can of worms.
Obviously, there have to be just per-user settings (independent of
"project").
> About the "where" part, one proposal I have off the top of my
> head is something like this:
>
> - Have a directory at the root of the tree, "_git" (I do not
> care about the name at this moment. The point being it can
> be revision controlled as part of the project and propagate
> to other repositories), to store per-project configuration.
Fine, but I would probably prefer having it hidden. .gitinfo?
> - Use $GIT_DIR/conf/ as a convention to store per repository
> configuration files. This does not propagate with
> pulls/pushes/merges across repositories.
That's fine by me. I'd prefer the hooks staying in $GIT_DIR/hooks/.
> - Use $HOME/.gitrc (could be a directory or a file in .ini
> style like StGIT uses -- again, I do not care about the
> details at this moment) to store per-user configuration.
As long as I can sanely parse it in shell... ;-)
> Which configuration is read first, what can be overridden, and
> if the configuration is cumulative would be specific to each
> preference item, I suspect. Some project may not want a user to
> override the pre-commit hooks, for a bad example. But normally
> the per-repository one would take precedence over per-user one
> which in turn would take precedence over per-project one.
What about just running all the hooks in the order you specified?
> [Footnotes]
>
> *1* Technically this does not involve the core at all, but the
> core people can act as objective, Porcelain-neutral referees.
> They'll need to know the outcome of the discussion anyway, since
> they are the ones that end up maintaining the Porcelain-neutral
> tutorial document.
>
> *2* Unless we are talking about the kind that shows and lets you
> edit the diff to be committed, which somebody else's Porcelain
> may support, that is.
FWIW, I'm planning something like this in cg-commit (when called
explicitly with -d) in short-term future.
> *3* .gitignore in the cwd is used in Cogito, if I am not
> mistaken.
Yes. There were several discussions about this in the past, with no
clear outcome, IIRC. I would prefer:
~/.git/ignore per-user
/.git/ignore per-repository
.gitignore per-directory (cummulative with parent directories)
Note that I also want to make use of some special characters in this
file. In particular /^# and /^!, to make it at least as powerful as CVS'
ignore.
> *4* E.g. I would commit for GIT project with junkio@cox.net
> while using junio@twinsun.com for my day-job projects.
.git/author in current Cogito (.git/conf/author or something in the
Brave New World ;-).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH 0/2] apply.c: a fix and an enhancement
From: Linus Torvalds @ 2005-07-22 20:43 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, Ryan Anderson, git
In-Reply-To: <42E1571B.8070108@gmail.com>
On Fri, 22 Jul 2005, A Large Angry SCM wrote:
>
> To do it without the history rewrite, create an alternate_history
> directory under .git with it's own objects tree. And populate that
> object tree with "alternative" content for the objects in the normal
> trees. Then teach the things the lookup/read objects to look there first
> and to _not_ care about invalid SHAs. Of course, if you do this, you
> will never be able to trust your repository.
You can do it much more nicely if you want.
Just teach "parse_commit()" to look at a ".git/fake_parents" file, and
insert fake extra parents for commits that way - you can graft any tree on
top of any other tree that way, and it's probably a nice idea for testing
things out.
Linus
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Petr Baudis @ 2005-07-22 20:41 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Junio C Hamano, Bryan larsen, git
In-Reply-To: <tnx1x5ryvn2.fsf@arm.com>
Dear diary, on Fri, Jul 22, 2005 at 12:37:05PM CEST, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> told me that...
> > Cogito seems to use $GIT_DIR/commit-template for that purpose.
> > Can't users put that "vim:" hint there, and if StGIT does not
> > use a commit template, patch it to use the same file as Cogito
> > does?
>
> I would use a neutral commit template, only that it should have a
> neutral prefix as well for the lines to be removed (neither STG nor CG
> but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.
This unfortunately isn't that simple, since this file substitutes only
the
CG: -----------------------------------------------------------------------
CG: Lines beginning with the CG: prefix are removed automatically.
snippet of the file. The trouble is, Cogito autogenerates most of the
rest of it. Would the acceptable solution be that I would have
@CG_FILELIST@-style placeholders there, and any tool processing the
file would simply drop lines containing @ directives it does not
understand? (@@ is escaped @)
I have nothing against changing the prefix to GIT:.
Then, Cogito's default commit-template would look like
GIT: -----------------------------------------------------------------------
GIT: Lines beginning with the GIT: prefix are removed automatically.
GIT:
GIT: Author: @AUTHOR_NAME@
GIT: Email: @AUTHOR_EMAIL@
GIT: Date: @AUTHOR_DATE@
GIT:@CG_SHOWFILES@@CG_NOMERGE@
GIT:@CG_SHOWFILES@@CG_NOMERGE@ By deleting lines beginning with GIT:F, the associated file
GIT:@CG_SHOWFILES@@CG_NOMERGE@ will be removed from the commit list.
GIT:@CG_SHOWFILES@
GIT:@CG_SHOWFILES@ Modified files:
GIT:@CG_SHOWFILES@F @FILELIST@
GIT: -----------------------------------------------------------------------
GIT: vim: textwidth=75
(where CG_SHOWFILES is defined only when the list of the files is to be
shown and CG_NOMERGE only when there is no merge going on).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Junio C Hamano @ 2005-07-22 20:39 UTC (permalink / raw)
To: Catalin Marinas, Petr Baudis, Linus Torvalds
Cc: git, Bryan larsen, Sam Ravnborg
In-Reply-To: <20050722192424.GB8556@mars.ravnborg.org>
Sam Ravnborg <sam@ravnborg.org> writes:
>> I would use a neutral commit template, only that it should have a
>> neutral prefix as well for the lines to be removed (neither STG nor CG
>> but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.
>
> How about $GIT_DIR/commit-template-`basename $EDITOR`
> Then we could have different templates for vim, emacs, kade etc.
This brings up a point I have been wanting to see discussed,
involving the core people and the Porcelain people [*1*].
I would like to see Porcelains stay compatible when the do not
have to differ. The commit template [*2*] is one example of
such. Another example is the "dontdiff/ignore" file Pasky
talked about in a recent commit log in his Cogito tree [*3*].
Porcelains need to agree on what is placed where and used in
what way.
First, I will talk about the "what" part. I can see there are
various "preference" items we may want to use:
- commit template (to enforce a certain style)
- standard "dontdiff/ignore" file.
- pre-commit hook (to enforce a certain tests to pass)
- post-commit-hook (sending commit-notification perhaps).
- environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and
such).
There may be others. Many of them would have different origin:
- Per project. A project may want to enforce pre-commit hook
for all participants;
- Per user. A user may want to use different environment
settings for different projects [*4*].
- Per repository (or work tree). A user may have more than
one work tree for the same project, and want to use
different "preference" items per tree.
Personally, given the nature of GIT being a distributed system,
I do not think something like /etc/git.conf (which suggests "per
system" configuration) makes much sense; except working around a
mailhost name configuration, perhaps.
About the "where" part, one proposal I have off the top of my
head is something like this:
- Have a directory at the root of the tree, "_git" (I do not
care about the name at this moment. The point being it can
be revision controlled as part of the project and propagate
to other repositories), to store per-project configuration.
- Use $GIT_DIR/conf/ as a convention to store per repository
configuration files. This does not propagate with
pulls/pushes/merges across repositories.
- Use $HOME/.gitrc (could be a directory or a file in .ini
style like StGIT uses -- again, I do not care about the
details at this moment) to store per-user configuration.
Which configuration is read first, what can be overridden, and
if the configuration is cumulative would be specific to each
preference item, I suspect. Some project may not want a user to
override the pre-commit hooks, for a bad example. But normally
the per-repository one would take precedence over per-user one
which in turn would take precedence over per-project one.
[Footnotes]
*1* Technically this does not involve the core at all, but the
core people can act as objective, Porcelain-neutral referees.
They'll need to know the outcome of the discussion anyway, since
they are the ones that end up maintaining the Porcelain-neutral
tutorial document.
*2* Unless we are talking about the kind that shows and lets you
edit the diff to be committed, which somebody else's Porcelain
may support, that is.
*3* .gitignore in the cwd is used in Cogito, if I am not
mistaken.
*4* E.g. I would commit for GIT project with junkio@cox.net
while using junio@twinsun.com for my day-job projects.
^ permalink raw reply
* Re: [PATCH 0/2] apply.c: a fix and an enhancement
From: A Large Angry SCM @ 2005-07-22 20:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git, Linus Torvalds
In-Reply-To: <7vsly6vd2b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
>>On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
>>>Now if we had a mechanism to graft a later history which starts
>>>at 2.6.12-rc2 on top of this earlier history leading up to
>>>it,... ;-)
>>We do - it's not even very hard, we just end up with 2 commits for every
>>change/merge that's unique to git, until we get to the current head:
>
> Aren't you essentially rewriting the history after 2.6.12-rc2?.
> I suspect that would invalidate the current linux-2.6 history
> people have been basing their work on since 2.6.12-rc2, which is
> unacceptable. That is not what I meant by "grafting".
>
> What I meant was to give a hint to the core that says "this
> 2.6.12-rc2 commit in the current linux-2.6.git tree is recorded
> as not having a parent, but please consider it the same as this
> other 2.6.12-rc2 commit in the 2.4.0->2.6.12-rc2 history when
> traversing the commit ancestry chain".
>
> If git-rev-list is taught about that, then you will see "git
> log" going across 2.6.12-rc2. If git-merge-base is taught about
> that, it will be able to find a merge base to merge a line of
> development that is forked from say 2.6.11 to the current tip of
> linux-2.6 tree.
I think that "rewriting history" in this case may be the better option
in _this_ case. But only because the tools are new and the users are
understanding. :-)
To do it without the history rewrite, create an alternate_history
directory under .git with it's own objects tree. And populate that
object tree with "alternative" content for the objects in the normal
trees. Then teach the things the lookup/read objects to look there first
and to _not_ care about invalid SHAs. Of course, if you do this, you
will never be able to trust your repository.
^ permalink raw reply
* Re: [PATCH 0/2] apply.c: a fix and an enhancement
From: Ryan Anderson @ 2005-07-22 20:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git, Linus Torvalds
In-Reply-To: <7vsly6vd2b.fsf@assigned-by-dhcp.cox.net>
On Fri, Jul 22, 2005 at 12:46:36PM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
> >> Now if we had a mechanism to graft a later history which starts
> >> at 2.6.12-rc2 on top of this earlier history leading up to
> >> it,... ;-)
> >
> > We do - it's not even very hard, we just end up with 2 commits for every
> > change/merge that's unique to git, until we get to the current head:
>
> Aren't you essentially rewriting the history after 2.6.12-rc2?.
> I suspect that would invalidate the current linux-2.6 history
> people have been basing their work on since 2.6.12-rc2, which is
> unacceptable. That is not what I meant by "grafting".
hmm, I may have been a bit too terse.
Each new commit would have at least two parents:
The commit from the current, 2.6.12-rc2 based tree.
The commits generated by this process that have, as one of their
children, the parents of the current commit from the 2.6.12-rc2
based tree.
That will mean all the merge tools will find a common base, and, at
worst, cycle through an extra commit that should add *no* extra issues.
Let me see if I can draw a picture of 5 or 6 commit tree:
Today:
A0->->-A1->->-A2
\ /
\--B1->->-/
Stiched together:
A0->->-A1->->-A2
|\ | / |
| \--B1->->-/ |
| | | |
O-M0->->-M1->->->M2
\ | /
\--N1->->->/
O being the old tree we're grafting on.
So, M0 would have parents of A0 and O, and the commit metadata from A0
N1 would have parents of M0 and B1, and the commit metadata from B1
M1 would have parents of A1 and M0, and the commit metadata from A1
M2 would have parents of A2, M1, and N1 and the commit metadata from A2
Does that help?
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH 0/2] apply.c: a fix and an enhancement
From: Junio C Hamano @ 2005-07-22 19:46 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git, Linus Torvalds
In-Reply-To: <20050722181800.GU20369@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
>> Now if we had a mechanism to graft a later history which starts
>> at 2.6.12-rc2 on top of this earlier history leading up to
>> it,... ;-)
>
> We do - it's not even very hard, we just end up with 2 commits for every
> change/merge that's unique to git, until we get to the current head:
Aren't you essentially rewriting the history after 2.6.12-rc2?.
I suspect that would invalidate the current linux-2.6 history
people have been basing their work on since 2.6.12-rc2, which is
unacceptable. That is not what I meant by "grafting".
What I meant was to give a hint to the core that says "this
2.6.12-rc2 commit in the current linux-2.6.git tree is recorded
as not having a parent, but please consider it the same as this
other 2.6.12-rc2 commit in the 2.4.0->2.6.12-rc2 history when
traversing the commit ancestry chain".
If git-rev-list is taught about that, then you will see "git
log" going across 2.6.12-rc2. If git-merge-base is taught about
that, it will be able to find a merge base to merge a line of
development that is forked from say 2.6.11 to the current tip of
linux-2.6 tree.
^ permalink raw reply
* qgit-0.8
From: Marco Costalba @ 2005-07-22 18:37 UTC (permalink / raw)
To: git; +Cc: berkus
Hi,
here is qgit-0.8:
http://prdownloads.sourceforge.net/qgit/qgit-0.8.tar.bz2?download
This release shows a big GUI rewrite with added menus,
buttons, help, settings page, etc.
Some new features:
- Possibility to view diffs against current checked-out tree, i.e
GUI interface to git-diff-cache.
Defaut is off, change it from menu->settings.
- GUI interface to git-format-patch-script with options in settings page
- Right click on an empty lane shows childs and parent in a pop-up
with 'jump to' on select
- Make install/uninstall support (thanks to Stanislav Karchebny)
- Separation of groups of files by two empty lines in case of merges
See changelog for a complete list of changes
I have updated some screens too:
https://sourceforge.net/project/screenshots.php?group_id=139897
Marco
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: [PATCH 0/2] apply.c: a fix and an enhancement
From: Ryan Anderson @ 2005-07-22 18:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vzmsewzik.fsf@assigned-by-dhcp.cox.net>
On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
> Now if we had a mechanism to graft a later history which starts
> at 2.6.12-rc2 on top of this earlier history leading up to
> it,... ;-)
We do - it's not even very hard, we just end up with 2 commits for every
change/merge that's unique to git, until we get to the current head:
Take the last imported commit - we'll call this branch A.
Take the 2.6.12-rc2 initial commit, we'll call this branch B.
This algorithm should stitch things together:
For each commit on branch B
Copy all commit metadata (author,etc)
Add a new parent Ai.
Take the trees from commit B.
Write a new commit, Ai+1
When we get to HEAD, we replace HEAD with this last commit we have
created, and we now have a nice, parallel commit tree that stitches
everything back together.
Working from the initial import up, you'll need to work in parallel and
handle create some mappings of "old commit" to "new commit" to create
all the merges with the new commit ids, but I think this should be
pretty straightforward to do.
If this is all integrated, I'd suggest unpacking everything but the
packs that are currently in the main tree, and repacking one very big
pack to get the maximum posible benefit from the deltas.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Sam Ravnborg @ 2005-07-22 19:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Junio C Hamano, Bryan larsen, git
In-Reply-To: <tnx1x5ryvn2.fsf@arm.com>
>
> I would use a neutral commit template, only that it should have a
> neutral prefix as well for the lines to be removed (neither STG nor CG
> but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.
How about $GIT_DIR/commit-template-`basename $EDITOR`
Then we could have different templates for vim, emacs, kade etc.
Sam
^ permalink raw reply
* [PATCH 2/2] apply.c: --exclude=fnmatch-pattern option.
From: Junio C Hamano @ 2005-07-22 16:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Adds --exclude=pattern option to the "git-apply" command. This
was useful while reimporting the BKCVS patchset dump of the
Linux kernel, starting at 2.4.0 and ending at 2.6.12-rc2 Ingo
announced some time ago to exclude BitKeeper directory.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
apply.c | 45 ++++++++++++++++++++++++++++++++++++++-------
1 files changed, 38 insertions(+), 7 deletions(-)
3206526a0af9403fc6184dc17879206b9216924f
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -13,7 +13,7 @@
* uses the working tree as a "branch" for a 3-way merge.
*/
#include <ctype.h>
-
+#include <fnmatch.h>
#include "cache.h"
// We default to the merge behaviour, since that's what most people would
@@ -1345,9 +1345,9 @@ static void write_out_one_result(struct
create_file(patch);
}
-static void write_out_results(struct patch *list)
+static void write_out_results(struct patch *list, int skipped_patch)
{
- if (!list)
+ if (!list && !skipped_patch)
die("No changes");
while (list) {
@@ -1358,12 +1358,30 @@ static void write_out_results(struct pat
static struct cache_file cache_file;
+static struct excludes {
+ struct excludes *next;
+ const char *path;
+} *excludes;
+
+static int use_patch(struct patch *p)
+{
+ const char *pathname = p->new_name ? : p->old_name;
+ struct excludes *x = excludes;
+ while (x) {
+ if (fnmatch(x->path, pathname, 0) == 0)
+ return 0;
+ x = x->next;
+ }
+ return 1;
+}
+
static int apply_patch(int fd)
{
int newfd;
unsigned long offset, size;
char *buffer = read_patch_file(fd, &size);
struct patch *list = NULL, **listp = &list;
+ int skipped_patch = 0;
if (!buffer)
return -1;
@@ -1377,9 +1395,15 @@ static int apply_patch(int fd)
nr = parse_chunk(buffer + offset, size, patch);
if (nr < 0)
break;
- patch_stats(patch);
- *listp = patch;
- listp = &patch->next;
+ if (use_patch(patch)) {
+ patch_stats(patch);
+ *listp = patch;
+ listp = &patch->next;
+ } else {
+ /* perhaps free it a bit better? */
+ free(patch);
+ skipped_patch++;
+ }
offset += nr;
size -= nr;
}
@@ -1397,7 +1421,7 @@ static int apply_patch(int fd)
exit(1);
if (apply)
- write_out_results(list);
+ write_out_results(list, skipped_patch);
if (write_index) {
if (write_cache(newfd, active_cache, active_nr) ||
@@ -1432,6 +1456,13 @@ int main(int argc, char **argv)
read_stdin = 0;
continue;
}
+ if (!strncmp(arg, "--exclude=", 10)) {
+ struct excludes *x = xmalloc(sizeof(*x));
+ x->path = arg + 10;
+ x->next = excludes;
+ excludes = x;
+ continue;
+ }
/* NEEDSWORK: this does not do anything at this moment. */
if (!strcmp(arg, "--no-merge")) {
merge_patch = 0;
^ permalink raw reply
* [PATCH 1/2] apply.c: handle incomplete lines correctly.
From: Junio C Hamano @ 2005-07-22 16:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
The parsing code had a bug that failed to recognize an
incomplete line at the end of a fragment, and the fragment
application code had a comparison bug to recognize such. Fix
them to handle incomplete lines correctly.
Add a test script for patches with various combinations of
complete and incomplete lines to make sure the fix works.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
apply.c | 9 ++++++++-
t/t4101-apply-nonl.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+), 1 deletions(-)
create mode 100755 t/t4101-apply-nonl.sh
9b378103b8ba89d697cdf368d29a6113929b127a
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -679,6 +679,13 @@ static int parse_fragment(char *line, un
break;
}
}
+ /* If a fragment ends with an incomplete line, we failed to include
+ * it in the above loop because we hit oldlines == newlines == 0
+ * before seeing it.
+ */
+ if (12 < size && !memcmp(line, "\\ No newline", 12))
+ offset += linelen(line, size);
+
patch->lines_added += added;
patch->lines_deleted += deleted;
return offset;
@@ -900,7 +907,7 @@ static int apply_one_fragment(struct buf
* last one (which is the newline, of course).
*/
plen = len-1;
- if (len > size && patch[len] == '\\')
+ if (len < size && patch[len] == '\\')
plen--;
switch (*patch) {
case ' ':
diff --git a/t/t4101-apply-nonl.sh b/t/t4101-apply-nonl.sh
new file mode 100755
--- /dev/null
+++ b/t/t4101-apply-nonl.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+test_description='git-apply should handle files with incomplete lines.
+
+'
+. ./test-lib.sh
+
+# setup
+
+(echo a; echo b) >frotz.0
+(echo a; echo b; echo c) >frotz.1
+(echo a; echo b | tr -d '\012') >frotz.2
+(echo a; echo c; echo b | tr -d '\012') >frotz.3
+
+for i in 0 1 2 3
+do
+ for j in 0 1 2 3
+ do
+ test $i -eq $j && continue
+ diff -u frotz.$i frotz.$j |
+ sed -e '
+ /^---/s|.*|--- a/frotz|
+ /^+++/s|.*|+++ b/frotz|' >diff.$i-$j
+ cat frotz.$i >frotz
+ test_expect_success \
+ "apply diff between $i and $j" \
+ "git-apply <diff.$i-$j && diff frotz.$j frotz"
+ done
+done
^ permalink raw reply
* [PATCH 0/2] apply.c: a fix and an enhancement
From: Junio C Hamano @ 2005-07-22 16:56 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In mid April, Ingo announced availability of his conversion from
CVS to a flat patchset format:
From: Ingo Molnar <mingo@elte.hu>
Subject: full kernel history, in patchset format
Message-ID: <20050416131528.GB19908@elte.hu>
the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a
script that will apply all the patches in order and will create a
pristine 2.6.12-rc2 tree.
...
note: i kept the patches the cvsps utility generated as-is, to have a
verifiable base to work on. There were a very small amount of deltas
missed (about a dozen), probably resulting from CVS related errors,
these are included in the diff-CVS-to-real patch. Also, the patch format
I was futzing with the script in Ingo's tarball, which
originally used "patch". After converting it to use
'git-apply', I had some troubles with applying patches, which
eventually led me to find out and fix a corner case bug ---
git-apply did not handle files with an incomplete line correctly
in some cases.
After I fixed that problem, the script still found some more
errors in the patchset, but after manual inspection it looked to
me that they are problems not on the patch application side, but
on the patch generation side. I only checked 2.4.0, 2.6.9,
2.6.11 and 2.6.12-rc2, but the trees built were byte-to-byte
equivalent, except that the file executable bits, which are
preserved in the patch series.
The patch attached to this message is not for inclusion in the
git source tree. It is the script I used for conversion. You
will need the following patches to apply.c for it to work, which
will be sent separately:
[PATCH 1/2] apply.c: handle incomplete lines correctly.
[PATCH 2/2] apply.c: --exclude=fnmatch-pattern option.
I did this not because I was particularly interested in the
ancient kernel history, but because I wanted to see how well
packs perform. Here are some numbers that may be of interest.
26M pack-000002.pack 18M pack-015360.pack
48M pack-001024.pack 21M pack-016384.pack
22M pack-002048.pack 18M pack-017408.pack
20M pack-003072.pack 19M pack-018432.pack
21M pack-004096.pack 17M pack-019456.pack
24M pack-005120.pack 22M pack-020480.pack
20M pack-006144.pack 20M pack-021504.pack
20M pack-007168.pack 17M pack-022528.pack
24M pack-008192.pack 23M pack-023552.pack
19M pack-009216.pack 16M pack-024576.pack
24M pack-010240.pack 21M pack-025600.pack
20M pack-011264.pack 19M pack-026624.pack
23M pack-012288.pack 18M pack-027648.pack
21M pack-013312.pack 17M pack-028237.pack
18M pack-014336.pack
The script makes a full pack after importing 2.4.0 (which is the
patchset #2), and then makes an incremental every 1024 commits,
so the baseline pack is 26MB and the first incremental up to the
patchset #1024 is 48MB. It averages at around 20MB per 1024
commits. The repository with the full history, repacked into a
single pack, is 203MB (370291 objects).
------------
A script to slurp full 2.4.0->2.6.12-rc2 history.
Create an empty directory, put the "build-git-tree" script in it,
and extract Ingo's CVSPS conversion result, available at:
http://kernel.org/pub/linux/kernel/people/mingo/Linux-2.6-patchset/
in it. Make sure the definition of variable PS matches the name
of the directory you extracted the tarball, and run the script.
Some hours later, you will have linux/ directory whose .git
subdirectory has a GITified full 2.4.0->2.6.12-rc2 history.
Now if we had a mechanism to graft a later history which starts
at 2.6.12-rc2 on top of this earlier history leading up to
it,... ;-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
build-git-tree | 177 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 177 insertions(+), 0 deletions(-)
diff --git a/build-git-tree b/build-git-tree
new file mode 100755
--- /dev/null
+++ b/build-git-tree
@@ -0,0 +1,177 @@
+#!/bin/sh
+
+PS=linux-2.4.0-to-2.6.12-rc2-patchset
+cat build-git-tree >build-git-tree-next
+cat >sayVersion <<\EOF
+default:
+ @echo "v$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)"
+EOF
+
+: >duplicate-tags
+
+: ${END=28237}
+: ${CPP=1024}
+
+sedScript='
+ /^Date: /{
+ s/^Date: \(.*\)/\1/
+ s/'\''/'\''\\'\'''\''/g
+ s/^.*/DATE='\''&'\''/p
+ }
+ /^Author: /{
+ s/^Author: \(.*\)/\1/
+ s/'\''/'\''\\'\'''\''/g
+ s/^.*/AUTHOR='\''&'\''/p
+ }
+ /^Log:$/{
+ n
+ b LOOP
+ }
+ b
+ : LOOP
+ /^BKrev: /{
+ g
+ s/^\n//
+ s/\n$//
+ s/'\''/'\''\\'\'''\''/g
+ s/^.*/LOG='\''&'\''/p
+ q
+ }
+ H
+ n
+ b LOOP
+'
+
+rm -fr errs linux pack && mkdir -p linux/Documentation errs pack || exit
+cp $PS/logo.gif linux/Documentation
+
+cd linux
+git-init-db
+git-ls-files --cached -z |
+xargs -0 -r git-update-cache --add --remove --
+find ?* -type f -print0 | xargs -0 -r git-update-cache --add --
+
+N=1 P=
+while expr $N \<= $END >/dev/null
+do
+ NN=$(printf "%06d" $N)
+ FILE=../$PS/patches/$N.patch
+
+ e=`sed -ne "$sedScript" $FILE` &&
+ eval "$e" &&
+
+ GIT_AUTHOR_NAME="$AUTHOR" &&
+ GIT_AUTHOR_EMAIL="$AUTHOR" &&
+ GIT_COMMITTER_NAME="$AUTHOR" &&
+ GIT_COMMITTER_EMAIL="$AUTHOR" &&
+ GIT_AUTHOR_DATE="+0000 $DATE" &&
+ GIT_COMMITTER_DATE="+0000 $DATE" &&
+
+ export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME \
+ GIT_COMMITTER_EMAIL GIT_AUTHOR_DATE GIT_COMMITTER_DATE &&
+
+ echo "* $NN - $AUTHOR - $DATE" &&
+
+ git-apply --exclude='BitKeeper/*' --index --summary --apply \
+ <$FILE >../errs/$NN.out 2>&1 || {
+ # Special case.
+ patch -E -p1 <$FILE >../errs/$NN.spc 2>&1
+ sed -ne 's|^File \(.*\) is not empty after patch, as expected$|\1|p' \
+ <../errs/$NN.spc |
+ while read path
+ do
+ echo "* expected to be empty: $path"
+ ls -l "$path"
+ rm -f "$path"
+ done >.tmp
+ cat .tmp >>../errs/$NN.spc
+ rm -f .tmp
+
+ # Some patches (like 678) do not have Index line for everything,
+ # so looking for Index: line is not good enough.
+ sed -n -e 's|^--- linux/\([^ ]*\).*|\1|p' \
+ -e 's|^+++ linux/\([^ ]*\).*|\1|p' $FILE |
+ sort -u |
+ xargs -r git-update-cache --add --remove --
+ if test -d BitKeeper
+ then
+ find BitKeeper -type f -print |
+ while read path
+ do
+ echo removing "$path"
+ done | tee -a ../errs/$NN.spc
+ find BitKeeper -type f -print0 |
+ xargs -0 -r git-update-cache --force-remove --
+ rm -fr BitKeeper
+ fi
+ }
+
+ T=`git-write-tree` &&
+ C=$(echo "$LOG" | git-commit-tree $T $P) &&
+ echo $C >.git/HEAD &&
+
+ P="-p $C" || exit
+
+ # Look at the Makefile change and make a tag.
+ git-diff-tree -p $C Makefile |
+ sed -ne '
+ /^[-+]VERSION =/{
+ p
+ q
+ }
+ /^[-+]PATCHLEVEL =/{
+ p
+ q
+ }
+ /^[-+]SUBLEVEL =/{
+ p
+ q
+ }
+ /^[-+]EXTRAVERSION =/{
+ p
+ q
+ }
+ ' >.tmp
+ if test -s .tmp
+ then
+ v=$((sed -ne '/^VERSION/p;/^PATCHLEVEL/p;/^SUBLEVEL/p;/^EXTRAVERSION/p' \
+ Makefile; cat ../sayVersion) | make -f -)
+ if test -f ".git/refs/tags/$v"
+ then
+ echo "* $v (duplicate)"
+ echo "$C $v" >>../duplicate-tags
+ else
+ echo "$C" >".git/refs/tags/$v"
+ echo "* $v"
+ fi
+ fi
+ rm -f .tmp
+
+ # 70a29f4bd97bbb78fac1cc7f87c13fb08d1a12cd == v2.4.0.6
+
+ # Pack
+ if expr \( $N = 2 \) \| \( $N % $CPP = 0 \) >/dev/null
+ then
+ {
+ echo "* packing"
+ du -sh .git/objects &&
+ case "$N" in
+ 2)
+ pack=$(git-rev-list --objects $C | \
+ git-pack-objects ../pack/pack-$NN)
+ ;;
+ *)
+ pack=$(git-rev-list --unpacked --objects $C | \
+ git-pack-objects --incremental ../pack/pack-$NN)
+ ;;
+ esac &&
+ ln ../pack/pack-$NN-$pack.idx ../pack/pack-$NN-$pack.pack \
+ .git/objects/pack/. &&
+ git-prune-packed &&
+ du -sh .git/objects
+ } 2>&1 | tee ../errs/$NN.packlog
+ fi
+ test -f ../errs/$NN.spc || rm -f ../errs/$NN.out
+
+ N=`expr $N + 1`
+done
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Catalin Marinas @ 2005-07-22 10:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bryan larsen, git
In-Reply-To: <7v3bq71rmb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I do not do Porcelain, but wouldn't it be nicer if we had a
> Porcelain neutral "commit log template file" under $GIT_DIR
> somewhere? 'vim: textwidth=75' is completely useless for
> somebody like me (I almost always work inside Emacs).
StGIT uses .git/patchdescr.tmpl as the template, where people can put
the a line like "STG: vim: textwidth=75" which will be automatically
removed. I won't include this patch since it is up to the user to
define whatever setting he/she wants for his editor (I use emacs
myself and add something like "STG: -*- mode: text; -*-" on the first
line)
> Cogito seems to use $GIT_DIR/commit-template for that purpose.
> Can't users put that "vim:" hint there, and if StGIT does not
> use a commit template, patch it to use the same file as Cogito
> does?
I would use a neutral commit template, only that it should have a
neutral prefix as well for the lines to be removed (neither STG nor CG
but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.
--
Catalin
^ permalink raw reply
* [PATCH] Deb packaging needs two more configuration files
From: Ryan Anderson @ 2005-07-22 6:36 UTC (permalink / raw)
To: git, Linus Torvalds
In-Reply-To: <20050722055556.GR20369@mythryan2.michonline.com>
The deb package building needs these two new files to work correctly.
debian/compat sets the rules under which the debhelper scripts (dh_*) operate.
debian/git-core.install tells dh_install what files to install in each package
that is generated. There is only one package being generated, so all files go
into it.
(I missed these in the last patch, mostly because I needed to do this to
find stuff I had missed:
find . -name .git -type d -prune -o -type f -print \
| grep -v -e .tree1 -e .tree2 \
| sed -e "s/^\.\///" \
| sort >.tree1
git-ls-files | grep -v -e .tree1 -e .tree2 \
| sort >.tree2
diff -u .tree1 .tree2
)
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
debian/compat | 1 +
debian/git-core.install | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 debian/compat
create mode 100644 debian/git-core.install
d5ccc10c30f1baa968705aa0c3dfc98e0ade5eaf
diff --git a/debian/compat b/debian/compat
new file mode 100644
--- /dev/null
+++ b/debian/compat
@@ -0,0 +1 @@
+4
diff --git a/debian/git-core.install b/debian/git-core.install
new file mode 100644
--- /dev/null
+++ b/debian/git-core.install
@@ -0,0 +1 @@
+*
^ permalink raw reply
* [PATCH] Deb packages should include the binaries (Try 2 - this time it actually applies)
From: Ryan Anderson @ 2005-07-22 5:55 UTC (permalink / raw)
To: git, Linus Torvalds
In-Reply-To: <20050721061545.GM20369@mythryan2.michonline.com>
The Deb packages were mising a dependency on "build install" from the
binary target - this fixes that, and cleans up some inconsistencies
elsewhere in the rulesets.
Traditionally, Debian packaging uses a file called "build-stamp" (or
"install-stamp", etc) in the main source tree. The initial deb package
support for Git tried to move this "build-stamp" file into the debian/
directory, but some instances were missed. That problem, however, was
incidental - the real fix is the missing dependency mentioned above.
(version 2 of this patch. I missed an early commit in v1 that made the old
patch impossible to apply.)
Signed-off-by: Ryan Anderson <ryan@michonline.com>
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,11 @@
+git-core (0.99-1) unstable; urgency=low
+
+ * Update deb package support to build correctly.
+
+ -- Ryan Anderson <ryan@michonline.com> Thu, 21 Jul 2005 02:03:32 -0400
+
git-core (0.99-0) unstable; urgency=low
-
+
* Initial deb package support
-- Eric Biederman <ebiederm@xmission.com> Tue, 12 Jul 2005 10:57:51 -0600
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Standards-Version: 3.6.1
Package: git-core
Architecture: any
-Depends: ${shlibs:Depends}, shellutils, diff, rsync, rcs
+Depends: ${misc:Depends}, shellutils, diff, rsync, rcs
Description: The git content addressable filesystem
GIT comes in two layers. The bottom layer is merely an extremely fast
and flexible filesystem-based database designed to store directory trees
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -21,8 +21,8 @@ DESTDIR := $(CURDIR)/debian/tmp
DOC_DESTDIR := $(DESTDIR)/usr/share/doc/git-core/
MAN_DESTDIR := $(DESTDIR)/$(MANDIR)
-build: build-stamp
-build-stamp:
+build: debian/build-stamp
+debian/build-stamp:
dh_testdir
$(MAKE) all doc
touch debian/build-stamp
@@ -36,7 +36,7 @@ debian-clean:
clean: debian-clean
$(MAKE) clean
-install: debian/build-stamp
+install: build
dh_testdir
dh_testroot
dh_clean -k
@@ -47,9 +47,9 @@ install: debian/build-stamp
mkdir -p $(DOC_DESTDIR)
find $(DOC) '(' -name '*.txt' -o -name '*.html' ')' -exec install {} $(DOC_DESTDIR) ';'
- dh_install --sourcedir=$(DESTDIR)
+ dh_install --list-missing --sourcedir=$(DESTDIR)
-binary:
+binary: build install
dh_testdir
dh_testroot
dh_installchangelogs
--
Ryan Anderson
sometimes Pug Majere
^ 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