On Wed, 3 Aug 2005, Junio C Hamano wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
Are you sure you have a good git version on master? I've never seen
anything like that, and I push all the time..
I have been esuspecting that it happens only because I rewind
and rebase pu, which you
On Wed, 3 Aug 2005, Johannes Schindelin wrote:
On Wed, 3 Aug 2005, Linus Torvalds wrote:
Are you sure you have a good git version on master? I've never seen
anything like that, and I push all the time..
Call him Zaphod: he has two heads (master and pu). You don't.
Oh, but I most
On Wed, 3 Aug 2005, Josef Weidendorfer wrote:
Yes it is. To reproduce:
Create a repository with 2 branches.
Make 2 clones of the 2 branches via SSH.
Make a commit on one clone and push.
Make another commit on the other clone and push = ERROR
This works perfectly fine, you just have to
On Wed, 3 Aug 2005, Josef Weidendorfer wrote:
But my example shows that the error happens even with 2 branches totally
unrelated to each other: if branch1 got a new commit, you can not push to
branch2 from another clone.
Sure you can.
git-send-pack remote branch2
and you've just
On Wed, 3 Aug 2005, Junio C Hamano wrote:
Wouldn't something like this work equally well?
Nope, for several reasons:
- it's _horribly_ inefficient (ie it traverses directories that it
doesn't need to)
- it shows all the changeset comments, regardless of whether they are
releant or
On Wed, 3 Aug 2005, Junio C Hamano wrote:
While I have not updated the send-pack src:dst syntax, I
added a horrible hack that some people may love to see. This
removes the need to use git-rev-parse from many commands.
Yes, I think this makes sense. We had three different sha1 parsers:
On Tue, 2 Aug 2005, Jeff Garzik wrote:
shrug I don't really care either way.
I suspect it's mostly the users, not the developers, who care. The core
developers already know what went in, and have git to see it, they don't
look at the shortlog output. So I suspect it's more important to see
On Mon, 1 Aug 2005, Matthias Urlichs wrote:
Hi, Linus Torvalds wrote:
git checkout -f master
git-rev-parse master .git/refs/heads/merge-branch
#
# Switch to it, always leaving master untouched
#
git checkout -f merge-branch
Isn't that equivalent
A few sparse warnings have crept in again since I checked last time:
undeclared variables with global scope.
Fix them by marking the private variables properly static.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
Btw, sparse also warns about the return 0 in receive-pack.c: unpack
On Sat, 30 Jul 2005, Junio C Hamano wrote:
* Right now, send-pack --all into an empty repository does
not do anything, but send-pack --all master into an empty
repository pushes all local heads. This is because we do not
check send_all when deciding if we want to call try_match
On Sun, 31 Jul 2005, Josef Weidendorfer wrote:
Added hook in git-receive-pack
After successful update of a ref,
$GIT_DIR/hooks/update refname old-sha1 new-sha2
is called if present. This allows e.g sending of a mail
with pushed commits on the remote repository.
Documentation update
On Sun, 31 Jul 2005, Junio C Hamano wrote:
But you are. I can run this just fine:
No I'm not. Try all the machines behind my firewall.
kernel.org is just the place I put things to when I publish them. It
doesn't have any of my working directories on it.
Linus
-
To
On Sun, 31 Jul 2005, Junio C Hamano wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
No I'm not. Try all the machines behind my firewall.
Ah, that's true. Do you push into them?
Yup, I do. I have this thing that I don't do backups, but I end up having
redundancy instead, so I keep
On Fri, 29 Jul 2005, Junio C Hamano wrote:
Would this be OK? I think it is ugly but it gets the job done.
Looks ok. I'd suggest having some option to turn of curl too - I have
one machine that doesn't have curl installed, and I just turn the things
that depend on it off by hand by editing
On Sat, 30 Jul 2005, Peter Osterlund wrote:
I have problems pulling linux kernel changes from
33ac02aa4cef417871e128ab4a6565e751e5f3b2 to
b0825488a642cadcf39709961dde61440cb0731c into my local tree. At first
I thought your patch would fix it, but it doesn't:
No, this is a merge conflict
On Sat, 30 Jul 2005, Alexander Nyberg wrote:
Linus, do you think we could have something like
patch-2.6.13-rc4-incremental-broken-out.tar.bz2 that could like Andrew's
be placed into patches/ in a tree?
Not really. The thing is, since the git patches really _aren't_ serial,
and merging
On Sat, 30 Jul 2005, Peter Osterlund wrote:
Can you send me your HEAD and MERGE_HEAD (don't do the merge).
HEAD : 33ac02aa4cef417871e128ab4a6565e751e5f3b2
MERGE_HEAD: b0825488a642cadcf39709961dde61440cb0731c
Bingo.
Yup, it's git-merge-base, and it is confused by the same thing
On Sat, 30 Jul 2005, Junio C Hamano wrote:
I love it I can just slow down and let others submit obviously
correct patches, which I can just slurp in.
You're obviously doing well as a maintainer. Only stupid people try to do
everything themselves.
Personally, I spend a _lot_ of time
-off-by: Linus Torvalds [EMAIL PROTECTED]
---
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -228,6 +228,17 @@ static void mark_parents_uninteresting(s
commit-object.flags |= UNINTERESTING;
/*
+* Normally we haven't parsed
On Fri, 29 Jul 2005, Linus Torvalds wrote:
, but any time we _depend_ on dates
one way or the other that would be a good.
_not_ be a good _thing_. I don't know what strange brain-glitch I had
there.
I had kind of hoped my kids would be all grown up before their dad started
This doesn't work at least in the form that Junio merged it (and from
what I can tell, he merged your patch as-is):
[EMAIL PROTECTED]:~/src/git make NO_OPENSSL=1
cc -g -O2 -Wall '-DNO_OPENSSL' '-DSHA1_HEADER=mozilla-sha1/sha1.h' -o
git-rev-list rev-list.o libgit.a -lz -lssl
On Thu, 28 Jul 2005, Morten Welinder wrote:
I have verified that successful close() after failed mmap() won't reset
the output of perror() to Success.
Does $standard guarantee that?
In general, successful libc calls can set errno to whatever they
please, except zero. And they
On Thu, 28 Jul 2005, Junio C Hamano wrote:
I do not want to get involved in policy decisions, but for the
record I always hated your commit log for that identifies the
committer physically approach.
Well, I have to say that I find it quite useful myself. I try to commit
x86 patches to the
On Mon, 25 Jul 2005, Linus Torvalds wrote:
David, how about a patch like this to cvsps? My very very limited testing
seems to say that it does the right thing..
Hmm.. David Mansfields address is bouncing, and it's apparently not just
that cvsps thing, since it says that the MX machine
Ok, I'm uploading my current git CVS import results to kernel.org right
now, which is my current best effort (meaning: I may try to improve on it
even if there aren't any more cvsps bugs/features I have to fix, and
obviously I'll re-create it if there _are_ cvsps or cvsimport bugs that
cause the
On Mon, 25 Jul 2005, Junio C Hamano wrote:
I personally do not have preference either way, but am slightly
biased towards the cumulative behaviour the patch attempts to
implement, which was what Pasky said he wanted to have.
I think that makes sense.
Imagine, for example, that you have
On Tue, 26 Jul 2005, Matthias Urlichs wrote:
That's a problem with the bkcvs tree. Remember tht Bitkeeper does
exactly the same thing -- the 1.0 version of *any* file is empty, and
content appears only in version 1.1.
Not really. That may be how the SCCS _deltas_ end up being done
On Tue, 26 Jul, Jeff Garzik wrote:
AFAICT this is
just a complete waste of time. Why does this occur?
Packing 1394 objects
Unpacking 1394 objects
100% (1394/1394) done
It doesn't seem to make any sense to perform work, then immediately undo
that work,
On Sat, 23 Jul 2005, Ryan Anderson wrote:
* Compile against the unencumbered Mozilla SHA1 code, instead of
the iffy OpenSSL code. This makes it easier to get the package
included for distribution with Debian.
Note that this is just not true.
We still use openssl for the
On Sat, 23 Jul 2005, Ryan Anderson wrote:
Add git-find-new-files to find files that are in the tree, but not checked
into the repository.
Most users will probably want to make clean before using this for real
significant changes, as it does such a good job that it finds binaries that
On Sat, 23 Jul 2005, Linus Torvalds wrote:
On Sat, 23 Jul 2005, Ryan Anderson wrote:
Add git-find-new-files to find files that are in the tree, but not checked
into the repository.
Most users will probably want to make clean before using this for real
significant changes
On Fri, 22 Jul 2005, A Large Angry SCM wrote:
To do it without the history rewrite, create an alternate_history
directory under .git with it's own objects tree. And populate that
object tree with alternative content for the objects in the normal
trees. Then teach the things the
On Sat, 23 Jul 2005, Petr Baudis wrote:
Dear diary, on Wed, Jul 20, 2005 at 03:17:47AM CEST, I got a letter
where Ryan Anderson [EMAIL PROTECTED] told me that...
Make debian/rules executable, and correct the spelling of rsync in
debian/control
Any progress with applying of this one?
On Fri, 22 Jul 2005, Junio C Hamano wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
I'd _really_ prefer to not have any preferences or other metadata files
under version control within that same project.
Don't you think that would be a per-project decision? Is it
acceptable if I make
On Thu, 21 Jul 2005, Ryan Anderson wrote:
Nevermind, I apparently wanted:
git-whatchanged HEAD ^$LAST_RELEASED_COMMIT
Yes. And since git-whatchanged uses git-rev-parse, and can thus use the
extended git commit format, including ranges, you can literally write the
above as
On Sat, 16 Jul 2005, Junio C Hamano wrote:
*** I see you have already merged my broken one; sorry.
I already noticed the breakage, and fixed that a bit differently.
Feel free to send an updated patch if you prefer your version after my
commits have percolated out..
Linus
-
Hmm..
This patch actually brings up two different issues
- I actually prefer code and documentation to be separated. Finding the
actual changes to code in this patch is made much harder by the fact
that most of the changes are documentation updates. In many ways it
would have been
On Fri, 15 Jul 2005, H. Peter Anvin wrote:
Since it can be run as a sequestered user, and we now have plenty of CPU
horsepower on the download servers, it seems like it should be an
entirely sane thing to do.
Goodie.
Is this thing meant to be run from inetd, or is it a listen and fork
On Thu, 14 Jul 2005, Russell King wrote:
Actually, I should've left the sh -x /usr/bin/cg-diff drivers/serial/8250.c
running a little longer. It's not the git-update-cache command which
is taking the time, it's git-diff-cache.
Ok. git-diff-cache actually ends up reading your HEAD tree,
On Thu, 14 Jul 2005, Junio C Hamano wrote:
The bisect search found that the commit
Make git-checkout create files with O_EXCL
makes the test t1005 fail. But it is getting late so I give up
to figuire this out tonight.
Ahh, thanks for noticing.
It says
* expecting
On Thu, 14 Jul 2005, Linus Torvalds wrote:
I'll strace the dang thing.
It's the Adding case in git-merge-one-file-script, which does
git-checkout-cache -u -f -- $4
and it's because of this:
lstat64(DF, {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
unlink(DF
On Thu, 14 Jul 2005, Linus Torvalds wrote:
I'll look into making diff-cache be more efficient. I normally don't use
it myself, so I didn't bother (I use git-diff-files, which is way more
efficient, but doesn't show the difference against the _tree_, it shows
the difference against the index
On Thu, 14 Jul 2005, Junio C Hamano wrote:
That said, I have been hating that diff options parsing for
quite a while, and I've been thinking about cleaning it up along
the lines I'll outline here, but have not done anything about
it. Care to help me out?
I didn't do what you suggested,
On Wed, 13 Jul 2005, Matthias Urlichs wrote:
Hi, Bryan Larsen wrote:
+ r=os.spawnvp(os.P_WAIT, args_l[0], args_l + args[i:min(i+1000,
len(args))])
The max length for argv is 32k IIRC, so 1000 is 28-byte file names.
I think 32k may be the posix-mandated minimum. Linux does 128kB,
On Wed, 13 Jul 2005, Chris Wedgwood wrote:
On Wed, Jul 13, 2005 at 09:03:26AM +0200, Matthias Urlichs wrote:
You are ;-) the tree itsels is no symlinked, but HEAD points to
refs/heads/branch by default.
Thanks for pointing that out. I honestly never noticed that.
How about the
On Wed, 13 Jul 2005, Russell King wrote:
This says it all. 1min 22secs to generate a patch from a locally
modified but uncommitted file.
No, there's something else going on.
Most likely that something forced a total index file re-validation, and
the time you see is every single checked out
On Wed, 13 Jul 2005, Junio C Hamano wrote:
I do not think git-cherry would be that useful in this context.
Nobody upstream is merging things into your development trail,
started at the private commit you made based on the 2.6.11 tree.
No, the point being that he (or anybody else) could
On Wed, 13 Jul 2005, Chris Wedgwood wrote:
I would however like to be able to hardlink more than just the
_object_ directory --- hardlinking the source is quite nice too.
Might that be considered safe? (I'm of course assuming that editors
do write + rename when saving their buffers).
On Wed, 13 Jul 2005, Linus Torvalds wrote:
Anyway, this would be a _wonderful_ interface for read-only updates, ie
people pulling from my (and other peoples) git repositories.
I guess I should say what the interface is, so that people don't have to
read the sources to find out
On Wed, 13 Jul 2005, Junio C Hamano wrote:
There currently are these two pack push-pull protocols used for
different purposes. Maybe you invented another today? I have
not looked beyond your log message.
No, it's the upload-pack one.
The send-pack protocol is just for writing new stuff,
On Tue, 12 Jul 2005, Petr Baudis wrote:
Could we please have the branch name written to .git/head-name in case
we switch the branch?
I wouldn't mind per se, but on the other hand I really _hate_ having
parallel information that can get out of sync. If you have two places
holding the same
On Tue, 12 Jul 2005, Eric W. Biederman wrote:
One last issue with building packages. Some distros are still shipping
GNU interactive tools so git as a package name for the rpm is problematic.
At the very least it is extremely confusing that git-0.99 is a more
recent package that
On Tue, 12 Jul 2005, Eric W. Biederman wrote:
The name of the tarball needs to be updated as well.
Yes, I noticed.
I ended up renaming the spec-file too.
Pushed out,
Linus
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL
Eric,
I ended up coding the ident stuff a bit differently, and I didn't do done
the tag/git-id part yet. Can you check out my latest commit (pushed out,
but it will probably take a few minutes to mirror out), and do the final
tag stuff based on that?
Linus
-
To unsubscribe
On Tue, 12 Jul 2005, Jerry Seutter wrote:
The README file for cogito/git mentions that there is an ssl library
included in the source which you can use if you don't have openssl. It
doesn't give any directions on how to use it, however. You could try
looking into using that.
Use
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
I guess I was expecting to pull from one tree into another unrelated
tree. Getting a tree with two heads and then be able to merge them
together.
You can do it, but you have to do it by hand. It's a valid operation, but
it's not an operation
On Mon, 11 Jul 2005, Daniel Barkalow wrote:
On Sun, 10 Jul 2005, Linus Torvalds wrote:
You really _mustn't_ try to create the pack directly to the
$GIT_DIR/objects/pack subdirectory - that would make git itself start
possibly using that pack before the index is all done
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
I'm having the worst time putting together a mental model of how git
works, and the documentation is spotty enough that it hasn't been
helpful. So I am wading through the code. It seems every time I turn
a corner there is another rough spot.
On Mon, 11 Jul 2005, Marc Singer wrote:
I picked 2.6.12
# git checkout -f v2.6.12
applied the patch and was greeted with an error about being unable to
commit telling me that I LONG_HEX_NUMBER is not a valid commit object.
Isn't 2.6.12 later than 2.6.12-rcX?
Yes.
However, that's
On Mon, 11 Jul 2005, Junio C Hamano wrote:
- we allow git-checkout-script with a tag; I think we store the tag
object without dereferencing in .git/HEAD;
No, git-checkout-script _shouldn't_ have done that. It will do the
read-tree on the tag (which will do the right thing), but it
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
Ok. Only the dumb methods are allowed.
Well, no, you can actually do git-clone-pack by hand in that git archive,
and it will use the smart packing to get the other end, even if it is
totally unrelated to the current project.
But you have to do
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
Actually I was looking at doing a git-ident thing that will
just compute who git thinks you are. And then git-commit-tree can
just popen it to share code. That looks like how the logic has
been accomplished in other places.
I hate popen() if
On Mon, 11 Jul 2005, Linus Torvalds wrote:
No, git-checkout-script _shouldn't_ have done that. It will do the
read-tree on the tag (which will do the right thing), but it won't change
the HEAD itself.
In preparation of actually updating the HEAD, I just made git checkout
verify
On Mon, 11 Jul 2005, Marc Singer wrote:
From my POV, what I want is a branch with the tag v2.6.12 as the basis
of the branch. I'm guessing that -b means make me a branch and call
it this.
Yup. That would be the interface.
# git checkout -b BRANCH_NAME [TAG]
If the TAG is omitted,
On Mon, 11 Jul 2005, Junio C Hamano wrote:
Opinions?
How about treating master a temporary thing --- whatever I
happen to be working on right now?
I'd not mind with this in theory, but it has the fundamental problem that
we can end up losing sight of commits we have, and then have no
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
The question:
Does git-upload-pack which gets it's list of objects
with git-rev-list --objects needed1 needed2 needed3 ^has1 ^has2 ^has3
get any history beyond the top of tree of each branch.
As I read the code it does not.
It does. It
On Mon, 11 Jul 2005, Junio C Hamano wrote:
I do not quite follow your objections. I do not think I am
forcing anybody to name an old thing.
Sure you are. You're forcing them to make a choice, where both choices
are bad. Either:
- name an old thing (that you may not even have worked on -
On Mon, 11 Jul 2005, Linus Torvalds wrote:
Of course, if you want to create a new branch my-branch and _not_
check it out, you could have done so with just
git-rev-parse v2.6.12^0 .git/refs/heads/my-branch
which I think I will codify as git branch.
And now we have
On Mon, 11 Jul 2005, Marc Singer wrote:
Does it make sense to think about this branch as an flow of commits?
Or is it just a starting point for a line of development?
It's really a flow of commits. Nothing will ever really remember what the
starting point was at some later date if you have
On Sun, 10 Jul 2005, Russell King wrote:
It means that rsync --delete-after can (in theory) be used when
making changes available to the upstream maintainer.
I'd suggest against that from a safety standpoint (no backups), but what
you _can_ do is to upload only the objects I don't have.
On Sun, 10 Jul 2005, David Woodhouse wrote:
Now the mailing list feed isn't happy though -- it stopped being able to
pull from your tree at around 0600 UTC (which I think is then the last
DRM fix was added). I got this when trying to update...
Which script is this? I'm looking at your
On Sun, 10 Jul 2005, Russell King wrote:
Ok, let's give this a go then. However, I'm not confident in this
working, especially after seeing the output of git-fsck-cache --full...
and I've no idea _why_ it's complaining.
Ok, I've downloaded your objects, and it all looks fine. Nothing is
On Sun, 10 Jul 2005, Russell King wrote:
On Sun, Jul 10, 2005 at 01:03:30PM -0700, Linus Torvalds wrote:
Anyway, I pushed out the merge, so don't worry about your tree. But let's
hold off on this partial thing for a while, ok?
Thanks, that's good news. I was fearing having
On Sat, 9 Jul 2005, Eric W. Biederman wrote:
The current intelligent fetch currently has a problem that it cannot
be used to bootstrap a repository. If you don't have an ancestor
of what you are fetching you can't fetch it.
Sure you can.
See the current git clone. It's actually quite
On Sun, 10 Jul 2005, Junio C Hamano wrote:
So I would suggest either:
- droping the packname parameter from git-pack-objects. Make
the packs always named pack-X{40}.pack (or just X{40}.pack);
Well, regardless, we want to be able to specify which directory to write
them to. We
On Sun, 10 Jul 2005, Daniel Barkalow wrote:
On Sun, 10 Jul 2005, Linus Torvalds wrote:
Well, regardless, we want to be able to specify which directory to write
them to. We don't necessarily want to write them to the current working
directory, nor do we want to write them
On Sat, 9 Jul 2005, David Woodhouse wrote:
Does git on master.kernel.org need to be updated to handle packed
objects? See attached.
Yes, looks that way. Except it's not git on master.kernel.org, it's git
in your home directory, I suspect. I expressly held off packing the
kernel repo until
On Fri, 8 Jul 2005, Bryan Larsen wrote:
Add --no-check option to git-write-tree.
I like almost all of these patches (well, the ones relevant to core git,
I'll not speak for Pasky on cogito), although I'd actually prefer your
index_fd() info-only flag to work the other way around: make it a
On Fri, 8 Jul 2005, Alexey Dobriyan wrote:
I'm confused now. This pack file is ~60M in size. Will rsync download
another 60M next time? What command should I use now to a) get latest and
greatest and b) be nice with my traffic?
Your existing command should work fine.
You may (or may not)
On Fri, 8 Jul 2005, Mateusz Berezecki wrote:
How to commit and check-in changes done to the checked-out source code?
The git commit command seems to only commit the changes locally
without pushing them via rsync.
Is there any way I can push commits via rsync? Am I missing the point
and
On Fri, 8 Jul 2005, Marc Singer wrote:
In working through a usage example on my way to producing bonafide
patches, I've found that commit is complaining. Here's what I've done.
o Fetched and built cogito-0.12
o Fetched (rsync) Linus' tree
o Created a working directory, linux-2.6
On Fri, 8 Jul 2005, Marc Singer wrote:
# git diff HEAD^ HEAD
This command will produce a diff of the changes I've made. What is
the HEAD^? Does it refer to the commit before the last one made?
Yes. The core tools don't understand this syntax, but most of the helper
scripts use
On Thu, 7 Jul 2005, Junio C Hamano wrote:
(1) Would it make sense to have an extra flag to rev-list
--objects to make it list all the objects reachable from
commits listed in its output, even when some of them are
unchanged from UNINTERESTING commits? Right now, a pack
On Thu, 7 Jul 2005, Junio C Hamano wrote:
- if (!strcmp(arg, --objects)) {
+ if (!strncmp(arg, --objects, 9)) {
+ if (!strcmp(arg+9, =self-sufficient))
+ objects_self_sufficient = 1;
This is nasty - if you mis-spell
On Thu, 7 Jul 2005, Tony Luck wrote:
So, what _is_ then the way to pull now, actually? If we use rsync, won't
we end up with having the objects we previous had twice now?
Rsync works fine. You can either unpack the pack you get, or, if you
prefer, just run
On Thu, 7 Jul 2005, Linus Torvalds wrote:
cg-update from a local repo that contains packs is broken though :-(
Is this with cg-0.12? The most recent release should be happy with packs.
Ahh, I see it. It's because it uses git-local-pull, and yes,
git-local-pull does the old filename
On Thu, 7 Jul 2005, Junio C Hamano wrote:
Again you are right. How about --full-objects instead?
I don't mind the --objects=xxx format per se, but it would need to
verify that the =xxx was either valid or wasn't there at all. So what I
objected to was not that it was easy to mis-spell,
On Thu, 7 Jul 2005, Junio C Hamano wrote:
However it does not automatically mean that the avenue I have
been pursuing would not work; the server side preparation needs
to be a bit more careful than what I sent, which unconditionally
runs prune-packed. It instead should leave the files
On Wed, 6 Jul 2005, Junio C Hamano wrote:
By invitation.
When we are cloning a repository on a local filesystem [...]
Hmm.. Did you test the ssh case?
+case $local_use,$is_local in
+default,f)
+ ;;
It would seem that you don't do anything at all for the non-local
On Wed, 6 Jul 2005, Greg KH wrote:
I just updated to the latest git tree, and now get the following when I
try to pull from a ssh repo:
$ git-pull-script [EMAIL PROTECTED]:/public_html/udev.git/
fatal: I don't like '@'. Sue me.
So I drop the @ and then get:
$ git-pull-script
On Wed, 6 Jul 2005, Greg KH wrote:
Ok, below is a patch for this. It works, but then errors out with:
bash: git-upload-pack: command not found
fatal: unexpected EOF
So I'm guessing that I have to convince the server owner to update their
version of git too?
The easiest way
On Thu, 7 Jul 2005, Jon Seymour wrote:
Linus: the last test fails with --topo-order at the moment. I haven't
seen your most recent changes, so it may still fail for trivial
reasons even then. If so, I'll post an update.
It passes for me, so I think the SEEN flag thing fixed it.
On Wed, 6 Jul 2005, Jon Seymour wrote:
Is there some reason why this didn't get applied?
I think it's horribly horribly ugly.
I really don't see the point of argument ordering mattering, and I think
the test is broken. Convince me otherwise.
Linus
-
To unsubscribe from
I just hit an interesting pack failure because of how git (mis-)uses zlib,
and I'm wondering what to do about it.
In particular, the git-unpack-objects code gets a data stream, and only
knows the _unpacked_ size of each object, because writing packed size is
extremely inconvenient in many ways
On Wed, 6 Jul 2005, Wolfgang Denk wrote:
I tested this on the U-Boot CVS repository (available at
http://cvs.sourceforge.net/cvstarballs/u-boot-cvsroot.tar.bz2).
Committing initial tree 2183da96d548c02bd4f99b05e673395f81212878
Cannot create object: Too many open files
If you make it
On Tue, 5 Jul 2005, Matthias Urlichs wrote:
I just had this ugly merge situation:
M
|\
| \
A B
|\/|
|/\|
C D
| /
|/
E
Suppose both the EC and the ED branch add files (not with conflicting
filenames!) which then get modified somewhere between C/D and M.
No matter
On Mon, 4 Jul 2005, David S. Miller wrote:
I can't be the only person in the world seeing this :-)
It usually grows to around 88MB and runs for 8 minutes before
it finishes.
I'm making something based on pack-files.
git-local-pull is indeed walking the whole tree and copying one file at a
On Fri, 22 Apr 2005, Linus Torvalds wrote:
I'm not even going to debug this bug. I'm just going to rewrite diff-cache
to do what I should have done originally, ie use the power of the
in-memory cache.
Done, and pushed out. It should hopefully work now.
Linus
On Fri, 22 Apr 2005 [EMAIL PROTECTED] wrote:
git log seems to have problems interpreting the dates ... looking at the
commit entries, the time is right ... but it appears that git log applies
the timezone correction twice, so the changes I just applied at 14:46 PDT
look like I made them at
On Thu, 21 Apr 2005, Chris Mason wrote:
We can sort by the files before reading them in, but even if we order things
perfectly, we're spreading the io out too much across the drive.
No we don't.
It's easy to just copy the repository in a way where this just isn't true:
you sort the
401 - 500 of 577 matches
Mail list logo
