When we allow a tag object in place of a commit object, we only
dereferenced the given tag once, which causes a tag that points
at a tag that points at a commit to be rejected. Instead,
dereference tag repeatedly until we get a non-tag.
This patch makes change to two functions:
- commit.c::look
On Sun, 10 Jul 2005, Linus Torvalds wrote:
> On Sun, 10 Jul 2005, Daniel Barkalow wrote:
> >
> > Perhaps git-pack-objects should have the base as a optional argument,
> > with a default of the filename in $GIT_DIR/objects/pack and an option
> > for sending just the pack file to stdout?
>
> You r
Yes, I meant to use $ARGS. I included the fix in the patchset I just sent.
Sorry,
Bryan
Joel Becker wrote:
Petr,
Commit 7c5977297f07c2a52c8c0f486309076b2a795d33 contains the
chunk:
-uri=$1
+
+infoonly=
+while optparse; do
+ if optparse -N; then
+ infoonly=-N
+
Make cg-commit aware of the rename of git-write-tree --no-check to --missing-ok.
Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]>
---
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -111,13 +111,13 @@ forceeditor=
ignorecache=
infoonly=
commitalways=
-nocheck=
+missingok=
Add --missing-ok option to git-write.tree. This option allows a write-tree
even if the referenced objects are not in the database.
Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]>
---
diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt
--- a/Documentation/git-write-t
Bugfix for cg-init -N: the -N option needs to be passed down into cg-commit as
well.
Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]>
---
diff --git a/cg-init b/cg-init
--- a/cg-init
+++ b/cg-init
@@ -56,7 +56,7 @@ if [ "$uri" ]; then
else
git-read-tree # Seed the dircache
find
Bugfix: nasty typo (ARGV instead of ARGS) in my last patch to cg-init.
Signed off by: Bryan Larsen <[EMAIL PROTECTED]>
---
diff --git a/cg-init b/cg-init
--- a/cg-init
+++ b/cg-init
@@ -33,7 +33,7 @@ while optparse; do
fi
done
-uri=$ARGV
+uri=$ARGS
[ -e $_git ] && die "$_git already
All of my patches have been applied to git and cogito except for the
first one, the patch that adds the --no-check option to
git-write-tree. This is problematic because one of the patches that
Petr applied to cogito requires git-write-tree --no-check.
As well, there are two bugs in cg-init: the
On Sun, 10 Jul 2005, Daniel Barkalow wrote:
>
> Perhaps git-pack-objects should have the base as a optional argument,
> with a default of the filename in $GIT_DIR/objects/pack and an option
> for sending just the pack file to stdout?
You really _mustn't_ try to create the pack directly to the
$
On Sun, 10 Jul 2005, Linus Torvalds wrote:
>
>
> 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 curr
One very minor problem I have with Holmsand approach [*1*] is
that the original Barkalow puller allowed a really dumb http
server by not requiring directory index at all. For somebody
like me with a cheap ISP account [*2*], it was great that I did
not have to update 256 index.html files for object
Petr,
Commit 7c5977297f07c2a52c8c0f486309076b2a795d33 contains the
chunk:
-uri=$1
+
+infoonly=
+while optparse; do
+ if optparse -N; then
+ infoonly=-N
+ else
+ optfail
+ fi
+done
+
+uri=$ARGV
However, $ARGV is not a variable I've ever
Ok, I tagged a "v0.99" thing, and pushed it out. I've also made trial
RPM's of it: src, ppc64 and x86. They're build on whatever random machines
I had, and on the ppc64 I chose to do it on my FC4 machine that has newer
libraries than my YDL one. The x86 thing is FC3, I do believe.
I haven't re
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 to
On Sun, 10 Jul 2005, Linus Torvalds wrote:
> 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
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
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> This series has one patch which is ready to go in and one that's not
> (although it's a reasonable phony for the current state of the git world).
I like the general direction in which this patch is leading us.
But before going further, I'd like to se
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 quit
Add write_sha1_to_fd(), which writes an object to a file descriptor. This
includes support for unpacking it and recompressing it.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
commit 264ff9f3dcde5553728b34fa08e04643b2b55946
tree 353fe33ae9c7265d7b685bca864d657e3efe2849
parent c3eb461762b1
Remove map_sha1_file(), now unused.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
commit c21a02262f770a25b005378e06354e582aa1bfd8
tree 7ac9fabe666f00f37572e7b349fdb859bf8a6491
parent 264ff9f3dcde5553728b34fa08e04643b2b55946
author Daniel Barkalow <[EMAIL PROTECTED]> 1121033599 -0400
commi
This series adds support for sending individual objects from packs in in
git-ssh-push and removes map_sha1_file.
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Sat, Jul 09, 2005 at 03:09:02PM -0600, 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.
>
Not sure if this is what you want, but you
Daniel Barkalow wrote:
On Sun, 10 Jul 2005, Dan Holmsand wrote:
Daniel Barkalow wrote:
If an individual file is not available, figure out what packs are
available:
Get the list of pack files the repository has
(currently, I just use "e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135")
For any p
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 to r
Make the --recover flag check the parents of commits which are already
available. This is needed currently to deal with cases where a parent is
pulled along with a commit (in a pack, e.g.) and references above that
parent aren't also pulled together.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTE
Petr Baudis wrote:
It _is_ unsafe for individual objects, and your packfile will be corrupt
if you break it in the middle and not have --whole-file turned on, I
assume. It would be ideal if we could make rsync allow resuming download
of the file if interrupted, but not under the final name but i
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 to reconstruct stuff.
Do you want me to re-populate linux-
On Sun, 10 Jul 2005, Dan Holmsand wrote:
> Daniel Barkalow wrote:
> > I have a design for using http-pull on a packed repository, and it only
> > requires one extra file in the repository: an append-only list of the pack
> > files (because getting the directory listing is very painful and
> > fail
Support for downloading the pack file
"e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135" when appropriate. (Will
support other pack files when the repository has a list of them.)
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
commit 74132562a2f6cfce9690a5091de7e85bd51d88af
tree c0ae9cb936abac4412
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 i
This series has one patch which is ready to go in and one that's not
(although it's a reasonable phony for the current state of the git world).
1: Several additional functions are needed in the library to support
progressively getting pack data from some remote location and using it
to de
Daniel Barkalow wrote:
I have a design for using http-pull on a packed repository, and it only
requires one extra file in the repository: an append-only list of the pack
files (because getting the directory listing is very painful and
failure-prone).
A few comments (as I've been tinkering with
Support for parsing index files without pack files, installing pack
files while running, and checking what pack files are available.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
commit b686d7a0377c24e05dbed0dafe909dda6c3dfb48
tree ce285b1a0adb4f8d415f72668a77bc1f1f92e1e1
parent 167a4a33
On Sun, Jul 10, 2005 at 09:51:16AM -0700, Linus Torvalds wrote:
> 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)
I have a design for using http-pull on a packed repository, and it only
requires one extra file in the repository: an append-only list of the pack
files (because getting the directory listing is very painful and
failure-prone).
The first thing to note is that fetch() is allowed to get more than ju
On Sun, 10 Jul 2005, David Woodhouse wrote:
>
> > Anyway, it's possible that this is a temporary problem: one of the issues
> > is that since you seem to be using the "rsync:" protocol for updating
> > things, what happens is that if the mirroring is off a bit, you may have
> > gotten a new h
On Sun, 2005-07-10 at 10:08 -0700, Linus Torvalds wrote:
> Which script is this? I'm looking at your scripts, but
> "cg-feedmaillist.sh" is unreadable for me, so I can't see all of it.
Hm. Dunno why that happened -- it's readable now, and also at
http://david.woodhou.se/cg-feedmaillist.sh
> Anywa
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 s
Am I doing something wrong?
% cg-version
cogito-0.12 (a2503fd85e6bb7f25d134a5634a1d8efc93fee5f)
% cg-clone -s ../linux-2.6
defaulting to local storage area
`/home/yoshfuji/GIT/linux-2.6+test/../linux-2.6/.git/refs/heads/master' ->
`.git/refs/heads/origin'
progress: 1011 objects, 2976247 bytes
d
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.
Dear diary, on Sat, Jul 09, 2005 at 12:34:44AM CEST, I got a letter
where Pavel Roskin <[EMAIL PROTECTED]> told me that...
> Hello, Petr!
Hello,
> Please consider this script for Cogito.
>
> Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
the script is definitively interesting, but I have coupl
Dear diary, on Sat, Jul 09, 2005 at 08:03:32PM CEST, I got a letter
where "H. Peter Anvin" <[EMAIL PROTECTED]> told me that...
> Petr Baudis wrote:
> >
> >Yes, please do. I deprecated rsync a day before Linus "broke" http-pull.
> >It's un-deprecated again for now in the latest Cogito.
> >
>
> Pres
Dear diary, on Sat, Jul 09, 2005 at 12:40:22PM CEST, I got a letter
where Bryan Larsen <[EMAIL PROTECTED]> told me that...
> (resending cogito patches)
>
> Add the -N option to cg-add.
>
> Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]>
Applied all three patches. Note that I'm a bit happier when
Dear diary, on Sat, Jul 09, 2005 at 11:04:37PM CEST, I got a letter
where Matthias Urlichs <[EMAIL PROTECTED]> told me that...
> > o Is there a way to force git to apply and safe the rejects?
>
> Well, you can use "patch -p1 ..." directly, and manually add the files it
> created to the object cac
Dear diary, on Sun, Jul 10, 2005 at 10:09:14AM CEST, I got a letter
where Russell King <[EMAIL PROTECTED]> told me that...
> On Sat, Jul 09, 2005 at 10:58:18PM +0100, Russell King wrote:
> > $ mv .git/objects/pack/* .git/
> > $ for i in .git/*.pack; do git-unpack-objects < $i; done
> > Unpacking 55
On Sun, 2005-07-10 at 00:38 +0100, David Woodhouse wrote:
> Doh. I thought I'd already done that, but in fact that was for the
> scripts which feed the mailing list, while the snapshot script kept
> using my copy.
Ok, the snapshot script starts working again if I change a few
environment variable
Dear diary, on Sat, Jul 09, 2005 at 01:34:55AM CEST, I got a letter
where Bryan Larsen <[EMAIL PROTECTED]> told me that...
> On Mac OS X
>
> $ cg-clone http://www.kernel.org/pub/scm/cogito/cogito.git
> defaulting to local storage area
> 19:11:10
> URL:http://www.kernel.org/pub/scm/cogito/cogito.g
* Marco Costalba <[EMAIL PROTECTED]> wrote:
> So I cannot reproduce the bug. [...]
weird - i cannot reproduce it either anymore, and annotate works now as
advertised - it's fast and accurate as far as i checked. But i synced to
the latest tree meanwhile. Perhaps i had an inconsistent tree?
(i
On Sun, Jul 10, 2005 at 12:15:48AM -0700, Junio C Hamano wrote:
> As a workaround until Cogito gets updated, would it help to have
> the environment variable GIT_ALTERNATE_OBJECT_DIRECTORIES
> pointing at the untouched copy of Linus tree's .git/objects/
> directory? All your other trees would find
Ingo Molnar wrote:
>
>the bad news: except for annotations. I started qgit in the current
>kernel GIT repository, and clicked on the following commit:
>
> 5bbcfd9000887c0da7d57cc7b3ac869fc0dd5aa9
>
>then i clicked on sched.c to see the annotated file.
Interesting enough sched.c is one of the f
* Marco Costalba <[EMAIL PROTECTED]> wrote:
> Here is qgit-0.7, a GUI git viewer.
>
> you can download from:
>
> http://prdownloads.sourceforge.net/qgit/qgit-0.7.tar.gz?download
>
>
> This time a small changelog, but a lot of work ;-)
>
> - rewrite of graph drawing
> - start-up loading: swit
On Sat, Jul 09, 2005 at 10:58:18PM +0100, Russell King wrote:
> $ mv .git/objects/pack/* .git/
> $ for i in .git/*.pack; do git-unpack-objects < $i; done
> Unpacking 55435 objects
> fatal: inflate returned -3
This morning's cg-update gave these new errors:
receiving file list ... done
wrote 86 b
> "RK" == Russell King <[EMAIL PROTECTED]> writes:
RK> I would if I could, but my workflow involves having an untouched local
RK> copy of your tree and several trees for each area.
RK> This involves updates using relative paths, and as has already been
RK> found elsewhere, this (with cogito 0
53 matches
Mail list logo
