[RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

2014-01-22 Thread Linus Torvalds
From: Linus Torvalds torva...@linux-foundation.org Date: Wed, 22 Jan 2014 12:32:30 -0800 Subject: [PATCH] Make 'git request-pull' more strict about matching local/remote branches The current 'request-pull' will try to find matching commit on the given remote, and rewrite the please pull line

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

2014-01-22 Thread Linus Torvalds
On Wed, Jan 22, 2014 at 1:46 PM, Junio C Hamano gits...@pobox.com wrote: The new find local ref code will also complain loudly if you give an ambiguous refname (eg you have both a tag and a branch with that same name, and you don't specify heads/name or tags/name). But this part might be a

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

2014-01-22 Thread Linus Torvalds
On Wed, Jan 22, 2014 at 2:03 PM, Linus Torvalds torva...@linux-foundation.org wrote: Any ideas? The hacky way is to do | head -1 to take the first show-ref output, and then check if you get a different result if you re-do it using show-ref --tags. But that sounds really excessively hacky

Re: [RFC PATCH] Make 'git request-pull' more strict about matching local/remote branches

2014-01-22 Thread Linus Torvalds
On Wed, Jan 22, 2014 at 2:14 PM, Junio C Hamano gits...@pobox.com wrote: I looked at 5150.4 and found that what it attempts to do is halfway sensible. I agree that it is half-way sensible. The important bit being the HALF part. The half part is why we have the semantics we have. There's no

[RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote

2014-01-22 Thread Linus Torvalds
From: Linus Torvalds torva...@linux-foundation.org Date: Wed, 22 Jan 2014 15:23:48 -0800 Subject: [PATCH] Make request-pull able to take a refspec of form local:remote This allows a user to say that a local branch has a different name on the remote server, using the same syntax that git push

Re: [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote

2014-01-23 Thread Linus Torvalds
On Thu, Jan 23, 2014 at 11:43 AM, Junio C Hamano gits...@pobox.com wrote: I am not sure if it is a good idea to hand-craft resulting head is unique constraint here. We already have disambiguation rules (and warning mechanism) we use in other places---this part should use the same rule, I

Re: [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote

2014-01-23 Thread Linus Torvalds
On Thu, Jan 23, 2014 at 2:58 PM, Junio C Hamano gits...@pobox.com wrote: Will be fine, provided if they always use local:remote syntax, I'd agree. Why? No sane user should actually need to use the local:remote syntax. The normal situation should be that you create the correctly named branch

Re: Re* [RFC PATCH 2/1] Make request-pull able to take a refspec of form local:remote

2014-01-29 Thread Linus Torvalds
On Wed, Jan 29, 2014 at 3:34 PM, Junio C Hamano gits...@pobox.com wrote: I am not yet doing the docs, but here is a minimal (and I think is the most sensible) fix to the If I asked a tag to be pulled, I used to get the message from the tag in the output---the updated code no longer does so

Odd git diff breakage

2014-03-31 Thread Linus Torvalds
I hit this oddity when not remembering the right syntax for --color-words.. Try this (outside of a git repository): touch a b git diff -u --color=words a b and watch it scroll (infinitely) printing out error: option `color' expects always, auto, or never forever. I haven't tried to

Re: Odd git diff breakage

2014-03-31 Thread Linus Torvalds
On Mon, Mar 31, 2014 at 11:30 AM, Junio C Hamano gits...@pobox.com wrote: Hmph, interesting. outside a repository is the key, it seems. Well, you can do it inside a repository too, but then you need to use the --no-index flag to get the diff two files behavior. It will result in the same

Re: [PATCH] diff-no-index: correctly diagnose error return from diff_opt_parse()

2014-03-31 Thread Linus Torvalds
On Mon, Mar 31, 2014 at 11:47 AM, Junio C Hamano gits...@pobox.com wrote: Instead, make it act like so: $ git diff --no-index --color=words a b error: option `color' expects always, auto, or never fatal: invalid diff option/value: --color=words Thanks,

Re: Sources for 3.18-rc1 not uploaded

2014-10-20 Thread Linus Torvalds
:00:00 2001 From: Linus Torvalds torva...@linux-foundation.org Date: Mon, 20 Oct 2014 08:21:38 -0700 Subject: [PATCH] Don't use the default 'tar.umask' for pax headers That wasn't the original behavior, and doing so breaks the fact that tar-files are bit-for-bit compatible across git versions

Re: Sources for 3.18-rc1 not uploaded

2014-10-20 Thread Linus Torvalds
On Mon, Oct 20, 2014 at 3:28 PM, brian m. carlson sand...@crustytoothpaste.net wrote: It doesn't appear that the stability of git archive --format=tar is documented anywhere. Given that, it doesn't seem reasonable to expect that any tar implementation produces bit-for-bit compatible output

Re: Sources for 3.18-rc1 not uploaded

2014-10-21 Thread Linus Torvalds
On Tue, Oct 21, 2014 at 1:08 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: Unfortunately, the git archive doc clearly says that the umask is applied to all archive entries. And that clearly wasn't the case (for extended metadata headers) before Brian's fix. Hey, it's time for another

Re: [PATCH v4] compat: Fix read() of 2GB and more on Mac OS X

2013-08-19 Thread Linus Torvalds
On Mon, Aug 19, 2013 at 8:41 AM, Steffen Prohaska proha...@zib.de wrote: The reason was that read() immediately returns with EINVAL if nbyte = 2GB. According to POSIX [1], if the value of nbyte passed to read() is greater than SSIZE_MAX, the result is implementation-defined. Yeah, the OS X

Re: [PATCH v4] compat: Fix read() of 2GB and more on Mac OS X

2013-08-19 Thread Linus Torvalds
On Mon, Aug 19, 2013 at 10:16 AM, Junio C Hamano gits...@pobox.com wrote: Linus Torvalds torva...@linux-foundation.org writes: The same argument applies to xwrite(), but currently we explicitly catch EINTR and EAGAIN knowing that on sane systems these are the signs that we got interrupted

Re: [PATCH v4] compat: Fix read() of 2GB and more on Mac OS X

2013-08-19 Thread Linus Torvalds
On Mon, Aug 19, 2013 at 2:56 PM, Kyle J. McKay mack...@gmail.com wrote: The fact that the entire file is read into memory when applying the filter does not seem like a good thing (see #7-#10 above). Yeah, that's horrible. Its likely bad for performance too, because even if you have enough

Re: [PATCH/RFC] Developer's Certificate of Origin: default to COPYING

2013-09-12 Thread Linus Torvalds
On Thu, Sep 12, 2013 at 3:30 PM, Junio C Hamano gits...@pobox.com wrote: Linus, this is not limited to us, so I am bothering you; sorry about that. My instinct tells me that some competent lawyers at linux-foundation helped you with the wording of DCO, and we amateurs shouldn't be mucking

Re: [PATCH/RFC] Developer's Certificate of Origin: default to COPYING

2013-09-12 Thread Linus Torvalds
On Thu, Sep 12, 2013 at 4:15 PM, Richard Hansen rhan...@bbn.com wrote: Is it worthwhile to poke a lawyer about this as a precaution? (If so, who?) Or do we wait for a motivating event? I can poke the lawyer that was originally involved. If people know other lawyers, feel free to poke them

Re: [PATCH] git-compat-util: Avoid strcasecmp() being inlined

2013-09-13 Thread Linus Torvalds
On Fri, Sep 13, 2013 at 12:53 PM, Sebastian Schuberth sschube...@gmail.com wrote: +#ifdef __MINGW32__ +#ifdef __NO_INLINE__ Why do you want to push this insane workaround for a clear Mingw bug? Please have mingw just fix the nasty bug, and the git patch with the trivial wrapper looks much

Re: [GIT PULL] sound fixes for 3.6-rc6

2012-09-13 Thread Linus Torvalds
On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai ti...@suse.de wrote: are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus *PLEASE* don't do this. You point to a branch, but then the pull request clearly implies there is a tag with

mailinfo: don't require text mime type for attachments

2012-09-30 Thread Linus Torvalds
attachments. If somebody really cares, and determines that some attachment is binary data (by looking at the data, not the MIME-type), the whole attachment should be dismissed, rather than fed in random-sized chunks to handle_filter(). Signed-off-by: Linus Torvalds torva...@linux-foundation.org

Fix git diff --stat for interesting - but empty - file changes

2012-10-17 Thread Linus Torvalds
. With no changes at all, git diff --stat output was empty. With just a chmod, it said 0 files changed. No way is our legacy behavior sane. Signed-off-by: Linus Torvalds torva...@linux-foundation.org --- This was triggered by kernel developers not noticing that they had added zero-sized files

Re: Fix git diff --stat for interesting - but empty - file changes

2012-10-17 Thread Linus Torvalds
On Wed, Oct 17, 2012 at 11:28 AM, Junio C Hamano gits...@pobox.com wrote: I think listing a file whose content remain unchanged with 0 as the number of lines affected makes sense, and it will mesh well with Duy's http://thread.gmane.org/gmane.comp.version-control.git/207749 I first

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

2012-10-23 Thread Linus Torvalds
On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner t...@linutronix.de wrote: It is spelled: git notes add -m comment SHA1 Cool! Don't use them for anything global. Use them for local codeflow, but don't expect them to be distributed. It's a separate flow, and while it *can* be

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

2012-10-23 Thread Linus Torvalds
On Wed, Oct 24, 2012 at 4:56 AM, Al Viro v...@zeniv.linux.org.uk wrote: How about git commit --allow-empty, with belated ACK for commit Don't bother. It's not that important, and it's just distracting. It's not like this is vital information. If you pushed it out without the ack, it's out

Re: first parent, commit graph layout, and pull merge direction

2013-05-23 Thread Linus Torvalds
On Thu, May 23, 2013 at 3:11 PM, Junio C Hamano gits...@pobox.com wrote: If the proposal were to make pull.rebase the default at a major version bump and force all integrators and other people who are happy with how pull = fetch + merge (not fetch + rebase) works to say pull.rebase = false in

Re: first parent, commit graph layout, and pull merge direction

2013-05-23 Thread Linus Torvalds
On Thu, May 23, 2013 at 5:21 PM, Junio C Hamano gits...@pobox.com wrote: I would assume that no-ff above was meant to be --ff-only from the first part of the message. Yeah, I may need more coffee.. I also would assume that I can rephrase that setting pull.merge (which does not exist) as

Re: New feature discussion: git rebase --status

2013-06-11 Thread Linus Torvalds
On Tue, Jun 11, 2013 at 10:18 AM, Hilco Wijbenga hilco.wijbe...@gmail.com wrote: Having git status display (even more) context sensitive information during git rebase or git merge would be very welcome. Please, if at all possible, don't make that a separate command. I agree. The rebase state

Re: [PATCH] build: get rid of the notion of a git library

2013-06-11 Thread Linus Torvalds
On Tue, Jun 11, 2013 at 11:06 AM, Felipe Contreras felipe.contre...@gmail.com wrote: Moreover, if you are going to argue that we shouldn't be closing the door [...] Felipe, you saying if you are going to argue ... to anybody else is kind of ironic. Why is it every thread I see you in, you're

Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace

2012-11-13 Thread Linus Torvalds
On Tue, Nov 13, 2012 at 11:15 AM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: Linus, do you remember if you left them out on purpose? Umm, no. I have to wonder why you care? As far as I'm concerned, the only valid space is space, TAB and CR/LF. Anything else is *noise*, not space. What's

Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace

2012-11-13 Thread Linus Torvalds
On Tue, Nov 13, 2012 at 11:40 AM, Linus Torvalds torva...@linux-foundation.org wrote: I have to wonder why you care? As far as I'm concerned, the only valid space is space, TAB and CR/LF. Anything else is *noise*, not space. What's the reason for even caring? Btw, expanding the whitespace

Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum

2013-01-17 Thread Linus Torvalds
On Thu, Jan 17, 2013 at 3:00 AM, John Keeping j...@keeping.me.uk wrote: There's also a warning that triggers with clang 3.2 but not clang trunk, which I think is a legitimate warning - perhaps someone who understands integer type promotion better than me can explain why the code is OK

Re: [PATCH 2/2] fix clang -Wtautological-compare with unsigned enum

2013-01-18 Thread Linus Torvalds
On Fri, Jan 18, 2013 at 9:15 AM, Phil Hord phil.h...@gmail.com wrote: Yes, I can tell by the wording of the error message that you are right and clang has a problem. But the git code it complained about does have a real problem, because the result of signed int a = ULONG_MAX is

Re: [PULL] Module fixes, and a virtio block fix.

2013-01-20 Thread Linus Torvalds
On Sun, Jan 20, 2013 at 5:32 PM, Rusty Russell ru...@rustcorp.com.au wrote: Due to the delay on git.kernel.org, git request-pull fails. It *looks* like it succeeds, except the warning, but (as we learned last time I screwed up), it doesn't put the branchname because it can't know. I think

Re: [PULL] Module fixes, and a virtio block fix.

2013-01-20 Thread Linus Torvalds
On Sun, Jan 20, 2013 at 6:00 PM, Junio C Hamano gits...@pobox.com wrote: What you mean by corrupt is not clear to me Some versions would just silently change the actual name you were using. So if you said for-linus, it might change it to linus, just because that branch happened to have the

Re: [PULL] Module fixes, and a virtio block fix.

2013-01-20 Thread Linus Torvalds
On Sun, Jan 20, 2013 at 6:57 PM, Rusty Russell ru...@rustcorp.com.au wrote: I'm confused. The default argument is HEAD: what does it know about tag names? Ugh. I actually thought that if you give it the tag name directly (as the end) it will use that. But no. It figures it out with git

Re: linux-next: unneeded merge in the security tree

2013-03-12 Thread Linus Torvalds
[ Added Junio and git to the recipients, and leaving a lot of stuff quoted due to that... ] On Mon, Mar 11, 2013 at 9:16 PM, Theodore Ts'o ty...@mit.edu wrote: On Tue, Mar 12, 2013 at 03:10:53PM +1100, James Morris wrote: On Tue, 12 Mar 2013, Stephen Rothwell wrote: The top commit in the

Re: linux-next: unneeded merge in the security tree

2013-03-12 Thread Linus Torvalds
On Tue, Mar 12, 2013 at 2:20 PM, Theodore Ts'o ty...@mit.edu wrote: What if we added the ability to do something like this: [remote origin] url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git fetch = +refs/heads/master:refs/heads/master

Re: linux-next: unneeded merge in the security tree

2013-03-12 Thread Linus Torvalds
On Tue, Mar 12, 2013 at 2:47 PM, Junio C Hamano gits...@pobox.com wrote: I agree that --ff-only thing is too strict and sometimes you would want to allow back-merges, but when you do allow such a back-merge, is there a reason you want it to be --no-signatures merge? When a subtree maintainer

Re: git status takes 30 seconds on Windows 7. Why?

2013-03-27 Thread Linus Torvalds
On Wed, Mar 27, 2013 at 12:04 PM, Jeff King p...@peff.net wrote: Yes, I think that's pretty much the case (though most of my Git-on-Windows experience is from cygwin long ago, where the stat performance was truly horrendous). Have you tried setting core.preloadindex, which should run the

Re: git status takes 30 seconds on Windows 7. Why?

2013-03-27 Thread Linus Torvalds
On Wed, Mar 27, 2013 at 1:00 PM, Junio C Hamano gits...@pobox.com wrote: Given that we haven't tweaked the parallelism or thread-cost parameters since the inception of the mechanism in Nov 2008, I suspect that we would see praises from some and grievances from other corners of the user base

Re: Handling renames.

2005-04-14 Thread Linus Torvalds
On Thu, 14 Apr 2005, David Woodhouse wrote: I've been looking at tracking file revisions. One proposed solution was to have a separate revision history for individual files, with a new kind of 'filecommit' object which parallels the existing 'commit', referencing a blob instead of a tree.

Re: Re: Re: write-tree is pasky-0.4

2005-04-15 Thread Linus Torvalds
On Fri, 15 Apr 2005, Daniel Barkalow wrote: Is there some reason you don't commit before merging? All of the current merge theory seems to want to merge two commits, using the information git keeps about them. Note that the 3-way merge would _only_ merge the committed state. The thing is,

Re: Re: Add clone support to lntree

2005-04-15 Thread Linus Torvalds
On Sat, 16 Apr 2005, Petr Baudis wrote: I'm wondering, whether each tree should be fixed to a certain branch. I'm wondering why you talk about branches at all. No such thing should exist. There are no branches. There are just repositories. You can track somebody elses repository, but you

Re: [PATCH 3/2] merge-trees script for Linus git

2005-04-15 Thread Linus Torvalds
On Fri, 15 Apr 2005, Junio C Hamano wrote: I'd take the hint, but I would say the current Perl version would be far more usable than the C version I would come up with by the end of this weekend because: Actually, it turns out that I have a cunning plan. I'm full of cunning plans, in

Re: [PATCH 3/2] merge-trees script for Linus git

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Junio C Hamano wrote: LT NOTE NOTE NOTE! I could make read-tree do some of these nontrivial LT merges, but I ended up deciding that only the matches in all three LT states thing collapses by default. * Understood and agreed. Having slept on it, I think I'll merge

Re: [PATCH 3/2] merge-trees script for Linus git

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Linus Torvalds wrote: Having slept on it, I think I'll merge all the trivial cases that don't involve a file going away or being added. Ie if the file is in all three trees, but it's the same in two of them, we know what to do. Junio, I pushed this out, along

Re: full kernel history, in patchset format

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Ingo Molnar wrote: i've converted the Linux kernel CVS tree into 'flat patchset' format, which gave a series of 28237 separate patches. (Each patch represents a changeset, in the order they were applied. I've used the cvsps utility.) the history data starts at

Re: full kernel history, in patchset format

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Thomas Gleixner wrote: One remark on the tree blob storage format. The binary storage of the sha1sum of the refered object is a PITA for scripting. Converting the ASCII - binary for the sha1sum comparision should not take much longer than the binary - ASCII

Re: full kernel history, in patchset format

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Thomas Gleixner wrote: For the export stuff its terrible slow. :( I don't really see your point. If you already know what the tree is like you say, you don't care about the tree object. And if you don't know what the tree is, what _are_ you doing? In other words, show

Re: [PATCH] update-cache --refresh cache entry leak

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Junio C Hamano wrote: When update-cache --refresh replaces an existing cache entry with a new one, it forgets to free the original. I've seen this patch now three times, and it's been wrong every single time. Maybe we should add a comment? That active-cache entry you

Re: [PATCH] Use libcurl to use HTTP to get repositories

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Paul Jackson wrote: Daniel wrote: I'm working off of Linus's tree when not working on scripts, and it doesn't have that section at all. Ah so - nevermind my README comments then. Well, actually, I suspect that something like this should go to Pasky. I really see my

Re: Storing permissions

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Paul Jackson wrote: Morten wrote: It makes some sense in principle, but without storing what they mean (i.e., group==?) it certainly makes no sense. There's no they there. I think Martin's proposal, to which I agreed, was to store a _single_ bit. If any of the

Re: Issues with higher-order stages in dircache

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Junio C Hamano wrote: I am wondering if you have a particular reason not to do the same for the removing half. No. Except for me being silly. Please just make it so. Also do you have any comments on this one from the same message? * read-tree - When merging

Re: Storing permissions

2005-04-16 Thread Linus Torvalds
On Sat, 16 Apr 2005, Linus Torvalds wrote: Anybody want to send a patch to do this? Actually, I just did it. Seems to work for the only test-case I tried, namely I just committed it, and checked that the permissions all ended up being recorded as 0644 in the tree (if it has the -x bit set

Re: Parseable commit header

2005-04-17 Thread Linus Torvalds
On Sun, 17 Apr 2005, Stefan-W. Hahn wrote: after playing a while with git-pasky it is a crap to interpret the date of commit logs. Though it was a good idea to put the date in a parseable format (seconds since), but the format of the commit itself is not good parseable. Actually, it is.

Re: Storing permissions

2005-04-17 Thread Linus Torvalds
On Sun, 17 Apr 2005, David A. Wheeler wrote: There's a minor reason to write out ALL the perm bit data, but only care about a few bits coming back in: Some people use SCM systems as a generalized backup system Yes. I was actually thinking about having system config files in a git

Re: using git directory cache code in darcs?

2005-04-17 Thread Linus Torvalds
On Sun, 17 Apr 2005, David Roundy wrote: That's all right. Darcs would only access the cached data through a git-caching layer, and we've already got an abstraction layer over the pristine cache. As long as the git layer can quickly retrieve the contents of a given file, we should be

Re: Re-done kernel archive - real one?

2005-04-17 Thread Linus Torvalds
On Sun, 17 Apr 2005, Russell King wrote: On Sat, Apr 16, 2005 at 04:01:45PM -0700, Linus Torvalds wrote: So I re-created the dang thing (hey, it takes just a few minutes), and pushed it out, and there's now an archive on kernel.org in my public personal directory called linux-2.6.git

Re: Re-done kernel archive - real one?

2005-04-17 Thread Linus Torvalds
On Sun, 17 Apr 2005, Russell King wrote: BTW, there appears to be errors in the history committed thus far. I'm not sure where this came from though. Some of them could be UTF8 vs ASCII issues, but there's a number which seem to have extra random crap in them (^M) and lots of blank

Re: [patch] fork optional branch point normazilation

2005-04-17 Thread Linus Torvalds
really is special: some people have Torvalds, Linus and maybe I should not just remove the commas, I should convert it to always be Linus Torvalds. But your gecos entry is just _strange_. Why the extra commas, I wonder?) Linus - To unsubscribe from this list: send the line

Re: [1/5] Parsing code in revision.h

2005-04-17 Thread Linus Torvalds
On Sun, 17 Apr 2005, Daniel Barkalow wrote: --- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/revision.h (mode:100644 sha1:28d0de3261a61f68e4e0948a25a416a515cd2e83) +++ 37a0b01b85c2999243674d48bfc71cdba0e5518e/revision.h (mode:100644 sha1:523bde6e14e18bb0ecbded8f83ad4df93fc467ab) @@ -24,6

Re: Re-done kernel archive - real one?

2005-04-17 Thread Linus Torvalds
On Sun, 17 Apr 2005, Russell King wrote: This will (and does) do exactly what I want. I'll also read into the above a request that you want it in forward date order. 8) No, I actually don't _think_ I care. In many ways I'm more used to reverse date order, because that's usually how you

First ever real kernel git merge!

2005-04-17 Thread Linus Torvalds
$(cat .git/HEAD) tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6 parent 8173055926cdb8534fbaed517a792bd45aed8377 parent df4449813c900973841d0fa5a9e9bc7186956e1e author Linus Torvalds [EMAIL PROTECTED] 111377 -0700 committer Linus Torvalds [EMAIL PROTECTED

Re: Re-done kernel archive - real one?

2005-04-17 Thread Linus Torvalds
On Sun, 17 Apr 2005, Russell King wrote: I pulled it tonight into a pristine tree (which of course worked.) Goodie. In doing so, I noticed that I'd messed up one of the commits - there's a missing new file. Grr. I'll put that down to being a newbie git. Actually, you should put that

Re: [patch] fork optional branch point normazilation

2005-04-17 Thread Linus Torvalds
On Sun, 17 Apr 2005, Brad Roberts wrote: braddr:x:1000:1000:Brad Roberts,,,:/home/braddr:/bin/bash All gecos entries on all my debian boxes are of the form: fullname, office number, office extension, and home number Ahh, ok. I'll make the cleanup thing just remove strange characters

Re: Merge with git-pasky II.

2005-04-17 Thread Linus Torvalds
On Mon, 18 Apr 2005, Herbert Xu wrote: I wasn't disputing that of course. However, the same effect can be achieved in using a single hash with a bigger length, e.g., sha256 or sha512. No it cannot. If somebody actually literally totally breaks that hash, length won't matter. There are

Re: Re-done kernel archive - real one?

2005-04-18 Thread Linus Torvalds
On Mon, 18 Apr 2005, Russell King wrote: Ok, I just tried pulling your tree into the tree you pulled from, and got this: No, that can't work. The pesky tools are helpful, but they really don't do merges worth cr*p right now, excuse my french. The _real_ way to pull is to do the (horribly

Re: A couple of questions

2005-04-18 Thread Linus Torvalds
On Mon, 18 Apr 2005, Imre Simon wrote: How will git handle a corrupted (git) file system? For instance, what can be done if objects/xy/z{38} does not pass the simple consistency test, i.e. if the file's sha1 hash is not xyz{38}? This might be a serious problem because, in general, one

Re: Re-done kernel archive - real one?

2005-04-18 Thread Linus Torvalds
On Mon, 18 Apr 2005, Greg KH wrote: On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote: Tools absolutely matter. And it will take time for us to build up that kind of helper infrastructure. So being newbie might be part of it, but it's the smaller part, I say. Rough

Re: Re-done kernel archive - real one?

2005-04-18 Thread Linus Torvalds
On Mon, 18 Apr 2005, Linus Torvalds wrote: No, that can't work. The pesky tools are helpful [...] I'm afraid that until Pasky's tools script this properly, [... ] If Pesky wants to take the above script, test it, [...] Ok, one out of three isn't too bad, is it? Pesky/Pasky, so close yet so

Re: [0/5] Parsers for git objects, porting some programs

2005-04-18 Thread Linus Torvalds
On Sun, 17 Apr 2005, Daniel Barkalow wrote: This series introduces common parsers for objects, and ports the programs that currently use revision.h to them. 1: the header files 2: the implementations 3: port rev-tree 4: port fsck-cache 5: port merge-base Ok, having now looked at

Re: [PATCH] fix bug in read-cache.c which loses files when merging a tree

2005-04-18 Thread Linus Torvalds
On Mon, 18 Apr 2005, James Bottomley wrote: I had a problem with the SCSI tree in that there's a file removal in one branch. Your git-merge-one-file-script wouldn't have handled this correctly: It seems to think that the file must be removed in both branches, which is wrong. Yes, I

Re: Re-done kernel archive - real one?

2005-04-18 Thread Linus Torvalds
On Mon, 18 Apr 2005, Russell King wrote: Since this happened, I've been working out what state my tree is in, and I restored it back to a state where I had one dangling commit head, which was _my_ head. For the future, if your tree gets messed up to the point where you say screw it and

Re: [PATCH] fix bug in read-cache.c which loses files when merging a tree

2005-04-18 Thread Linus Torvalds
On Mon, 18 Apr 2005, Petr Baudis wrote: So, I'm confused. Why did you introduce unpack-file instead of doing just this? It was code that I already had (ie the old code from merge-cache just moved over), and thanks to that, I don't have to worry about broken mktemp crap in user space...

Re: Re-done kernel archive - real one?

2005-04-18 Thread Linus Torvalds
On Mon, 18 Apr 2005, Greg KH wrote: Hm, have you pushed all of the recent changes public? Oops. Obviously not. Will fix. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: Re-done kernel archive - real one?

2005-04-18 Thread Linus Torvalds
On Mon, 18 Apr 2005, Greg KH wrote: Anyway, I try it this way and get: You should update to the newest version anyway.. $ dotest ~/linux/patches/usb/usb-visor-tapwave_zodiac.patch Applying USB: visor Tapwave Zodiac support patch fatal: preparing to update file

Re: Re-done kernel archive - real one?

2005-04-18 Thread Linus Torvalds
On Tue, 19 Apr 2005, Petr Baudis wrote: What is actually a little annoying is having to cd ,,merge and then back, though. I don't know, but the current pull-merge script does not bother with the temporary merge directory neither, even though Linus wanted it. Linus, do you still do? ;-)

Re: SCSI trees, merges and git status

2005-04-18 Thread Linus Torvalds
On Mon, 18 Apr 2005, James Bottomley wrote: It looks like the merge tree has contamination from the scsi-misc-2.6 tree ... possibly because the hosting system got the merged objects when I pushed. Nope, the way I merge, if I get a few objects it shouldn't matter at all. I'll just look at

Re: SCSI trees, merges and git status

2005-04-18 Thread Linus Torvalds
On Mon, 18 Apr 2005, James Bottomley wrote: Then the git-pull... script actually does the merge and the resulting tree checks out against BK So? What do you intend to do with all the other stuff I've already put on top? Yes, I can undo my tree, but my tree has had more stuff in it since I

Re: SCSI trees, merges and git status

2005-04-18 Thread Linus Torvalds
On Mon, 18 Apr 2005, James Bottomley wrote: Fair enough. If you pull from rsync://www.parisc-linux.org/~jejb/scsi-misc-2.6.git Thanks. Pulled and pushed out. Doing this exposed two bugs in your merge script: 1) It doesn't like a completely new directory (the misc tree contains a

Re: [darcs-devel] Darcs and git: plan of action

2005-04-19 Thread Linus Torvalds
On Tue, 19 Apr 2005, Tupshin Harper wrote: I suspect that any use of wildcards in a new format would be impossible for darcs since it wouldn't allow darcs to construct dependencies, though I'll leave it to david to respond to that. Note that git _does_ very efficiently (and I mean

Re: naive question

2005-04-19 Thread Linus Torvalds
On Tue, 19 Apr 2005, Petr Baudis wrote: I'd actually prefer, if: (i) checkout-cache simply wouldn't touch files whose stat matches with what is in the cache; it updates the cache with the stat informations of touched files Run update-cache --refresh _before_ doing the checkout-cache,

Re: naive question

2005-04-19 Thread Linus Torvalds
On Tue, 19 Apr 2005, Linus Torvalds wrote: The real expense right now of a merge is that we always forget all the stat information when we do a merge (since it does a read-tree). I have a cunning way to fix that, though, which is to make read-tree -m read in the old index state like

Re: [PATCH] write-tree performance problems

2005-04-19 Thread Linus Torvalds
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

Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2

2005-04-19 Thread Linus Torvalds
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

Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2

2005-04-19 Thread Linus Torvalds
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. real3m54.909s user0m14.835s sys 0m10.587s 4 minutes might be long enough to cause some folks to lose hope. Well, the real operations

Re: [PATCH] write-tree performance problems

2005-04-19 Thread Linus Torvalds
On Tue, 19 Apr 2005, Chris Mason wrote: 5) right before exiting, write-tree updates the index if it made any changes. This part won't work. It needs to do the proper locking, which means that it needs to create index.lock _before_ it reads the index file, and write everything to that one

Re: [RFC] Possible strategy cleanup for git add/remove/diff etc.

2005-04-19 Thread Linus Torvalds
On Tue, 19 Apr 2005, Junio C Hamano wrote: Let's for a moment forget what git-pasky currently does, which is not to touch .git/index until the user says Ok, let's commit. I think git-pasky is wrong. It's true that we want to often (almost always) diff against the last released thing,

Re: [RFC] Possible strategy cleanup for git add/remove/diff etc.

2005-04-19 Thread Linus Torvalds
On Tue, 19 Apr 2005, Linus Torvalds wrote: That is indeed the whole point of the index file. In my world-view, the index file does _everything_. It's the staging area (work file), it's the merging area (merge directory) and it's the cache file (stat cache). I'll immediately write a tool

Re: [PATCH 2/3] init-db.c: normalize env var handling.

2005-04-19 Thread Linus Torvalds
On Tue, 19 Apr 2005, Zach Welch wrote: This patch applies on top of: [PATCH 1/3] init-db.c: cleanup comments init-db.c | 11 +++ 1 files changed, 3 insertions(+), 8 deletions(-) Signed-Off-By: Zach Welch [EMAIL PROTECTED] Normalize init-db environment variable

Re: [PATCH 2/3] init-db.c: normalize env var handling.

2005-04-19 Thread Linus Torvalds
On Tue, 19 Apr 2005, Zach Welch wrote: I feel even more abashed for my earlier scripting faux pas. Would you like me to resend them to you off-list? No, I edited them and applied them (the first series, I'll have to think about the second one). It's only when there are tens of patches

Re: [PATCH] write-tree performance problems

2005-04-20 Thread Linus Torvalds
On Tue, 19 Apr 2005, Chris Mason wrote: I'll finish off the patch once you ok the basics below. My current code works like this: Chris, before you do anything further, let me re-consider. Assuming that the real cost of write-tree is the compression (and I think it is), I really suspect

Re: WARNING! Object DB conversion (was Re: [PATCH] write-tree performance problems)

2005-04-20 Thread Linus Torvalds
On Wed, 20 Apr 2005, Jon Seymour wrote: Am I correct to understand that with this change, all the objects in the database are still being compressed (so no net performance benefit), but by doing the SHA1 calculations before compression you are keeping open the possibility that at some

Re: [PATCH 1/4] Accept commit in some places when tree is needed.

2005-04-20 Thread Linus Torvalds
On Tue, 19 Apr 2005, Junio C Hamano wrote: This patch lifts the tree-from-tree-or-commit logic from diff-cache.c and moves it to sha1_file.c, which is a common library source for the SHA1 storage part. I don't think that's a good interface. It changes the sha1 passed into it: that may

Re: [PATCH] write-tree performance problems

2005-04-20 Thread Linus Torvalds
On Wed, 20 Apr 2005, C. Scott Ananian wrote: Hmm. Are our index files too large, or is there some other factor? They _are_ pretty large, but they have to be, For the kernel, the index file is about 1.6MB. That's - 17,000+ files and filenames - stat information for all of them - the

Re: [PATCH] write-tree performance problems

2005-04-20 Thread Linus Torvalds
On Wed, 20 Apr 2005, C. Scott Ananian wrote: OK, sure. But how 'bout chunking trees? Are you grown happy with the new trees-reference-other-trees paradigm, or is there a deep longing in your heart for the simplicity of 'trees-reference-blobs-period'? I'm pretty sure we do better

Re: [PATCH] write-tree performance problems

2005-04-20 Thread Linus Torvalds
On Wed, 20 Apr 2005, Linus Torvalds wrote: To actually go faster, it _should_ need this patch. Untested. See if it works.. NO! Don't see if this works. For the sha1 file already exists file, it forgot to return the SHA1 value in returnsha1, and would thus corrupt the trees it wrote. So

Re: [PATCH] write-tree performance problems

2005-04-20 Thread Linus Torvalds
On Wed, 20 Apr 2005, Linus Torvalds wrote: NO! Don't see if this works. For the sha1 file already exists file, it forgot to return the SHA1 value in returnsha1, and would thus corrupt the trees it wrote. Proper version with fixes checked in. For me, it brings down the time to write

  1   2   3   4   5   6   >