* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Daniel Jacobowitz @ 2005-04-19 22:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504191449270.2274@ppc970.osdl.org>
On Tue, Apr 19, 2005 at 03:00:04PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 19 Apr 2005, Greg KH wrote:
> >
> > It looks like your domain name isn't set up properly for your box (which
> > is why it worked for you, but not me before, causing that patch).
>
> No, I think it's a bug in your domainname changes. I don't think you
> should do the domainname at all if the hostname has a dot in it.
>
> Most machines I have access to (and that includes machines that are
> professionally maintained, not just my own cruddy setup) says "(none)" to
> domainname and have the full hostname in hostname.
>
> And even the ones that use domainname tend to not have a fully qualified
> DNS domain there. You need to use dnsdomainname to get that, and I don't
> even know how to do it with standard libc.
>
> So how about something like this?
>
> (Somebody who actually knows how these things should be done - please feel
> free to pipe up).
The glibc documentation blows for this, but what getdomainname comes
from uname(2), not from any DNS-related configuration. Debian only
ever sets this if you're using NIS.
There's no real great way to get the current hostname; a lot of
applications do a reverse DNS lookup on the primary network interface,
with appropriate handwaving to define primary.
Easiest might be to punt to hostname --fqdn, or an equivalent to its
algorithm - which appears to be fetch the hostname from uname, do a DNS
lookup on that, and a reverse DNS lookup on the result.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Petr Baudis @ 2005-04-19 22:26 UTC (permalink / raw)
To: Steven Cole
Cc: Linus Torvalds, Greg KH, Greg KH, Git Mailing List, linux-kernel,
sensors
In-Reply-To: <426583D5.2020308@mesatop.com>
Dear diary, on Wed, Apr 20, 2005 at 12:19:01AM CEST, I got a letter
where Steven Cole <elenstev@mesatop.com> told me that...
> Linus Torvalds wrote:
> >
> >On Tue, 19 Apr 2005, Greg KH wrote:
> >
> >>Nice, it looks like the merge of this tree, and my usb tree worked just
> >>fine.
> >
> >
> >Yup, it all seems to work out.
>
> [many files patched]
> patching file mm/mmap.c
> patching file net/bridge/br_sysfs_if.c
> patching file scripts/ver_linux
> ----------------------^^^^^^^^^
> Hey, that's my patch! Last...and least.
> But perhaps a progress bar right about here might be
> a good thing for the terminally impatient.
>
> real 3m54.909s
> user 0m14.835s
> sys 0m10.587s
>
> 4 minutes might be long enough to cause some folks to lose hope.
I'm wondering if doing
if [ "$(show-diff)" ]; then
git diff | git apply
else
checkout-cache -f -a
fi
would actually buy us some time; or, how common is it for people to have
no local changes whatsoever, and whether relative slowdown of additional
show-diff to git diff would actually matter.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Martin Schlemmer @ 2005-04-19 22:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504191449270.2274@ppc970.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]
On Tue, 2005-04-19 at 15:00 -0700, Linus Torvalds wrote:
>
> On Tue, 19 Apr 2005, Greg KH wrote:
> >
> > It looks like your domain name isn't set up properly for your box (which
> > is why it worked for you, but not me before, causing that patch).
>
> No, I think it's a bug in your domainname changes. I don't think you
> should do the domainname at all if the hostname has a dot in it.
>
> Most machines I have access to (and that includes machines that are
> professionally maintained, not just my own cruddy setup) says "(none)" to
> domainname and have the full hostname in hostname.
>
> And even the ones that use domainname tend to not have a fully qualified
> DNS domain there. You need to use dnsdomainname to get that, and I don't
> even know how to do it with standard libc.
>
Correct me if I am wrong, but the right way to do this is to set the
hostname to just that - the hostname, and add 'domain foo.com'
to /etc/resolv.conf. Then you should get something like (for say
www1.foo.com):
$ hostname
www1
$ dnsdomainname
foo.com
$ hostname -f
www1.foo.com
I know for some buggy software the workaround was to set the hostname to
the FQDN, but that is really just a kludge, and the software should
rather be fixed (had to patch postfix some time back for instance).
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] write-tree performance problems
From: Linus Torvalds @ 2005-04-19 22:21 UTC (permalink / raw)
To: David Lang; +Cc: Chris Mason, git
In-Reply-To: <Pine.LNX.4.62.0504191508060.26365@qynat.qvtvafvgr.pbz>
On Tue, 19 Apr 2005, David Lang wrote:
>
> what if you turned the forest of quilt patches into a forest of git trees?
> (essentially applying each patch against the baseline seperatly) would
> this make sense or be useful?
It has a certain charm, but the fact is, it gets really messy to sort out
later.
The thing is, there's a huge benefit to a straight-line tree: you can do
binary searching etc of patches that cause problems, and in general it's
just a lot _easier_ to work with a linear set of patches for pretty much
everybody.
So yes, it's "cool" to show the fact that patches are independent and show
them as each applying to the baseline (and then you can have the "mother
of all merges" that ties them all together), but that's just a _nightmare_
when you actually try to debug things and sort things out.
So while I'm a huge proponent of parallell development, and having lots of
branches, I actually think that _linearizing_ stuff is a good thing.
So let's put it this way: parallel development and merging is wonderful as
a tool to handle true distributed development, and it's the thing that GIT
really tries to do. But once you have "local" development (like in a set
of quilt patches), the _last_ thing you want to do is try to make it look
parallel. You're much better off picking a good order, and sticking with
it. Because otherwise, 2 months down the line, you'll just look at that
tree, and what you'll want to do is to visualize them linearly anyway.
Linus
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Steven Cole @ 2005-04-19 22:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, Greg KH, Git Mailing List, linux-kernel, sensors
In-Reply-To: <Pine.LNX.4.58.0504191204480.19286@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Tue, 19 Apr 2005, Greg KH wrote:
>
>>Nice, it looks like the merge of this tree, and my usb tree worked just
>>fine.
>
>
> Yup, it all seems to work out.
[many files patched]
patching file mm/mmap.c
patching file net/bridge/br_sysfs_if.c
patching file scripts/ver_linux
----------------------^^^^^^^^^
Hey, that's my patch! Last...and least.
But perhaps a progress bar right about here might be
a good thing for the terminally impatient.
real 3m54.909s
user 0m14.835s
sys 0m10.587s
4 minutes might be long enough to cause some folks to lose hope.
Steven
^ permalink raw reply
* Re: [PATCH] write-tree performance problems
From: David Lang @ 2005-04-19 22:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Chris Mason, git
In-Reply-To: <Pine.LNX.4.58.0504191143220.19286@ppc970.osdl.org>
On Tue, 19 Apr 2005, Linus Torvalds wrote:
> On Tue, 19 Apr 2005, Chris Mason wrote:
>>
>> Very true, you can't replace quilt with git without ruining both of them. But
>> it would be nice to take a quilt tree and turn it into a git tree for merging
>> purposes, or to make use of whatever visualization tools might exist someday.
>
> Fair enough. The thing is, going from quilt->git really is a pretty "big
> decision", since it's the decision that says "I will now really commit all
> this quilt changes forever and ever".
>
> Which is also why I think it's actually ok to take a minute to do 100
> quilt patches. This is not something you do on a whim. It's something
> you'd better think about. It's turning a very fluid environment into a
> unchangable, final thing.
what if you turned the forest of quilt patches into a forest of git trees?
(essentially applying each patch against the baseline seperatly) would
this make sense or be useful?
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Re: [darcs-devel] Darcs and git: plan of action
From: Patrick McFarland @ 2005-04-19 22:08 UTC (permalink / raw)
To: darcs-devel; +Cc: Kevin Smith, Ray Lee, git
In-Reply-To: <4264677A.9090003@qualitycode.com>
[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]
On Monday 18 April 2005 10:05 pm, Kevin Smith wrote:
> The big feature of a darcs replace patch is that it works forward and
> backward in time. Let me try to come up with an example that can help
> explain it. Hopefully I'll get it right. Let's start with a file like
> this that exists in a project for which both you and I have darcs repos:
>
> cat
> dog
> fish
>
> Now, you change it to:
>
> cat dog
> dog
> fish
>
> while I simultaneously do a replace of "dog" with "plant", resulting in:
>
> cat
> plant
> fish
>
> We merge. The final result in both of our trees is:
>
> cat plant
> plant
> fish
>
> Notice that just by looking at my diffs, you can't tell that I used a
> replace operation. I didn't just replace the instances of "dog" that
> were in my file at that moment. I conceptually replaced all instances,
> including ones that aren't there yet.
I think that's the best explanation of how it works. And that is partially why
darcs is so powerful.
--
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Linus Torvalds @ 2005-04-19 22:00 UTC (permalink / raw)
To: Greg KH; +Cc: Git Mailing List
In-Reply-To: <20050419214009.GA25681@kroah.com>
On Tue, 19 Apr 2005, Greg KH wrote:
>
> It looks like your domain name isn't set up properly for your box (which
> is why it worked for you, but not me before, causing that patch).
No, I think it's a bug in your domainname changes. I don't think you
should do the domainname at all if the hostname has a dot in it.
Most machines I have access to (and that includes machines that are
professionally maintained, not just my own cruddy setup) says "(none)" to
domainname and have the full hostname in hostname.
And even the ones that use domainname tend to not have a fully qualified
DNS domain there. You need to use dnsdomainname to get that, and I don't
even know how to do it with standard libc.
So how about something like this?
(Somebody who actually knows how these things should be done - please feel
free to pipe up).
Linus
---
commit-tree.c: 54b636ee1edf596dae1cb9a756eaccdfd5127cef
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -317,8 +317,10 @@ int main(int argc, char **argv)
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
gethostname(realemail+len+1, sizeof(realemail)-len-1);
- strcat(realemail, ".");
- getdomainname(realemail+strlen(realemail), sizeof(realemail)-strlen(realemail)-1);
+ if (!strchr(realemail+len+1, '.')) {
+ strcat(realemail, ".");
+ getdomainname(realemail+strlen(realemail), sizeof(realemail)-strlen(realemail)-1);
+ }
time(&now);
tm = localtime(&now);
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Greg KH @ 2005-04-19 21:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, linux-kernel, sensors
In-Reply-To: <Pine.LNX.4.58.0504191316180.19286@ppc970.osdl.org>
On Tue, Apr 19, 2005 at 01:20:47PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 19 Apr 2005, Greg KH wrote:
> >
> > Ok, if you want some practice with "real" merges, feel free to merge from
> > the following two trees whenever you are ready:
> > kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2.6.git/
> > for 11 aoe bugfix patches, and:
> > kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/
> > for 13 driver core, sysfs, and debugfs fixes.
>
> Done, pushed out. Can you verify that the end result looks sane to you? I
> just cheched that the diffstat looks similar (mine claims just 108 lines
> changed in aoecmd.c - possibly due to different diff formats).
Looks good to me (the diffstat difference is probably because the
patches were consecutive, and the sum of them are smaller (modifying
same parts of the files, etc.))
The git-changes-script shows that you picked up everything from my trees
successfully (assuming we trust that so far) and a raw diff looks good
too.
Two "odd" things in the changelog:
commit caaaaebc2380426b64aaa60a169834a7aefc956c
tree 484292d57c19acbf04cf5c783e7d26181b95e96e
parent 334a4e1b19f7f471594f7abd3bfead3720c1bd61
author Hugh Dickins <hugh@veritas.com> Wed, 20 Apr 2005 03:29:23 -0700
committer Linus Torvalds <torvalds@ppc970.osdl.org.(none)> Wed, 20 Apr 2005 03:29:23 -0700
It looks like your domain name isn't set up properly for your box (which
is why it worked for you, but not me before, causing that patch).
Also the date is in the future with the -0700, yet the time is in UTC.
Oh wait, that's a 'git log' thing, the raw changeset is correct, I guess
I'll wait for Pasky to fix that :)
> And yes, my new merge thing seems to have kept the index-cache much better
> up-to-date, allowing an optimized checkout-cache -f -a to work and only
> get the new files.
Very nice.
thanks,
greg k-h
^ permalink raw reply
* Bug in merge-base
From: Petr Baudis @ 2005-04-19 21:31 UTC (permalink / raw)
To: barkalow; +Cc: git
Hello,
I've hit a strange bug in merge-base I don't want to debug now. ;-)
I've been doing my regular git pull test from my main branch, but
suddenly git merge wanted to do a tree merge instead of fast-forward.
What went wrong?
The commits tree looks like:
36c764 -- 808162 -- ...... -- 8e08e7
5b53d3 -'
(see the rev-tree output at
http://pasky.or.cz/~pasky/dev/git/stuff/rev-tree)
The problem is, merge-base hints me wrong:
$ merge-base 8e08e7 808162
5b53d3
instead of 808162.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] write-tree performance problems
From: Linus Torvalds @ 2005-04-19 21:23 UTC (permalink / raw)
To: Chris Mason; +Cc: git
In-Reply-To: <200504191708.23536.mason@suse.com>
On Tue, 19 Apr 2005, Chris Mason wrote:
>
> Regardless, putting it into the index somehow should be fastest, I'll see what
> I can do.
Start by putting it in at "read-tree" time, and adding the code to
invalidate all parent directory indexes when somebody changes a file in
the index (ie "update-cache" for anything but a "--refresh").
That would be needed anyway, since those two are the ones that already
change the index file.
Once you're sure that you can correctly invalidate the entries (so that
you could never use a stale tree entry by mistake), the second stage would
be to update it at "write-tree" time.
Linus
^ permalink raw reply
* wit 0.0.2 - a web interface for git available
From: Christian Meder @ 2005-04-19 21:15 UTC (permalink / raw)
To: git
Hi,
I've uploaded a new wit to http://www.absolutegiganten.org/wit
Wit is a web interface for git. Right now it includes: views of blob,
commit and tree objects, generating patches for the commits, downloading
of gz or bzip2 tarballs of trees.
It's easy to setup and a simple stand alone server configuration is
included.
Changes:
* the html doesn't look like total crap anymore
* generates patches against one parent on the fly
* generates gz or bzip2 tarballs on the fly
Feedback is greatly appreciated.
Greetings,
Christian
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
^ permalink raw reply
* Re: [PATCH] write-tree performance problems
From: Chris Mason @ 2005-04-19 21:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504191143220.19286@ppc970.osdl.org>
On Tuesday 19 April 2005 15:03, Linus Torvalds wrote:
> On Tue, 19 Apr 2005, Chris Mason wrote:
> > Very true, you can't replace quilt with git without ruining both of them.
> > But it would be nice to take a quilt tree and turn it into a git tree
> > for merging purposes, or to make use of whatever visualization tools
> > might exist someday.
>
> Fair enough. The thing is, going from quilt->git really is a pretty "big
> decision", since it's the decision that says "I will now really commit all
> this quilt changes forever and ever".
>
> Which is also why I think it's actually ok to take a minute to do 100
> quilt patches. This is not something you do on a whim. It's something
> you'd better think about. It's turning a very fluid environment into a
> unchangable, final thing.
>
It's only final when someone pulls from you...for me, all the trees would be
temporary.
[ ... subtree tree hashes in the index file ... ]
> I'll think about it. I'd love to speed up write-tree, and keeping track of
> it in the index is a nice little trick, but it's not quite high enough up
> on my worries for me to act on it right now.
>
> But if you want to try to see how nasty it would be to add tree index
> entries to the index file at "write-tree" time automatically, hey...
>
Makes sense, I'll let the merge development frenzy die down and give it a try
one weekend. I might look into making it a special case of the merging index
changes, since some of the concepts seem similar.
Regardless, putting it into the index somehow should be fastest, I'll see what
I can do.
-chris
^ permalink raw reply
* Re: [PATCH] Add help details to git help command. (This time with Perl)
From: David Greaves @ 2005-04-19 20:45 UTC (permalink / raw)
To: Steven Cole; +Cc: Petr Baudis, git
In-Reply-To: <42656B6B.3080209@mesatop.com>
Steven Cole wrote:
> Speaking of "I think", the name "cogito" was suggested for the
> SCM layer, but IIRC Linus suggested staying with just plain git. Petr
> suggested tig, perhaps because it looks at git from another point of view.
I haven't read _all_ the mails - I thought cogito was kinda selected and
I got the feeling that Linus wasn't exactly bothered what it was called.
Anyway, git has a rename that needs testing at some point...
> legit Since git is GPLv2, but perhaps a little too French.
That made me smile.
Quite a few entendres in there...
It's Petr's baby - he gets to name it.
David
^ permalink raw reply
* Re: [PATCH] Add help details to git help command. (This time with Perl)
From: Steven Cole @ 2005-04-19 20:34 UTC (permalink / raw)
To: David Greaves; +Cc: Petr Baudis, git
In-Reply-To: <42655630.80207@dgreaves.com>
David Greaves wrote:
> Petr Baudis wrote:
>
>> Dear diary, on Tue, Apr 19, 2005 at 07:35:15PM CEST, I got a letter
>> where Steven Cole <elenstev@mesatop.com> told me that...
>>
>
> I've been working on git.pl and getting help working nicely
>
> things to try:
> git.pl help
> git.pl add
> git.pl add --help
> git.pl add --man
> git.pl help add
>
> The main objectives:
> * get a reasonable perl code base in git.pl
> * provide some way to document WTF is going on :)
> * keep the docs near the developer
> * allow variations in verbosity
> * modularise
> * don't use modules outside the base perl set
> * allow a gentle migration (so start by calling the .sh's)
>
> I don't like the pod2usage calling convention but I use them for now.
>
> I don't love the 'require gitadd.pl' but it's a gradual start...
>
> Cogito.pm seems to be a good place for the library stuff.
>
> git.pl
> passes everything to scripts except gitadd.pl
> works when called from somewhere other than the git dir
> I don't feel 100% about the fixup ports
>
> gitadd.pl
>
>
> I thought I'd ask for comments before I spent too much time on this...
>
> David
>
I only did my version which spits out the comments at the top of the
shell script as a quick hack.
This looks good to me. Keeping the docs near the developer is essential,
I think. Speaking of "I think", the name "cogito" was suggested for the
SCM layer, but IIRC Linus suggested staying with just plain git. Petr
suggested tig, perhaps because it looks at git from another point of view.
If we ever do decide to name the SCM layer (the git-pasky stuff) something
with "git inside", other choices are:
agitato Beethoven's "Moonlight Sonata" 3rd movment is "Presto agitato"
legit Since git is GPLv2, but perhaps a little too French.
regurgitate No comment neccessary.
Steven
^ permalink raw reply
* [PATCH] init-db.c: fix stupid typo
From: Zach Welch @ 2005-04-19 20:31 UTC (permalink / raw)
To: git
Fix a stupid typo from the last mkdir refactorng patch.
init-db.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Signed-Off-By: Zach Welch <zw@superlucidity.net>
--- a/init-db.c 2005-04-19 13:06:11.000000000 -0700
+++ a/init-db.c 2005-04-19 13:06:16.000000000 -0700
@@ -11,7 +11,7 @@
* be the judge. The default case is to have a DB per managed directory.
*/
-static void create_dir(char *path)
+static void create_dir(char *dir)
{
if (mkdir(dir, 0755) < 0) {
if (errno != EEXIST) {
There are 0 patches in this series:
^ permalink raw reply
* [PATCH] Better option parsing for gitdiff.sh
From: Pavel Roskin @ 2005-04-19 20:19 UTC (permalink / raw)
To: git
Hello!
This patch improves option handling for gitdiff.sh. Now "-p" doesn't
need to precede "-r", although all options still have to be placed
before the file names. Also, the patch introduces a minimal usage info
for the script.
The patch is against current git-pasky.
Signed-off-by: Pavel Roskin <proski@gnu.org>
--- a/gitdiff.sh
+++ b/gitdiff.sh
@@ -27,6 +27,13 @@ die () {
exit 1
}
+usage () {
+ echo "Usage:" >&2
+ echo " gitdiff.sh -r rev1:rev2 [FILES...]" >&2
+ echo " gitdiff.sh -r rev1 -r rev2 [FILES...]" >&2
+ exit 1
+}
+
diffqfile () {
dir=$1; shift
file=$1; shift
@@ -59,26 +66,44 @@ diffqueue () {
return $ret
}
-
-# FIXME: The commandline parsing is awful.
-
-if [ "$1" = "-p" ]; then
- shift
- parent=1
-fi
-
-if [ "$1" = "-r" ]; then
- shift
- id1=$(echo "$1": | cut -d : -f 1)
- [ "$id1" != "$1" ] && id2=$(echo "$1": | cut -d : -f 2)
- shift
-fi
-
-if [ "$1" = "-r" ]; then
- shift
- id2="$1"
- shift
-fi
+# Parsing the command line
+id1_set=
+id2_set=
+while true; do
+ case $1 in
+ -p)
+ parent=1
+ shift
+ ;;
+ -r)
+ if test "$id2_set"; then
+ echo "Too many revision numbers" 2>&1
+ usage
+ elif test "$id1_set"; then
+ shift
+ id2="$1"
+ id2_set=1
+ shift
+ else
+ shift
+ id1=$(echo "$1": | cut -d : -f 1)
+ id1_set=1
+ if test "$id1" != "$1"; then
+ id2=$(echo "$1": | cut -d : -f 2)
+ id2_set=1
+ fi
+ shift
+ fi
+ ;;
+ -*)
+ echo "Unknown option $1" 2>&1
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+done
if [ "$parent" ]; then
id2="$id1"
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Linus Torvalds @ 2005-04-19 20:20 UTC (permalink / raw)
To: Greg KH; +Cc: Git Mailing List, linux-kernel, sensors
In-Reply-To: <20050419194728.GA24367@kroah.com>
On Tue, 19 Apr 2005, Greg KH wrote:
>
> Ok, if you want some practice with "real" merges, feel free to merge from
> the following two trees whenever you are ready:
> kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2.6.git/
> for 11 aoe bugfix patches, and:
> kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/
> for 13 driver core, sysfs, and debugfs fixes.
Done, pushed out. Can you verify that the end result looks sane to you? I
just cheched that the diffstat looks similar (mine claims just 108 lines
changed in aoecmd.c - possibly due to different diff formats).
And yes, my new merge thing seems to have kept the index-cache much better
up-to-date, allowing an optimized checkout-cache -f -a to work and only
get the new files.
Pasky? Can you check my latest git stuff, notably read-tree.c and the
changes to git-pull-script?
Linus
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Greg KH @ 2005-04-19 19:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, linux-kernel, sensors
In-Reply-To: <Pine.LNX.4.58.0504191204480.19286@ppc970.osdl.org>
On Tue, Apr 19, 2005 at 12:40:44PM -0700, Linus Torvalds wrote:
> I'm still working out some performance issues with merges (the actual
> "merge" operation itself is very fast, but I've been trying to make the
> subsequent "update the working directory tree to the right thing" be much
> better).
Ok, if you want some practice with "real" merges, feel free to merge from
the following two trees whenever you are ready:
kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2.6.git/
for 11 aoe bugfix patches, and:
kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/
for 13 driver core, sysfs, and debugfs fixes.
The diffstats are:
aoe:
Documentation/aoe/mkdevs.sh | 1
Documentation/aoe/mkshelf.sh | 1
Documentation/aoe/todo.txt | 14 ++++
Documentation/aoe/udev-install.sh | 6 +-
drivers/block/aoe/aoe.h | 23 +++++--
drivers/block/aoe/aoeblk.c | 5 +
drivers/block/aoe/aoecmd.c | 110 ++++++++++++++++++++++----------------
drivers/block/aoe/aoedev.c | 8 +-
drivers/block/aoe/aoenet.c | 8 +-
9 files changed, 111 insertions(+), 65 deletions(-)
driver:
Documentation/kref.txt | 221 +++++++++++++++++++++++++++++++++++++++++-
drivers/base/class.c | 2
drivers/base/core.c | 3
drivers/base/firmware_class.c | 3
drivers/base/platform.c | 1
drivers/usb/host/hc_crisv10.c | 1
fs/partitions/check.c | 2
fs/sysfs/file.c | 35 ++++++
include/linux/debugfs.h | 14 +-
include/linux/sysfs.h | 7 +
lib/kobject.c | 7 -
net/bridge/br_sysfs_if.c | 2
scripts/ver_linux | 2
13 files changed, 290 insertions(+), 10 deletions(-)
No rush, but they should be good test for your merge speeds, as they are
based off of an older HEAD than your current one :)
> In other words, I want it to be at the point where people can do
>
> git pull <repo-address>
>
> and it will "just work", at least for people who don't have any local
> changes in their tree. None of this "check out all the files again" crap.
That would be very nice to have.
> But how about a plan that we go "live" tomorrow - assuming nobody finds
> any problems before that, of course.
That's fine with me.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] Parametrize installation directory
From: Pavel Roskin @ 2005-04-19 19:43 UTC (permalink / raw)
To: git
Hello!
It shouldn't be necessary to patch Makefile to specify where scripts
should be installed. This patch introduces a variable bindir for that
purpose. The name of the variable was chosen for compatibility with
projects using Automake.
For example, to install scripts to /usr/local/bin use:
make install bindir=usr/local/bin
Signed-off-by: Pavel Roskin <proski@gnu.org>
--- a/Makefile
+++ b/Makefile
@@ -12,6 +12,7 @@ CFLAGS=-g -O3 -Wall
CC=gcc
AR=ar
+bindir = $(HOME)/bin/
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
@@ -54,7 +55,7 @@ gitversion.sh: $(VERSION)
@chmod +x $@
install: $(PROG) $(GEN_SCRIPT)
- install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(HOME)/bin/
+ install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(bindir)
clean:
rm -f *.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [script] ge: export commits as patches
From: Petr Baudis @ 2005-04-19 19:41 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20050419185607.GA26756@elte.hu>
Dear diary, on Tue, Apr 19, 2005 at 08:56:07PM CEST, I got a letter
where Ingo Molnar <mingo@elte.hu> told me that...
> and please fix gitXnormid.sh to simply echo nothing and return with a -1
> exit value when a nonsensical ID is passed to it. Right now the output
> is quite ugly if you do 'ge blah'.
That's a feature; you can do || exit 1. Put its stderr to /dev/null if
you want your own error reporting.
BTW, I still think my gitpatch.sh is nicer. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Linus Torvalds @ 2005-04-19 19:40 UTC (permalink / raw)
To: Greg KH; +Cc: Greg KH, Git Mailing List, linux-kernel, sensors
In-Reply-To: <20050419185807.GA1191@kroah.com>
On Tue, 19 Apr 2005, Greg KH wrote:
>
> Nice, it looks like the merge of this tree, and my usb tree worked just
> fine.
Yup, it all seems to work out.
> So, what does this now mean? Is your kernel.org git tree now going to
> be the "real" kernel tree that you will be working off of now? Should
> we crank up the nightly snapshots and emails to the -commits list?
I'm not quite ready to consider it "real", but I'm getting there.
I'm still working out some performance issues with merges (the actual
"merge" operation itself is very fast, but I've been trying to make the
subsequent "update the working directory tree to the right thing" be much
better).
> Can I rely on the fact that these patches are now in your tree and I can
> forget about them? :)
>
> Just wondering how comfortable you feel with your git tree so far.
Hold off for one more day. I'm very comfortable with how well git has
worked out so far, and yes, mentally I consider this "the tree", but the
fact is, git isn't exactly easy on "normal users".
I think my merge stuff and Pasky's scripts are getting there, but I want
to make sure that we have a version of Pasky's scripts that use the new
"read-tree -m" optimizations to make tracking a tree faster, and I'd like
to have them _tested_ a bit first.
In other words, I want it to be at the point where people can do
git pull <repo-address>
and it will "just work", at least for people who don't have any local
changes in their tree. None of this "check out all the files again" crap.
But how about a plan that we go "live" tomorrow - assuming nobody finds
any problems before that, of course.
Linus
^ permalink raw reply
* Re: [script] ge: export commits as patches
From: Greg KH @ 2005-04-19 19:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: Ingo Molnar, git
In-Reply-To: <20050419170320.GG12757@pasky.ji.cz>
On Tue, Apr 19, 2005 at 07:03:20PM +0200, Petr Baudis wrote:
> Dear diary, on Tue, Apr 19, 2005 at 03:48:43PM CEST, I got a letter
> where Ingo Molnar <mingo@elte.hu> told me that...
> > is there any 'export commit as patch' support in git-pasky? I didnt find
> > any such command (maybe it got added meanwhile), so i'm using the 'ge'
> > hack below.
> >
> > e.g. i typically look at commits via 'git log', and then when i see
> > something interesting, i look at the commit via the 'ge' script. E.g.
> > "ge 834f6209b22af2941a8640f1e32b0f123c833061" done in the kernel tree
> > will output a particular commit's header and the patch.
>
> Nice idea. I will add it, probably as 'git patch'.
Ah, thanks for doing this. 'git patch' works great (but you might want
to mention in the 'help' that you can give the commit id for the patch,
if you don't want to see the HEAD patch.)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] Add help details to git help command. (This time with Perl)
From: David Greaves @ 2005-04-19 19:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Steven Cole, git
In-Reply-To: <20050419175051.GK12757@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
Petr Baudis wrote:
> Dear diary, on Tue, Apr 19, 2005 at 07:35:15PM CEST, I got a letter
> where Steven Cole <elenstev@mesatop.com> told me that...
>
I've been working on git.pl and getting help working nicely
things to try:
git.pl help
git.pl add
git.pl add --help
git.pl add --man
git.pl help add
The main objectives:
* get a reasonable perl code base in git.pl
* provide some way to document WTF is going on :)
* keep the docs near the developer
* allow variations in verbosity
* modularise
* don't use modules outside the base perl set
* allow a gentle migration (so start by calling the .sh's)
I don't like the pod2usage calling convention but I use them for now.
I don't love the 'require gitadd.pl' but it's a gradual start...
Cogito.pm seems to be a good place for the library stuff.
git.pl
passes everything to scripts except gitadd.pl
works when called from somewhere other than the git dir
I don't feel 100% about the fixup ports
gitadd.pl
I thought I'd ask for comments before I spent too much time on this...
David
--
[-- Attachment #2: Cogito.pm --]
[-- Type: application/x-perl, Size: 449 bytes --]
[-- Attachment #3: gitadd.pl --]
[-- Type: application/x-perl, Size: 1919 bytes --]
[-- Attachment #4: git.pl --]
[-- Type: application/x-perl, Size: 3681 bytes --]
^ permalink raw reply
* Re: [PATCH] write-tree performance problems
From: Linus Torvalds @ 2005-04-19 19:03 UTC (permalink / raw)
To: Chris Mason; +Cc: git
In-Reply-To: <200504191412.00227.mason@suse.com>
On Tue, 19 Apr 2005, Chris Mason wrote:
>
> Very true, you can't replace quilt with git without ruining both of them. But
> it would be nice to take a quilt tree and turn it into a git tree for merging
> purposes, or to make use of whatever visualization tools might exist someday.
Fair enough. The thing is, going from quilt->git really is a pretty "big
decision", since it's the decision that says "I will now really commit all
this quilt changes forever and ever".
Which is also why I think it's actually ok to take a minute to do 100
quilt patches. This is not something you do on a whim. It's something
you'd better think about. It's turning a very fluid environment into a
unchangable, final thing.
That said, I agree that "write-tree" is expensive. It tends to be by far
the most expensive op you normally do. I'll make sure it goes faster.
> We already have a "trust me, it hasn't changed" via update-cache.
Heh. I see "update-cache" not as a "it hasn't changed", but a "it _has_
changed, and now I want you to reflect that fact". In other words,
update-cache is an active statement: it says that you're ready to commit
your changes.
In contrast, to me your "write-tree" thing in many ways is the reverse of
that: it's saying "don't look here, there's nothing interesting there".
Which to me smells like trying to hide problems rather than being positive
about them.
Which it is, of course. It's trying to hide the fact that writing a tree
is not instantaenous.
> With that said, I hate the patch too. I didn't see how to compare against the
> old tree without reading each tree object from the old tree, and that should
> be slower then what write-tree does now.
Reading a tree is faster, simply because you uncompress instead of
compress. So I can read a tree in 0.28 seconds, but it takes me 0.34
seconds to write one. That said, reading the trees has disk seek issues if
it's not in the cache.
What I'd actually prefer to do is to just handle tree caching the same way
we handle file caching - in the index.
Ie we could have the index file track "what subtree is this directory
associated with", and have a "update-cache --refresh-dir" thing that
updates it (and any entry update in that directory obviously removes the
dir-cache entry).
Normally we'd not bother and it would never trigger, but it would be
useful for your scripted setup it would end up caching all the tree
information in a very efficient manner. Totally transparently, apart from
the one "--refresh-dir" at the beginning. That one would be slightly
expensive (ie would do all the stuff that "write-tree" does, but it would
be done just once).
(We could also just make "write-tree" do it _totally_ transparently, but
then we're back to having write-tree both read _and_ write the index file,
which is a situation that I've been trying to avoid. It's so much easier
to verify the correctness of an operation if it is purely "one-way").
I'll think about it. I'd love to speed up write-tree, and keeping track of
it in the index is a nice little trick, but it's not quite high enough up
on my worries for me to act on it right now.
But if you want to try to see how nasty it would be to add tree index
entries to the index file at "write-tree" time automatically, hey...
Linus
^ 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