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
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
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
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
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
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
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
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
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
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
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,
: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
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
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
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
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
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
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
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
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
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
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
. 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[ 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
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
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
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
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
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.
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,
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
On Sun, 17 Apr 2005, Daniel Barkalow wrote:
--- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/revision.h (mode:100644
sha1:28d0de3261a61f68e4e0948a25a416a515cd2e83)
+++ 37a0b01b85c2999243674d48bfc71cdba0e5518e/revision.h (mode:100644
sha1:523bde6e14e18bb0ecbded8f83ad4df93fc467ab)
@@ -24,6
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
$(cat .git/HEAD)
tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6
parent 8173055926cdb8534fbaed517a792bd45aed8377
parent df4449813c900973841d0fa5a9e9bc7186956e1e
author Linus Torvalds [EMAIL PROTECTED] 111377 -0700
committer Linus Torvalds [EMAIL PROTECTED
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
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
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
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
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
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
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
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
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
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
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...
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
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
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? ;-)
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
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
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
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
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,
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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 - 100 of 577 matches
Mail list logo