* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Martin Schlemmer @ 2005-04-19 23:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504191539000.2274@ppc970.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]
On Tue, 2005-04-19 at 15:43 -0700, Linus Torvalds wrote:
>
> On Wed, 20 Apr 2005, Martin Schlemmer wrote:
> >
> > 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.
>
> I'll correct you.
>
> The fact is, that's not what people do. Not me, not kernel.org, not _any_
> of the machines I've got access to. They put the fully qualified name in
> the hostname, and just do "search foo.com" in /etc/resolv.conf.
>
> So clearly, expecting that people work the way you claim is being
> extremely optimistic. I'm sure some people do that too, but I suspect I'm
> in the majority. Both Fedora Core and YellowDog act the way I described,
> not the way you do..
>
The interesting bit you snipped was the part where you said you do not
know how to get dnsdomainname to work properly, and that I answered.
Why this other crap about how 90% of the world does it?
PS: If you have later tools, setting hostname to the FQDN and then still
adding 'domain' to resolv.conf seems to do the right thing, although it
did not some time back (and was why I said the bit about hostname only
containing the hostname, else you got something like 'hostname -f'
returning 'www1.foo.com.foo.com) ...
--
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 23:09 UTC (permalink / raw)
To: David Lang; +Cc: Chris Mason, git
In-Reply-To: <Pine.LNX.4.62.0504191557410.26365@qynat.qvtvafvgr.pbz>
On Tue, 19 Apr 2005, David Lang wrote:
>
> if you are useing quilt for locally developed patches I fully agree with
> you, but I was thinking of the case where Andrew is receiving independant
> patches from lots of people and storing them in quilt for testing, and
> then sending them on to you. In this case the patches really are
> independant and it may be useful to continue to treat them this way
> instead of collapsing them into one 'update from Andrew' feed.
If so, he should set up one repository per quilt patch.
That would be crazy, but yes, it would allow me to cherry-pick which
one(s) I want to merge with.
But the fact is, that cherry-picking should happen at quilt-time not at
git time.
Linus
^ permalink raw reply
* Re: Bug in merge-base
From: Daniel Barkalow @ 2005-04-19 23:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050419223420.GF9305@pasky.ji.cz>
On Wed, 20 Apr 2005, Petr Baudis wrote:
> Dear diary, on Wed, Apr 20, 2005 at 12:17:12AM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
>
> > I can think of. Are you sure there isn't another path to 5b53d3?
>
> I'm not. Actually there well might be.
>
> I think merge-base should never take a path which is effectively
> "upside-down" when a straight "upside" one is available.
>
> Hmm. So what I depended on for merge-base was that when doing it on A
> and B and A is predecessor of B, then it will always just return A. I
> will perhaps need to abuse rev-tree somehow for this then, it looks.
It is currently optimizing for the shortest longer path, but I guess it
should optimize for the shortest shorter path (i.e., the 0-length path
from A to itself always wins).
On the other hand, the date-based comparison (which you'd get with the
version I sent yesterday with [2/4] and [4/4]) would give you the most
recent common ancestor, which would necessarily avoid this situation.
Do you want to go with the date-based approach, or should I work out a
shortest shorter path algorithm?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [darcs-devel] Darcs and git: plan of action
From: Ray Lee @ 2005-04-19 23:06 UTC (permalink / raw)
To: Kevin Smith; +Cc: git, darcs-devel
In-Reply-To: <42658E38.1020406@qualitycode.com>
On Tue, 2005-04-19 at 19:03 -0400, Kevin Smith wrote:
> Pop quiz:
> Here is revision 1 of my file:
> abcde
>
> Here is revision 2:
> wow
> Now, did I do that with a darcs replace, or just by typing?
I'm still not communicating well.
Give me a case where assuming it's a replace will do the wrong thing,
for C code, where it's a variable or function name.
Ray
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Kenneth Johansson @ 2005-04-19 23:04 UTC (permalink / raw)
To: Greg KH; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050419223303.GB25966@kroah.com>
Greg KH wrote:
> 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...
I have to agree with Daniel on this one. The domainname is related to
nis and can be whatever you want it has nothing to do with DNS domains.
Similar to a realm in kerberos
This is how it's used both on debian and solaris(don't use much else)
and is consistent with Linus claim that it's common to have none.
^ permalink raw reply
* Re: [darcs-devel] Darcs and git: plan of action
From: Kevin Smith @ 2005-04-19 23:03 UTC (permalink / raw)
To: Ray Lee; +Cc: git, darcs-devel
In-Reply-To: <1113950442.29444.31.camel@orca.madrabbit.org>
Ray Lee wrote:
> On Mon, 2005-04-18 at 22:05 -0400, Kevin Smith wrote:
>
>>Notice that just by looking at my diffs, you can't tell that I used a
>>replace operation.
>
>
> Here's where we disagree. If you checkpoint your tree before the
> replace, and immediately after, the only differences in the
> source-controlled files would be due to the replace.
But I might have manually changed those tokens, or I might have done it
with a replace operation. Just looking at the diffs, those two cases
would look identical and be indistinguishable. The only way to know
whether or not a darcs replace was done was to look at the patch metadata.
Pop quiz:
Here is revision 1 of my file:
abcde
Here is revision 2:
wow
Now, did I do that with a darcs replace, or just by typing?
Kevin
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Petr Baudis @ 2005-04-19 23:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Cole, Greg KH, Greg KH, Git Mailing List, linux-kernel,
sensors
In-Reply-To: <Pine.LNX.4.58.0504191525290.2274@ppc970.osdl.org>
Dear diary, on Wed, Apr 20, 2005 at 12:38:17AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> Just say no to patches.
FYI, I've - per Junio's suggestion - made git merge's fast-forward to
apply show-diff output as a patch instead. This is roughly equal to
doing the sanity check against local changes, except that it handles
them, while at it. (Tree merge refuses to work when there are local
changes.)
--
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: Darcs and git: plan of action
From: Tupshin Harper @ 2005-04-19 23:00 UTC (permalink / raw)
To: Ray Lee; +Cc: git, Kevin Smith, darcs-devel
In-Reply-To: <1113950442.29444.31.camel@orca.madrabbit.org>
Ray Lee wrote:
>Here's where we disagree. If you checkpoint your tree before the
>replace, and immediately after, the only differences in the
>source-controlled files would be due to the replace.
>
This is assuming that you only have one replace and no other operations
recorded in the patch. If you have multiple replaces or a replace and a
traditional diff recorded in the same patch, then this is not true.
> And since the
>language of the file is known (and thereby the tokenization -- it *is*
>well-defined), then a tokenizer that compares the before and after trees
>(for just the files that changed, obviously), can discover what you did,
>and promote the mere ASCII diff into a token-replace diff. (The same
>sort of idea could be done for reindention, I'd hope.)
>
>
See above for one set of limitations on this. A more fundamental problem
comes back to intent. If I have a file "foo" before:
a1
a2
and after:
b1
b2
is that a "replace [_a-zA-Z0-9] a b foo" patch, or is that a
-a1
-a2
+b1
+b2
patch? Note that this comes down to heuristics, and no matter what you
use, you will be wrong sometimes, *and* the choice that is made can
substantively affect the contents of the repository after additional
patches are applied.
>We agree on everything except that it's provable that one can discover a
>replace operation, given a before and after tree.
>
>
It's provable that you can not.
-Tupshin
^ permalink raw reply
* Re: [PATCH] write-tree performance problems
From: David Lang @ 2005-04-19 23:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Chris Mason, git
In-Reply-To: <Pine.LNX.4.58.0504191514550.2274@ppc970.osdl.org>
On Tue, 19 Apr 2005, Linus Torvalds wrote:
> 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.
if you are useing quilt for locally developed patches I fully agree with
you, but I was thinking of the case where Andrew is receiving independant
patches from lots of people and storing them in quilt for testing, and
then sending them on to you. In this case the patches really are
independant and it may be useful to continue to treat them this way
instead of collapsing them into one 'update from Andrew' feed.
I don't know if this sort of thing happens enough to matter or not.
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: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Petr Baudis @ 2005-04-19 22:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Steven Cole, Linus Torvalds, Greg KH, Greg KH, Git Mailing List,
linux-kernel, sensors
In-Reply-To: <7vpswqpes1.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Apr 20, 2005 at 12:45:02AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>
> PB> I'm wondering if doing
>
> PB> if [ "$(show-diff)" ]; then
> PB> git diff | git apply
> PB> else
> PB> checkout-cache -f -a
> PB> fi
>
> PB> would actually buy us some time; or, how common is it for people to have
> PB> no local changes whatsoever, and whether relative slowdown of additional
> PB> show-diff to git diff would actually matter.
>
> "show-diff -s" perhaps. Also wouldn't it be faster to pipe
> show-diff output (not git diff output) to patch (not git apply)?
Excellent idea, thanks. Changed git merge to do this.
--
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: [script] ge: export commits as patches
From: David A. Wheeler @ 2005-04-19 22:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: Ingo Molnar, git
In-Reply-To: <20050419170320.GG12757@pasky.ji.cz>
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?
>>
>>
>
>Nice idea. I will add it, probably as 'git patch'.
>
>
>
Eek!
It's a nice idea, and it'd be great as a subcommand. But PLEASE
don't name it "patch". I already know what "patch" does, "patch"
ACCEPTS a patch... it doesn't create one ;-).
How about naming it "aspatch" or "asdiff" instead? Or something else
(good names, anyone?).
<soapbox_to_choir>Good externally-viewed names are critical... good
command names that are similar to what people "already know"
can really help make the tool a joy to use.</soapbox_to_choir>
--- David A. Wheeler
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Lars Fenneberg @ 2005-04-19 22:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504191449270.2274@ppc970.osdl.org>
Hi all!
Quoting Linus Torvalds (torvalds@osdl.org):
> 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.
I don't think getdomainname should be used at all in this case as it is the
domain name used by NIS and it might be different from the DNS domain name
in the FQDN associated with a given host. I just looked into the domainname
manual page and it agrees with me:
domainname, nisdomainname, ypdomainname will print the name of the
system as returned by the getdomainname(2) function. This is also known as
the YP/NIS domain name of the system.
That's why it is set to "(none)" (i.e. its not setup at all) on most hosts
because if they're not running NIS it's not really needed.
To get the FQDN which is what we want you'd have to use something like
this:
#include <netdb.h>
#include <unistd.h>
char *getfqdn(void)
{
static char hostname[HOST_NAME_MAX + 1];
struct hostent *hp;
if (gethostname(hostname, sizeof(hostname)) < 0)
{
/* error handling */
}
if (!(hp = gethostbyname(hostname)))
{
/* just return the possibly unqualified hostname */
return hostname;
}
return hp->h_name;
}
Cheers,
Lars.
--
Lars Fenneberg, lf@elemental.net (private), lf@mcs.de (work)
^ permalink raw reply
* Re: SHA1 hash safety
From: C. Scott Ananian @ 2005-04-19 22:48 UTC (permalink / raw)
To: David Meybohm; +Cc: Andy Isaacson, omb, git
In-Reply-To: <20050419223027.GA26100@localhost>
On Tue, 19 Apr 2005, David Meybohm wrote:
> 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.
No, the collision papers don't show this at all.
--scott
atomic strategic HBDRILL SARANAC COBRA JUDY Ft. Meade assassination politics
Mossad HOPEFUL ZPSEMANTIC DTFROGS HTKEEPER LITEMPO LIONIZER operation
( http://cscott.net/ )
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Linus Torvalds @ 2005-04-19 22:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Greg KH, Git Mailing List, linux-kernel, sensors
In-Reply-To: <20050419223945.GG9305@pasky.ji.cz>
On Wed, 20 Apr 2005, Petr Baudis wrote:
>
> I will probably not buy git-export, though. (That is, it is merged, but
> I won't make git frontend for it.) My "git export" already does
> something different, but more importantly, "git patch" of mine already
> does effectively the same thing as you do, just for a single patch; so I
> will probably just extend it to do it for an (a,b] range of patches.
That's fine. It was a quick hack, just to show that if somebody wants to,
the data is trivially exportable.
Linus
^ permalink raw reply
* Re: [PATCH] write-tree performance problems
From: C. Scott Ananian @ 2005-04-19 22:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Chris Mason, git
In-Reply-To: <Pine.LNX.4.58.0504191017300.19286@ppc970.osdl.org>
On Tue, 19 Apr 2005, Linus Torvalds wrote:
> (*) Actually, I think it's the compression that ends up being the most
> expensive part.
You're also using the equivalent of '-9', too -- and *that's slow*.
Changing to Z_NORMAL_COMPRESSION would probably help a lot
(but would break all existing repositories, sigh).
--scott
DES WTO Indonesia NRA LCPANGS supercomputer plastique class struggle
AEFOX Pakistan ODEARL Secretary KUGOWN Cheney ODIBEX SDI AP JMMADD
( http://cscott.net/ )
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Linus Torvalds @ 2005-04-19 22:47 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Greg KH, Git Mailing List
In-Reply-To: <20050419222738.GA14566@nevyn.them.org>
On Tue, 19 Apr 2005, Daniel Jacobowitz wrote:
>
> 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.
Hah. I'll just commit my patch, and for any setup where that doesn't work,
people can set COMMIT_AUTHOR_EMAIL by hand.
Linus
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Junio C Hamano @ 2005-04-19 22:45 UTC (permalink / raw)
To: Petr Baudis
Cc: Steven Cole, Linus Torvalds, Greg KH, Greg KH, Git Mailing List,
linux-kernel, sensors
In-Reply-To: <20050419222609.GE9305@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> I'm wondering if doing
PB> if [ "$(show-diff)" ]; then
PB> git diff | git apply
PB> else
PB> checkout-cache -f -a
PB> fi
PB> would actually buy us some time; or, how common is it for people to have
PB> no local changes whatsoever, and whether relative slowdown of additional
PB> show-diff to git diff would actually matter.
"show-diff -s" perhaps. Also wouldn't it be faster to pipe
show-diff output (not git diff output) to patch (not git apply)?
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Linus Torvalds @ 2005-04-19 22:43 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: Greg KH, Git Mailing List
In-Reply-To: <1113949783.2129.4.camel@nosferatu.lan>
On Wed, 20 Apr 2005, Martin Schlemmer wrote:
>
> 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.
I'll correct you.
The fact is, that's not what people do. Not me, not kernel.org, not _any_
of the machines I've got access to. They put the fully qualified name in
the hostname, and just do "search foo.com" in /etc/resolv.conf.
So clearly, expecting that people work the way you claim is being
extremely optimistic. I'm sure some people do that too, but I suspect I'm
in the majority. Both Fedora Core and YellowDog act the way I described,
not the way you do..
Linus
^ permalink raw reply
* Re: Darcs and git: plan of action
From: Ray Lee @ 2005-04-19 22:40 UTC (permalink / raw)
To: Kevin Smith; +Cc: git, darcs-devel
In-Reply-To: <4264677A.9090003@qualitycode.com>
(Sorry for the delayed reply -- I'm living on tape delay for a bit.)
On Mon, 2005-04-18 at 22:05 -0400, Kevin Smith wrote:
> >>>>The other is "replace very instace of identifier `foo` with identifier`bar`".
> >>>
> >>>That could be derived, however, by a particularly smart parser [1].
> >>
> >>No, it can't. Seriously. A darcs replace patch is encoded as rules, not
> >>effects, and it is impossible to derive the rules just by looking at the
> >>results. Not difficult. Impossible.
> >
> > If I do a token replace in an editor (say one of those fancy new-fangled
> > refactoring thangs, or good ol' vi), a token-level comparator can
> > discover what I did. That link I sent is an example of one such beast.
>
> The big feature of a darcs replace patch is that it works forward and
> backward in time.
That's *not* a feature of the token replace patch, however. That's a
feature of the darcs commutation machinery, correct? (With the obvious
caveat that darcs can only *do* the commutation if it has correctly
nuanced darcs-style token replace patches, rather than mere ASCII
textual diffs.)
> 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
Okay, that all makes sense.
> Notice that just by looking at my diffs, you can't tell that I used a
> replace operation.
Here's where we disagree. If you checkpoint your tree before the
replace, and immediately after, the only differences in the
source-controlled files would be due to the replace. And since the
language of the file is known (and thereby the tokenization -- it *is*
well-defined), then a tokenizer that compares the before and after trees
(for just the files that changed, obviously), can discover what you did,
and promote the mere ASCII diff into a token-replace diff. (The same
sort of idea could be done for reindention, I'd hope.)
> 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.
Well yes, that's exactly what we want. And the key point of all of this
is that there's no magic here. The darcs machinery does all the
commutations such that the patches can wiggle together without
conflicts. To do it's job, of course, it needs nuanced patches, rather
than the quite literal ones generated by diff.
We agree on everything except that it's provable that one can discover a
replace operation, given a before and after tree.
> Now, I should mention here that I personally dislike the replace
> operation, and I think it is more dangerous than helpful. However, other
> darcs users are quite happy with it, and it certainly is a creative and
> powerful feature.
It's creative alright, though I had the same misgivings. In my common
code workflow, I almost never have global tokens -- all my replaces
would be per function, so I never saw an opportunity to use it when I
was screwing around with darcs.
> Other creative patch types have also been dreamed of. For example, a
> powerful language-specific refactoring operation has been discussed as a
> far-future possibility. That would be safe, and cool.
<subliminal> indention patch type, indention patch type... </subliminal>
> > > Automated refactoring tools, for example, perform the
> > > rename+modify as an atomic operation.
> > [...]
> Although there are no such nifty refactoring tools available today, they
> will exist at some point.
Yeah, I spent some time drooling over the refactoring editors before
slapping myself and deciding I'd wait for others to live on that
bleeding edge for a while. I've had to clean up too much code from other
people.
> Even without tools, many shops have policies against checking in code
> that won't compile. If you rename a java class, you must simultaneously
> perform the rename and modify the class name inside. If you commit
> between those steps, it's broken.
I'm trying hard to find a nice way to say that's silly. I'm failing. My
suggestion in that case would be that the local coder commit many
patches to a local repository, one of which is the rename. Then upon
completion of the refactoring, the set of patches is committed to the
group repository. Tags before and after preserve the repository's
precondition that it always compiles.
> [I do realize that the kernel doesn't have java code, by the way.]
Don't worry, I didn't think that you did :-).
Ray
^ permalink raw reply
* Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Petr Baudis @ 2005-04-19 22:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, Git Mailing List, linux-kernel, sensors
In-Reply-To: <Pine.LNX.4.58.0504191316180.19286@ppc970.osdl.org>
Dear diary, on Tue, Apr 19, 2005 at 10:20:47PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> Pasky? Can you check my latest git stuff, notably read-tree.c and the
> changes to git-pull-script?
I've made git merge to use read-tree -m, HTH.
I will probably not buy git-export, though. (That is, it is merged, but
I won't make git frontend for it.) My "git export" already does
something different, but more importantly, "git patch" of mine already
does effectively the same thing as you do, just for a single patch; so I
will probably just extend it to do it for an (a,b] range of patches.
--
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: 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
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