* 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: Petr Baudis @ 2005-07-22 21:37 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: git
In-Reply-To: <20050722.172629.73295196.yoshfuji@linux-ipv6.org>
Dear diary, on Fri, Jul 22, 2005 at 11:26:29PM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <yoshfuji@linux-ipv6.org> told me that...
> 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);
I see, I didn't know about this. Well, I didn't actually use the #
stringificator many times. Perhaps a short comment would be due.
> > > 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.
It uses only two words ("create socket") from that, though. ;-)
> Anyway, I agree that it would be confusing.
> Better ideas / wordings?
if (connect() < 0) sockfd = -2;
...
if (sockfd == -1) die("unable to create socket");
else die("unable to connect")
or I'd prefer the second error message "unable to connect", which is
perhaps more descriptive regarding what effectively happened.
BTW, could the close() on the socket ever fail (read as "modify errno")
here?
--
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 2/2] GIT: Listen on IPv6 as well, if available.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-07-22 21:35 UTC (permalink / raw)
To: pasky; +Cc: git, yoshfuji
In-Reply-To: <20050722212151.GI11916@pasky.ji.cz>
In article <20050722212151.GI11916@pasky.ji.cz> (at Fri, 22 Jul 2005 23:21:51 +0200), Petr Baudis <pasky@suse.cz> says:
> 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/?
Because it is the Good Way To Go; protocol independent programming.
> > - 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.)
>
okay.
> > + 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.
okay...
--yoshfuji
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Catalin Marinas @ 2005-07-22 21:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Petr Baudis, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <7vy87yr2xh.fsf@assigned-by-dhcp.cox.net>
On Fri, 2005-07-22 at 13:39 -0700, Junio C Hamano wrote:
> I would like to see Porcelains stay compatible when the do not
> have to differ. The commit template [*2*] is one example of
> such.
For StGIT it is not a problem to use any commit template with any
prefix. It doesn't generate extra lines.
Would such a template only have 'GIT:' prefixed lines? I usually put
another line like 'Signed-off-by:', for convenience. The problem with
StGIT appears when one wants to re-edit the patch description (stg
refresh -e), in which case the existing description should be merged
with a part of the template (if you want to get the editor setting for
example). It doesn't do this since there is no point in getting another
'Signed...' line in the existing description.
> 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)
OK
> - standard "dontdiff/ignore" file.
StGIT currently uses .git/exclude, since I saw it used by cogito. What
is dontdiff supposed to do? The 'git diff' command only shows the diff
for the files added to the repository.
> - pre-commit hook (to enforce a certain tests to pass)
> - post-commit-hook (sending commit-notification perhaps).
OK
> - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and
> such).
StGIT works the other way around. By default uses the environment, which
can be overridden by the stgitrc file. I could change this easily.
> 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;
As Petr said, it's hard to define a project.
> - 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.
StGIT uses /etc/stgitrc, ~/.stgitrc and .git/stgitrc, the latter
overriding the former.
> 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.
For StGIT it makes sense to get some default settings via /etc/stgitrc.
There are things like a SMTP server and the diff3 command. These are set
when installing the application and can be overridden in your home
or .git directories.
> About the "where" part, one proposal I have off the top of my
> head is something like this:
Before we get to "where", we should define the common settings. I think
that git should define the common settings for its operations and the
other tools should follow them.
Once you get unique settings for an application (like mail templates or
three-way merge commands), it's pretty hard to put them in the same
file. It would even be confusing for users.
> - 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.
That's the thing I didn't like in GNU Arch. You modify the file ignoring
rules for example and the change will be included in the next commit.
You could only get some defaults when cloning a repository, otherwise
once you have different preferences from the repository's maintainer,
you start getting conflicts in the config files.
> - 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.
> - 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.
Again, having Porcelain specific options mixed in the same file might
lead to some confusion among users.
> But normally
> the per-repository one would take precedence over per-user one
> which in turn would take precedence over per-project one.
With a note if specifying what a project is.
> *3* .gitignore in the cwd is used in Cogito, if I am not
> mistaken.
I will to add this to StGIT.
> *4* E.g. I would commit for GIT project with junkio@cox.net
> while using junio@twinsun.com for my day-job projects.
In StGIT this is settable via authorname/authoremail in the stgitrc file
and can be per repository or per user.
--
Catalin
^ permalink raw reply
* Re: [PATCH 0/2] apply.c: a fix and an enhancement
From: Linus Torvalds @ 2005-07-22 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: A Large Angry SCM, Ryan Anderson, git
In-Reply-To: <7vhdempmgg.fsf@assigned-by-dhcp.cox.net>
On Fri, 22 Jul 2005, Junio C Hamano wrote:
>
> And the file would obviously be per-project, so according to
> Pasky's suggestion that would be ".gitinfo/fake_parents" ;-).
I'd _really_ prefer to not have any preferences or other metadata files
under version control within that same project.
If you want to version control them, that's fine, but don't tie the
versioning to the main project itself. You can have a _separate_ git
index, and a separate branch for the preferences and other metadata (but
you can, if you want to, obviously share the .git directory contents and
mix up the objects).
The thing is, different people might want to tie in these things different
ways. For example, one thing this kind of "grafting" is useful for is to
literally graft two different projects together, even if you may actually
want to export them independently (ie you do _not_ want the graftign
itself to be visible when you export it).
Think of something like a collection of projects, each under their own
subdirectory. We could eventually literally make them _look_ like one big
project, with cross-project commits grafted together, but they'd
technically be totally independent (think "git" vs "gitk" - rather than
having a very tight merge like I did, we could have tried to make it be a
more virtual graft instead).
And personal preferences are just that - personal. I do _not_ want to have
the kernel project history have things like "editor preferences" etc in
the revision history - you might want to revision them, but that would be
totally independent of the history of the project itself.
Linus
^ permalink raw reply
* Re: [PATCH 2/2] GIT: Listen on IPv6 as well, if available.
From: Petr Baudis @ 2005-07-22 22:05 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: git
In-Reply-To: <20050722.173517.73563363.yoshfuji@linux-ipv6.org>
Dear diary, on Fri, Jul 22, 2005 at 11:35:17PM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <yoshfuji@linux-ipv6.org> told me that...
> In article <20050722212151.GI11916@pasky.ji.cz> (at Fri, 22 Jul 2005 23:21:51 +0200), Petr Baudis <pasky@suse.cz> says:
> > 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/?
>
> Because it is the Good Way To Go; protocol independent programming.
I can see its merits, and it doesn't look so horrible after a while. ;-)
--
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] Make debian/rules executable, and correct the spelling of rsync in debian/control
From: Petr Baudis @ 2005-07-22 22:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Ryan Anderson
In-Reply-To: <20050720011747.GK20369@mythryan2.michonline.com>
Dear diary, on Wed, Jul 20, 2005 at 03:17:47AM CEST, I got a letter
where Ryan Anderson <ryan@michonline.com> told me that...
> Make debian/rules executable, and correct the spelling of rsync in
> debian/control
Any progress with applying of this one? Linus, do you want me to ack
even trivial patches which had you in the recipient list? Or I could
start actively maintaining git-pb again, if you wish.
--
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] Make debian/rules executable, and correct the spelling of rsync in debian/control
From: Linus Torvalds @ 2005-07-22 22:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Ryan Anderson
In-Reply-To: <20050722221923.GM11916@pasky.ji.cz>
On Sat, 23 Jul 2005, Petr Baudis wrote:
>
> Dear diary, on Wed, Jul 20, 2005 at 03:17:47AM CEST, I got a letter
> where Ryan Anderson <ryan@michonline.com> told me that...
> > Make debian/rules executable, and correct the spelling of rsync in
> > debian/control
>
> Any progress with applying of this one? Linus, do you want me to ack
> even trivial patches which had you in the recipient list? Or I could
> start actively maintaining git-pb again, if you wish.
I don't know what I missed when I was away for a few days - especially
since there was some noise about people correcting their own patches. So
I'd actually prefer people just re-sent the stuff to me and I can apply
it.
Linus
^ permalink raw reply
* git-pb rebased
From: Petr Baudis @ 2005-07-22 22:35 UTC (permalink / raw)
To: git
Hello,
I don't expect anyone but myself to actually follow git-pb, but just
in case - I rebased it against the latest Linus' HEAD since its history
was becoming rather dirty, rusty and generally undesirable to merge for
anyone. So if you will try to update, you will end up with tree merge
and you don't want to do that, so
cat .git/refs/heads/origin >.git/refs/heads/master
--
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: Santi Béjar @ 2005-07-22 22:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: A Large Angry SCM, Ryan Anderson, git
In-Reply-To: <Pine.LNX.4.58.0507221447420.6074@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Think of something like a collection of projects, each under their own
> subdirectory. We could eventually literally make them _look_ like one big
> project, with cross-project commits grafted together, but they'd
> technically be totally independent (think "git" vs "gitk" - rather than
> having a very tight merge like I did, we could have tried to make it be a
> more virtual graft instead).
One posibility for a collection of projects is to make them with a tree of
commits instead of a tree of trees and blobs.
Santi
^ permalink raw reply
* Re: [PATCH 1/2] GIT: Try all addresses for given remote name
From: Sam Ravnborg @ 2005-07-23 0:15 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: pasky, git
In-Reply-To: <20050722.172629.73295196.yoshfuji@linux-ipv6.org>
On Fri, Jul 22, 2005 at 05:26:29PM -0400, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> 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.
You could copy the include/linux/stingify.h file from the kernel also.
That makes it available for other users also.
Sam
^ permalink raw reply
* Re: [PATCH 0/2] apply.c: a fix and an enhancement
From: Junio C Hamano @ 2005-07-22 22:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: A Large Angry SCM, Ryan Anderson, git
In-Reply-To: <Pine.LNX.4.58.0507221447420.6074@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I'd _really_ prefer to not have any preferences or other metadata files
> under version control within that same project.
Don't you think that would be a per-project decision? Is it
acceptable if I make sure that .gitinfo/* is _optional_ and
things do not break for projects that do not use it?
I hope you are not vetoing the ongoing discussion in another
thread from including the per-project configuration.
Some people want to run their project differently, and one thing
I see often done is to have pre-commit hooks that always run
test suites [*1*]. I do not think it is an unreasonable thing for
Porcelains to support, and what I am trying to get at is if two
Porcelains decide to support it, they do it in a compatible way.
> And personal preferences are just that - personal. I do _not_ want to have
> the kernel project history have things like "editor preferences" etc in
> the revision history - you might want to revision them, but that would be
> totally independent of the history of the project itself.
I agree. The .gitinfo/fake-parents may be a good thing in that
sense to have project-wide, and as long as the kernel person
(that is you) do not add .gitinfo/commit-template you would be
happy, wouldn't you?
[Footnote]
*1* Personally sometimes I feel myself that is silly, but that
is _other_ people's project, not my own. I think letting them
follow their own workflow to slow themselves is better than
outright forbidding it and telling them not to do it.
^ permalink raw reply
* [PATCH 0/9] applymbox updates and assorted trivial patches.
From: Junio C Hamano @ 2005-07-22 23:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
(Resend after you said you prefer people resending).
I was experimenting with applypatch and applymbox to see how it
feels like being Linus ;-) and also I saw some trivially correct
patches on the list floating unmerged during KS/OLS.
Since I rebase my repostitory to fix up the history often, I
needed a reliable way to preserve authorship information when I
export the patches via format-patch and slurp them via applymbox.
I am sending the following changes to applymbox and format-patch
first:
[PATCH] tools/applymbox: allow manual fixing and continuing after a failure.
[PATCH] git-format-patch-script and mailinfo updates.
[PATCH] format-patch: --mbox and --check.
I wrote the first one to recover from a situation where an
earlier patch failed to apply but I still had many other e-mails
in the mailbox.
The second one allows format-patch to give ability to optionally
add From: and Date: lines as the first two lines after the patch
title line. The mailinfo program has been enhanced to grok
Date: in the top part of the message body just like From: in the
message body can override the sender of the e-mail.
The third one is an extra. It lets me export patches in a
format resembling UNIX mbox, so I can concatenate the output
together and reprocess them through applymbox.
After they are accepted, I will forward these trivially correct
patches I saw on the list, using the enhanced format-patch; they
are expected to be processed with the new applymbox as a
practice; by doing this I am also ACKing these patches:
[PATCH] debian/ fixes
[PATCH] Fix a typo in git-unpack-objects documentation.
[PATCH] Cleanup: git-verify-tag-script
[PATCH] Install git-verify-tag-script
[PATCH] Support more http features: https no cert, .netrc -> auth
[PATCH] Document "curl" requirements.
^ permalink raw reply
* [PATCH] tools/applymbox: allow manual fixing and continuing after a failure.
From: Junio C Hamano @ 2005-07-22 23:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
With "-c .dotest/0002" flag, the applymbox command can be told
to use existing .dotest/patch file after hand-fixing the patch
conflicts for the second patch in the mailbox, and continue on
from that message, skipping the already applied first patch in
.dotest/0001.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
tools/applymbox | 48 ++++++++++++++++++++++++++++++++++++++----------
1 files changed, 38 insertions(+), 10 deletions(-)
688c63d625903ea3972deb3ec5c6dc3ef00f950e
diff --git a/tools/applymbox b/tools/applymbox
--- a/tools/applymbox
+++ b/tools/applymbox
@@ -9,20 +9,48 @@
## You give it a mbox-format collection of emails, and it will try to
## apply them to the kernel using "applypatch"
##
-## dotest [ -q ] mail_archive [Signoff_file]
+## applymbox [ -c .dotest/msg-number ] [ -q ] mail_archive [Signoff_file]"
##
-rm -rf .dotest
-mkdir .dotest
-case $1 in
+## The patch application may fail in the middle. In which case:
+## (1) look at .dotest/patch and fix it up to apply
+## (2) re-run applymbox with -c .dotest/msg-number for the current one.
+## Pay a special attention to the commit log message if you do this and
+## use a Signoff_file, because applypatch wants to append the sign-off
+## message to msg-clean every time it is run.
- -q) touch .dotest/.query_apply
- shift;;
+query_apply= continue= resume=t
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ -q) query_apply=t ;;
+ -c) continue="$2"; resume=f; shift ;;
+ -*) usage ;;
+ *) break ;;
+ esac
+ shift
+done
+
+case "$continue" in
+'')
+ rm -rf .dotest
+ mkdir .dotest
+ mailsplit "$1" .dotest || exit 1
esac
-mailsplit $1 .dotest || exit 1
-for i in .dotest/*
+
+case "$query_apply" in
+t) touch .dotest/.query_apply
+esac
+
+for i in .dotest/0*
do
- mailinfo .dotest/msg .dotest/patch < $i > .dotest/info || exit 1
- git-stripspace < .dotest/msg > .dotest/msg-clean
+ case "$resume,$continue" in
+ f,$i) resume=t;;
+ f,*) continue;;
+ *)
+ mailinfo .dotest/msg .dotest/patch <$i >.dotest/info || exit 1
+ git-stripspace < .dotest/msg > .dotest/msg-clean
+ ;;
+ esac
applypatch .dotest/msg-clean .dotest/patch .dotest/info "$2"
ret=$?
if [ $ret -ne 0 ]; then
^ permalink raw reply
* [PATCH] git-format-patch-script and mailinfo updates.
From: Junio C Hamano @ 2005-07-22 23:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
- avoid duplicating [PATCH] in the commit message body if the
original commit has it already (happens for commits done from
mails via applymbox).
- check if the commit author is different from the one who is
running the script, and emit an appropriate "From:" and
"Date: " lines to the output.
- with '--date', emit "Date: " line to preserve the original
author date even for the user's own commit.
- teach mailinfo to grok not just "From: " but "Date: ".
The patch e-mail output by format-patch starts with the first
line from the original commit message, prefixed with [PATCH],
and optionally a From: line if you are reformatting a patch
obtained from somebody else, a Date: line from the original
commit if (1) --date is specified or (2) for somebody else's
patch, and the rest of the commit message body.
Expected use of this is to move the title line from the commit
to Subject: when sending it via an e-mail, and leave the From:
and the Date: lines as the first lines of your message.
The mailinfo command has been changed to read Date: (in addition
to From: it already understands) and do sensible things when
running applymbox.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-format-patch-script | 38 +++++++++++++++++++++++++++++++-------
tools/mailinfo.c | 10 +++++++++-
2 files changed, 40 insertions(+), 8 deletions(-)
70e9ebdaa9951183d2e4f9b569dafbc50012d8ec
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -30,6 +30,8 @@ outdir=./
while case "$#" in 0) break;; esac
do
case "$1" in
+ -d|--d|--da|--dat|--date)
+ date=t ;;
-n|--n|--nu|--num|--numb|--numbe|--number|--numbere|--numbered)
numbered=t ;;
-o=*|--o=*|--ou=*|--out=*|--outp=*|--outpu=*|--output=*|--output-=*|\
@@ -56,6 +58,8 @@ esac
junio=`git-rev-parse --verify "$junio"`
linus=`git-rev-parse --verify "$linus"`
+me=`git-var GIT_AUTHOR_IDENT | sed -e 's/>.*/>/'`
+
case "$outdir" in
*/) ;;
*) outdir="$outdir/" ;;
@@ -66,6 +70,7 @@ tmp=.tmp-series$$
trap 'rm -f $tmp-*' 0 1 2 3 15
series=$tmp-series
+commsg=$tmp-commsg
titleScript='
/./d
@@ -82,6 +87,12 @@ titleScript='
q
'
+whosepatchScript='
+/^author /{
+ s/author \(.*>\) \(.*\)$/au='\''\1'\'' ad='\''\2'\''/p
+ q
+}'
+
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
stripCommitHead='/^'"$_x40"' (from '"$_x40"')$/d'
@@ -91,9 +102,8 @@ total=`wc -l <$series`
i=$total
while read commit
do
- title=`git-cat-file commit "$commit" |
- git-stripspace |
- sed -ne "$titleScript"`
+ git-cat-file commit "$commit" | git-stripspace >$commsg
+ title=`sed -ne "$titleScript" <$commsg`
case "$numbered" in
'') num= ;;
*)
@@ -102,6 +112,7 @@ do
*) num=' '`printf "%d/%d" $i $total` ;;
esac
esac
+
file=`printf '%04d-%stxt' $i "$title"`
i=`expr "$i" - 1`
echo "$file"
@@ -109,15 +120,28 @@ do
mailScript='
/./d
/^$/n
- s|^|[PATCH'"$num"'] |
+ s|^\[PATCH[^]]*\] *||
+ s|^|[PATCH'"$num"'] |'
+
+ eval "$(sed -ne "$whosepatchScript" $commsg)"
+ test "$au" = "$me" || {
+ mailScript="$mailScript"'
+ a\
+From: '"$au"
+ }
+ test "$date,$au" = ",$me" || {
+ mailScript="$mailScript"'
+ a\
+Date: '"$ad"
+ }
+
+ mailScript="$mailScript"'
: body
p
n
b body'
- git-cat-file commit "$commit" |
- git-stripspace |
- sed -ne "$mailScript"
+ sed -ne "$mailScript" <$commsg
echo '---'
echo
git-diff-tree -p $diff_opts "$commit" | git-apply --stat --summary
diff --git a/tools/mailinfo.c b/tools/mailinfo.c
--- a/tools/mailinfo.c
+++ b/tools/mailinfo.c
@@ -220,8 +220,9 @@ static int eatspace(char *line)
static void handle_body(void)
{
int has_from = 0;
+ int has_date = 0;
- /* First line of body can be a From: */
+ /* First lines of body can have From: and Date: */
while (fgets(line, sizeof(line), stdin) != NULL) {
int len = eatspace(line);
if (!len)
@@ -232,6 +233,13 @@ static void handle_body(void)
continue;
}
}
+ if (!memcmp("Date:", line, 5) && isspace(line[5])) {
+ if (!has_date) {
+ handle_date(line+6);
+ has_date = 1;
+ continue;
+ }
+ }
line[len] = '\n';
handle_rest();
break;
^ permalink raw reply
* [PATCH] format-patch: --mbox and --check.
From: Junio C Hamano @ 2005-07-22 23:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Add --mbox option to export patches in a format resembling UNIX
mbox, so that later they can be concatenated and fed to
applymbox.
Add --check to look for lines that introduce bogus whitespaces.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-format-patch-script | 49 +++++++++++++++++++++++++++++++++++++++++------
1 files changed, 43 insertions(+), 6 deletions(-)
b9d503a8a5e3d83059836c939a09d5f6abdf5406
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -4,7 +4,7 @@
#
usage () {
- echo >&2 "usage: $0"' [-n] [-o dir] [-<diff options>...] upstream [ our-head ]
+ echo >&2 "usage: $0"' [-n] [-o dir] [--mbox] [--check] [-<diff options>...] upstream [ our-head ]
Prepare each commit with its patch since our-head forked from upstream,
one file per patch, for e-mail submission. Each output file is
@@ -16,6 +16,10 @@ the current working directory.
When -n is specified, instead of "[PATCH] Subject", the first line is formatted
as "[PATCH N/M] Subject", unless you have only one patch.
+
+When --mbox is specified, the output is formatted to resemble
+UNIX mailbox format, and can be concatenated together for processing
+with applymbox.
'
exit 1
}
@@ -25,13 +29,19 @@ IFS='
'
LF='
'
-outdir=./
+outdir=./
while case "$#" in 0) break;; esac
do
case "$1" in
+ -a|--a|--au|--aut|--auth|--autho|--author)
+ author=t ;;
+ -c|--c|--ch|--che|--chec|--check)
+ check=t ;;
-d|--d|--da|--dat|--date)
date=t ;;
+ -m|--m|--mb|--mbo|--mbox)
+ date=t author=t mbox=t ;;
-n|--n|--nu|--num|--numb|--numbe|--number|--numbere|--numbered)
numbered=t ;;
-o=*|--o=*|--ou=*|--out=*|--outp=*|--outpu=*|--output=*|--output-=*|\
@@ -71,6 +81,7 @@ trap 'rm -f $tmp-*' 0 1 2 3 15
series=$tmp-series
commsg=$tmp-commsg
+filelist=$tmp-files
titleScript='
/./d
@@ -115,16 +126,27 @@ do
file=`printf '%04d-%stxt' $i "$title"`
i=`expr "$i" - 1`
- echo "$file"
+ echo >&2 "* $file"
{
mailScript='
/./d
/^$/n
- s|^\[PATCH[^]]*\] *||
- s|^|[PATCH'"$num"'] |'
+ s|^\[PATCH[^]]*\] *||'
+
+ case "$mbox" in
+ t)
+ echo 'From nobody Mon Sep 17 00:00:00 2001' ;# UNIX "From" line
+ mailScript="$mailScript"'
+ s|^|Subject: [PATCH'"$num"'] |'
+ ;;
+ *)
+ mailScript="$mailScript"'
+ s|^|[PATCH'"$num"'] |'
+ ;;
+ esac
eval "$(sed -ne "$whosepatchScript" $commsg)"
- test "$au" = "$me" || {
+ test "$author,$au" = ",$me" || {
mailScript="$mailScript"'
a\
From: '"$au"
@@ -147,5 +169,20 @@ Date: '"$ad"
git-diff-tree -p $diff_opts "$commit" | git-apply --stat --summary
echo
git-diff-tree -p $diff_opts "$commit" | sed -e "$stripCommitHead"
+
+ case "$mbox" in
+ t)
+ echo
+ ;;
+ esac
} >"$outdir$file"
+ case "$check" in
+ t)
+ # This is slightly modified from Andrew Morton's Perfect Patch.
+ # Lines you introduce should not have trailing whitespace.
+ # Also check for an indentation that has SP before a TAB.
+ grep -n '^+\([ ]* .*\|.*[ ]\)$' "$outdir$file"
+
+ : do not exit with non-zero because we saw no problem in the last one.
+ esac
done <$series
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Junio C Hamano @ 2005-07-22 23:07 UTC (permalink / raw)
To: Catalin Marinas
Cc: Petr Baudis, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <1122068634.7042.35.camel@localhost.localdomain>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> Would such a template only have 'GIT:' prefixed lines? I usually put
> another line like 'Signed-off-by:', for convenience. The problem with
> StGIT appears when one wants to re-edit the patch description (stg
> refresh -e), in which case the existing description should be merged
> with a part of the template (if you want to get the editor setting for
> example). It doesn't do this since there is no point in getting another
> 'Signed...' line in the existing description.
If signed-off-by is the only thing you are worried about, how
about making it not part of the commit template and the message
user touches with the editor? You first look at the user
configuration somewhere to see if the user wants the
signed-off-by line to his commits and with what value, and if
the last lines of the edit result does not contain that value
(to avoid duplicates), add it before feeding the message to
git-commit-tree.
>> - standard "dontdiff/ignore" file.
>
> StGIT currently uses .git/exclude, since I saw it used by cogito. What
> is dontdiff supposed to do? The 'git diff' command only shows the diff
> for the files added to the repository.
I see that what I wrote was vague and badly stated. Please
forget about my mentioning "dontdiff". What I meant was your
.git/exclude, Pasky's .gitignore file and friends.
>> - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and
>> such).
>
> StGIT works the other way around. By default uses the environment, which
> can be overridden by the stgitrc file. I could change this easily.
Again I was vague, and what you say StGIT does is exactly what I
meant. I have one value in my environment coming from the login
shell, and a per- repository preference item overrides it to
something else.
>> - Per project. A project may want to enforce pre-commit hook
>> for all participants;
>
> As Petr said, it's hard to define a project.
By reading the part you talk about your hating tla, I think you
know exactly what I mean.
When you merge two projects like Linus did between git.git and
gitk, obviously the person who is merging the two is responsible
for merging the per-project default configuration and resolving
conflicts. This probably should be overridable by individual
developers who pull/fetch into their repository by having per-
repository configuration.
> For StGIT it makes sense to get some default settings via /etc/stgitrc.
> There are things like a SMTP server and the diff3 command. These are set
> when installing the application and can be overridden in your home
> or .git directories.
Exactly, but that is not specific to StGIT, I presume, and I did
not want to hear "``For StGIT'' it makes sense". If StGIT needs
to use "diff3" on a system, probably that is because "merge" is
not available on that system. In that case, cogito needs to
use it too, doesn't it?
If we can make users and sysadmins not having to maintain two
sets of configuration files for two Porcelains, if we
can,... that is what I have been trying to address.
> Before we get to "where", we should define the common
> settings. I think that git should define the common settings
> for its operations and the other tools should follow them.
Personally, unless it is something very obvious and basic, I do
not think the core barebone Porcelain should be inventing
arbitrary conventions and imposing them on other Porcelains.
For very basic things I would agree.
I think Petr already started the discussion rolling for commit
templates, and I like his proposal. For ignore pattern files, I
think what Cogito does sounds almost sensible [*1*] and I am
sure StGIT have something similar. I do not see Linus and co
jumping up and down saying git-status should detect and show new
files not registered in the cache, so for now I'd propose to
skip adding this one to the barebone Porcelain (meaning, this is
an example of not "git defining the common and others following
suite").
> That's the thing I didn't like in GNU Arch. You modify the file ignoring
> rules for example and the change will be included in the next commit.
> You could only get some defaults when cloning a repository, otherwise
> once you have different preferences from the repository's maintainer,
> you start getting conflicts in the config files.
That's why I suggested to have "_git" (project wide default)
separate from $GIT_DIR/info (repository owner's discretion), the
latter overriding the former.
>> - 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.
>
> Again, having Porcelain specific options mixed in the same file might
> lead to some confusion among users.
True. We need to be careful.
Or course, there is an option of not worry about Porcelain
compatibilities at all --- which is certainly simpler. All we
need is to make sure they do not use the same filename for
conflicting purposes. If everybody feels that way then this
discussion is moot and I apologize for wasting people's time.
[Footnote]
*1* I said "almost sensible" but it is not meant to blame Pasky.
I think the --exclude mechanism in git-ls-files should be
extended to allow not just the filename-sans-leading-directory
match but a full relative-to-the-project-root path match. That
way, cg-status would not have to run around in the tree to find
individual .gitignore files.
Personally, I think having to have ignore pattern like .cvsignore
per-directory is simply _ugly_.
^ permalink raw reply
* Re: Local cg-pull fails
From: Petr Baudis @ 2005-07-22 23:22 UTC (permalink / raw)
To: Russell King; +Cc: git
In-Reply-To: <20050714111224.B31383@flint.arm.linux.org.uk>
Dear diary, on Thu, Jul 14, 2005 at 12:12:25PM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> Last time this was discussed, someone suggested -f, which solved the
> problem. Can we please modify the cg-pull script to use -f ?
Thanks, done.
> Secondly, can I suggest that cogito developers consider the above
> usage scenario and construct a regression test for it to ensure that
> future breakages of this nature are caught. For me, cogito has been
> extremely fragile, and I don't think the above usage is unreasonable.
Done.
--
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 23:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: Catalin Marinas, Bryan larsen, git
In-Reply-To: <20050722212725.GJ11916@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> Cogito shows '[NMD] filename' in place of @FILELIST@.
Sounds sensible. Does it parse it to limit the files to be
committed?
> 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?
Although I admit that is minor, I've had the same problem, and
this sounds like a good idea.
However, I'd like to see what the extent of damage would be even
if everybody agrees this is a good change. Any one of core
barebone Porcelain, Linus git-tools, gitk, gitweb, Cogito, and
StGIT would have a veto over this kind of change, or at least we
should wait until everybody catches up.
If we all decide to go ahead, the transition would not be so
painful, since we do not currently say 'A', the Porcelains can
start accepting 'A' as synonym for 'N' today, and then later we
can change the tools to produce 'A' instead of 'N'.
^ permalink raw reply
* Re: [PATCH 0/2] apply.c: a fix and an enhancement
From: Linus Torvalds @ 2005-07-22 23:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: A Large Angry SCM, Ryan Anderson, git
In-Reply-To: <7vfyu6jvrm.fsf@assigned-by-dhcp.cox.net>
On Fri, 22 Jul 2005, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > I'd _really_ prefer to not have any preferences or other metadata files
> > under version control within that same project.
>
> Don't you think that would be a per-project decision? Is it
> acceptable if I make sure that .gitinfo/* is _optional_ and
> things do not break for projects that do not use it?
It can't be a per-project decision, since the preferences are
per-developer.
In other words, if it's per-project, then that implies that every single
developer has to agree on the same thing. Which just not possible - it
makes no sense.
In contrast, if you have a separate local _branch_ that maintains a
".gitinfo" totally separately (no common commits at all), then you can
choose to propagate/participate in that branch or not, as you wish, on a
per-developer basis.
> I agree. The .gitinfo/fake-parents may be a good thing in that
> sense to have project-wide,
I disagree. Even something like fake-parents isn't project-wide.
For example, what if I tried to dig out even _more_ information than what
is in the BK CVS archives? Or if I wanted to have just the 2.6.0->
history? The whole point of fake-parents is that you can do things like
that - you can point your history at alternative views.
If we'd make it project-global, then we might as well just rewrite the
original commit entirely, and use "git-convert-cache" to convert the whole
archive. At that point, fake-parents becomes pointless.
> and as long as the kernel person
> (that is you) do not add .gitinfo/commit-template you would be
> happy, wouldn't you?
What you're saying is that people can be happy if they just don't use a
stupid decision. That's a sure sign that the decision shouldn't have been
made in the first place.
Linus
^ permalink raw reply
* Re: [PATCH 0/2] apply.c: a fix and an enhancement
From: Petr Baudis @ 2005-07-22 23:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, A Large Angry SCM, Ryan Anderson, git
In-Reply-To: <Pine.LNX.4.58.0507221447420.6074@g5.osdl.org>
Dear diary, on Fri, Jul 22, 2005 at 11:53:41PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Fri, 22 Jul 2005, Junio C Hamano wrote:
> >
> > And the file would obviously be per-project, so according to
> > Pasky's suggestion that would be ".gitinfo/fake_parents" ;-).
>
> I'd _really_ prefer to not have any preferences or other metadata files
> under version control within that same project.
>
> If you want to version control them, that's fine, but don't tie the
> versioning to the main project itself. You can have a _separate_ git
> index, and a separate branch for the preferences and other metadata (but
> you can, if you want to, obviously share the .git directory contents and
> mix up the objects).
I think that is a bad idea. Suddenly, you do not have the two things in
the same timeline, which may be quite confusing especially in case of
some hooks which depend on the contents of the tree of the project
itself, in case of commit templates and such.
> And personal preferences are just that - personal. I do _not_ want to have
> the kernel project history have things like "editor preferences" etc in
> the revision history - you might want to revision them, but that would be
> totally independent of the history of the project itself.
Yes, but this stuff is not for personal preferences. It is for
project-wide preferences and policies, which can be still normally
overridden or altered locally in each repository.
--
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: Petr Baudis @ 2005-07-22 23:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, A Large Angry SCM, Ryan Anderson, git
In-Reply-To: <Pine.LNX.4.58.0507221619450.6074@g5.osdl.org>
Dear diary, on Sat, Jul 23, 2005 at 01:26:07AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Fri, 22 Jul 2005, Junio C Hamano wrote:
> > Linus Torvalds <torvalds@osdl.org> writes:
> >
> > > I'd _really_ prefer to not have any preferences or other metadata files
> > > under version control within that same project.
> >
> > Don't you think that would be a per-project decision? Is it
> > acceptable if I make sure that .gitinfo/* is _optional_ and
> > things do not break for projects that do not use it?
>
> It can't be a per-project decision, since the preferences are
> per-developer.
>
> In other words, if it's per-project, then that implies that every single
> developer has to agree on the same thing. Which just not possible - it
> makes no sense.
Some example of possible per-project settings:
pre-commit hook killing trailing whitespaces
global per-project ignore file (*.ko or something)
common base commit template
(standardized form developer fills in when committing,
some remindments in the comment section, ...)
Obviously, you still ought to have a way to locally override any of
those per-repository in your .git/conf/.
--
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 23:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, A Large Angry SCM, Ryan Anderson, git
In-Reply-To: <20050722233344.GP11916@pasky.ji.cz>
On Sat, 23 Jul 2005, Petr Baudis wrote:
>
> Yes, but this stuff is not for personal preferences. It is for
> project-wide preferences and policies, which can be still normally
> overridden or altered locally in each repository.
What you are describing is a nightmare.
Let's assume that a user alters the settings locally.
EVERY SINGLE TIME he does a "cg-commit", those local alterations would get
committed, since that config file is part of the same project, and cogito
by default commits all changes.
That's just insane. It means that in practive it's simply not reasonable
to have your own local copies of that file. So what would you do? You'd
add more and more hacks to cover this up, and have a "commit-ignore" file
that ignores the .gitinfo files etc etc. UGLY. All because of a design
mistake.
In contrast, let's say that the .gitinfo/xyzzy files were in another
unrelated branch altogether: that means that normally those files wouldn't
even be seen by git as being under revision control (the "index" file
doesn't mention them, nor the tree pointed to by HEAD), but you could, if
you wanted to, do a simple
#
# edit the control files and check the
# changes in to the control stream
#
git switch control-files
.. edit .gitinfo/xyzzy
git commit --all
#
# get back to the real project
#
git switch master
and it just works. In the above "git switch" would be exactly the same as
a normal "git checkout", except it's told to not update the current
directory contexts on switch and instead just save the index file away and
restore it. (In contrast, using a full "git checkout" would remove the
real project when switching to the control files, and then again remove
the control files when switching back to the main project).
Linus
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Petr Baudis @ 2005-07-22 23:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Catalin Marinas, Bryan larsen, git
In-Reply-To: <7v8xzyh1ak.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Jul 23, 2005 at 01:24:35AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Cogito shows '[NMD] filename' in place of @FILELIST@.
>
> Sounds sensible. Does it parse it to limit the files to be
> committed?
Yes.
> > 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?
>
> Although I admit that is minor, I've had the same problem, and
> this sounds like a good idea.
>
> However, I'd like to see what the extent of damage would be even
> if everybody agrees this is a good change. Any one of core
> barebone Porcelain, Linus git-tools, gitk, gitweb, Cogito, and
> StGIT would have a veto over this kind of change, or at least we
> should wait until everybody catches up.
I don't think the situation is so bad. At least in Cogito, there is only
one use of 'N' (and cg-status, but that goes directly to the user), and
it's likely useless and things would work even with that changing to 'A'
(nevertheless, I just updated Cogito to accept 'A' at that place as
well).
--
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: Petr Baudis @ 2005-07-22 23:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, A Large Angry SCM, Ryan Anderson, git
In-Reply-To: <Pine.LNX.4.58.0507221640050.6074@g5.osdl.org>
Dear diary, on Sat, Jul 23, 2005 at 01:50:09AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
>
>
> On Sat, 23 Jul 2005, Petr Baudis wrote:
> >
> > Yes, but this stuff is not for personal preferences. It is for
> > project-wide preferences and policies, which can be still normally
> > overridden or altered locally in each repository.
>
> What you are describing is a nightmare.
>
> Let's assume that a user alters the settings locally.
>
> EVERY SINGLE TIME he does a "cg-commit", those local alterations would get
> committed, since that config file is part of the same project, and cogito
> by default commits all changes.
No, no, no. A user does not alter the settings locally in .gitinfo/ -
.gitinfo/ is for per-_project_ stuff, not per-user. If user wants an
override, he does it per-repository in his .git/conf directory, which is
not version-tracked (actually, core GIT does not even let me to).
> That's just insane. It means that in practive it's simply not reasonable
> to have your own local copies of that file. So what would you do? You'd
> add more and more hacks to cover this up, and have a "commit-ignore" file
> that ignores the .gitinfo files etc etc. UGLY. All because of a design
> mistake.
Actually, commit-ignore might be useful in other cases, e.g. when
someone (me, a thousand times in the past) needs to keep temporary hacks
in the Makefile so that he can actually build the thing on his weird
system etc. ;-)
--
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
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