* Re: Change "pull" to _only_ download, and "git update"=pull+merge?
From: David A. Wheeler @ 2005-04-19 22:39 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, Martin Schlemmer, David Greaves, git
In-Reply-To: <Pine.LNX.4.21.0504191245160.30848-100000@iabervon.org>
Daniel Barkalow wrote:
>See, I don't think you ever want to just pull. You want to
>pull-and-do-something, but the something could be any operation...
In a _logical_ sense that's true; I'd only want to pull data if I intended
to (possibly) do something with it. But as a _practical_ matter,
I can see lots of reasons for doing a pull as a separate operation.
One is disconnected operation; I may want to pull the data now, to
prepare for disconnectino, and then work later while disconnected.
Another is using lots of data compared to the pipesize; if I have a
dial-in modem, or I want the history of the linux kernel since 0.0.1,
I might want to "pull" & go away/go to sleep for the night. I might
use cron/at to automatically "pull" at 3am from some interesting branches.
The next day, I could then "pull" again to update just what changed,
and/or do the operation I intended to do if the operation auto-pulls the
missing data.
>I'm actually getting suspicious that the right thing is to hide "pull" in the id scheme. That is, instead of saying "linus" to refer to the
>"linus" head that you currently have, you say "+linus" to refer to the
>head Linus has on his server currently, and this will cause you to
>download anything necessary to perform the operation with the resulting value.
>
>
That's an interesting idea. I'll have to think about that.
What command would you suggest for the common case
of "update with current track?" I've proposed "git update [NAME]".
"git merge" with update-from-current-track as default seems unclear, and
I worry that I might accidentally press RETURN too soon & merge with
the wrong thing. And I like the idea of "git update" doing the same thing
(essentially) as "cvs update" and "svn update"; LOTS of people "know"
what update does, so using the same command name for one of the most
common operations smooths transition (GNU Arch's "tla update"
is almost, though not exactly, the same too.)
I still think it's important to have a very simple command that updates
your current branch with a tracked branch (because it's common to stay
in sync with a master branch), and a way to just download the data without
doing things with it YET (because you want to do things in stages).
The commands "update" and "pull" come to mind when thinking that way,
though as long as the commands are simple & clear that's a good thing
(I think it's a GOOD idea to use the same commands as CVS and
Subversion when the results are essentially the same, just because so many
people are already familiar with them, but only where it makes sense.)
--- David A. Wheeler
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Linus Torvalds @ 2005-04-19 22:38 UTC (permalink / raw)
To: Steven Cole; +Cc: Greg KH, Greg KH, Git Mailing List, linux-kernel, sensors
In-Reply-To: <426583D5.2020308@mesatop.com>
On Tue, 19 Apr 2005, Steven Cole wrote:
>
> 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.
Well, the real operations took only 15 seconds. What kind of horribe
person are you, that you don't have all of the kernel in your disk cache
already? Shame on you.
Or was the 4 minutes for downloading all the objest too?
Anyway, it looks like you are using pasky's scripts, and the old
"patch-based" upgrade at that. You certainly will _not_ see the
[many files patched]
patching file mm/mmap.c
..
if you use a real git merge. That's probable be the real problem here.
Real merges have no patches taking place _anywhere_. And they take about
half a second. Doing an "update" of your tree should _literally_ boil down
to
#
# "repo" needs to point to the repo we update from
#
rsync -avz --ignore-existing $repo/objects/. .git/objects/.
rsync -L $repo/HEAD .git/NEW_HEAD || exit 1
read-tree -m $(cat .git/NEW_HEAD) || exit 1
checkout-cache -f -a
update-cache --refresh
mv .git/NEW_HEAD .git/HEAD
and if it does anything else, it's literally broken. Btw, the above does
need my "read-tree -m" thing which I committed today.
(CAREFUL: the above is not a good script, because it _will_ just overwrite
all your old contents with the stuff you updated to. You should thus not
actually use something like this, but a "git update" should literally end
up doing the above operations in the end, and just add proper checking).
And if that takes 4 minutes, you've got problems.
Just say no to patches.
Linus
PS: If you want a clean tree without any old files or anything else, for
that matter, you can then do a "show-files -z --others | xargs -0 rm", but
be careful: that will blow away _anything_ that wasn't revision controlled
with git. So don't blame me if your pr0n collection is gone afterwards.
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Greg KH @ 2005-04-19 22:33 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050419222738.GA14566@nevyn.them.org>
On Tue, Apr 19, 2005 at 06:27:38PM -0400, Daniel Jacobowitz wrote:
> 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.
Well, somehow Gentoo sets this up properly, and I'm not using NIS. Hm,
my SuSE boxes on the other hand...
> 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.
Ick. Let's stick with Linus's patch for now...
thanks,
greg k-h
^ permalink raw reply
* Re: SHA1 hash safety
From: David Meybohm @ 2005-04-19 22:30 UTC (permalink / raw)
To: Andy Isaacson; +Cc: omb, git
In-Reply-To: <20050418074323.GA29765@hexapodia.org>
On Mon, Apr 18, 2005 at 12:43:23AM -0700, Andy Isaacson wrote:
>
> I'm not going to do the sums, but I would hazard a guess that it's more
> likely your PC suffered a cosmic-ray-induced memory fault - EACH OF THE
> FOUR TIMES YOU TESTED IT - causing it to report the same MD5, than that
> you actually discovered a collision with a measly million (or even
> hundred million) plaintexts.
But doesn't this require assuming the distribution of MD5 is uniform,
and don't the papers finding collisions in less show it's not? So, your
birthday-argument for calculating the probability wouldn't apply, because
it rests on the assumption MD5 is uniform, and it isn't.
For example, say most people are married in June, get pregnant, and
there are more births around March, 9 months later, than in other
months. Then if you are born in March you have a higher chance of seeing
a collision of your birthday with someone else's. The same is true for
someone else born in March too, and this makes the chances of seeing a
collision for the whole function higher.
^ permalink raw reply
* 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
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