Thomas Rast tr...@student.ethz.ch writes:
I like the general idea, too, but I think there is a long way ahead, and
we shouldn't hold up v5 on this.
We shouldn't rush, only to keep some deadline, and regret it later
that we butchered the index format without thinking things through.
When this
Junio C Hamano gits...@pobox.com writes:
Then of course you need to split the second patch into several logical
patches again. We can drop _v5 suffix in read-cache-v5.c (I haven't
done that). When we add partial read/write for v5, we can add more
func pointers to index_ops and implement them
I'm confused.
What is the intended work flow here? Ie, aside from trashing my
repository and starting over, what does one do to recover?
rich@cobra git clone /home/rich/repos/webos webos
Cloning into 'webos'...
done.
rich@cobra cd webos
rich@cobra git remote add central
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
add_to_index and remove_index_entry_at seem good places for the cut.
But do we need to redefine the location?
That is one of the things we need to think about carefully. Of
course, if add_to_index() just takes a pathname out of the ce the
caller
Rich Pixley rich.pix...@palm.com writes:
I'm confused.
What is the intended work flow here? Ie, aside from trashing my
repository and starting over, what does one do to recover?
rich@cobra git clone /home/rich/repos/webos webos
Cloning into 'webos'...
done.
rich@cobra cd webos
[..]
- By design, the borrowed object store MUST not ever lose any
object from it, as such an object loss can corrupt the borrowing
repositories. In theory, it is OK for the object store whose
objects are borrowed by repositories to acquire new objects, but
losing existing
Eric Wong wrote:
Hi,
A few minor comments inline...
Please ensure all error messages and code are readable in
80-column terminals.
Also, keep opening { on the same line as the if/unless.
Backticks don't nest properly, nowadays, we prefer:
N=$(expr $N + 1)
+cp
dcommit didn't handle errors returned by SVN and coped very
poorly with concurrent commits that appear in SVN repository
while dcommit was running. In both cases it left git repository
in inconsistent state: index (which was reset with `git reset
--mixed' after a successful commit to SVN) no
On Tue, Aug 07, 2012 at 08:45:10PM +, Eric Wong wrote:
Peter Baumann waste.mana...@gmx.de wrote:
Therefore the easiest solution to clear the cache is to delete the files
on disk in 'git svn reset'. Normally, deleting the files behind the back
of the memoization module would be
On Sun, Aug 05, 2012 at 11:38:12AM +0200, Michael Haggerty wrote:
I have some other crazy ideas for making the concept even more powerful:
* Support remote alternate repositories. Local repository obtains
missing objects from the remote as needed. This would probably be
insanely
On Mon, Aug 6, 2012 at 11:03 PM, Jeff King p...@peff.net wrote:
On Mon, Aug 06, 2012 at 10:44:07PM -0700, Brandon Casey wrote:
Anyone else? :)
Sorry to gang up on you. :)
Heh. :b
I still think your 2/2 is worth doing independently, though. It is silly
that git-prune will not mention pruned
Jeff King p...@peff.net writes:
On Mon, Aug 06, 2012 at 11:08:39AM +0800, mofaph wrote:
I am using Git 1.7.11.4 now. I compile and then install it from the repo.
$ git checkout v1.7.11.4
$ make prefix=$HOME/opt/git/1.7.11.4 all doc info
$ make prefix=$HOME/opt/git/1.7.11.4
On Tue, Aug 7, 2012 at 12:46 AM, Junio C Hamano gits...@pobox.com wrote:
The index_ops abstraction is a right way to go, and I like it, but I
think the split illustrated in this patch might turn out to be at
wrong levels (and it is OK, as I understand this is a illustration
of concept patch).
On 08/05, Junio C Hamano wrote:
Thomas Gummerer t.gumme...@gmail.com writes:
diff --git a/read-cache.c b/read-cache.c
index 2f8159f..5d61d92 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1433,7 +1446,7 @@ int read_index_from(struct index_state *istate, const
char *path)
On 08/05, Junio C Hamano wrote:
Thomas Gummerer t.gumme...@gmail.com writes:
-static int ce_write(git_SHA_CTX *context, int fd, void *data, unsigned int
len)
+static int ce_write_v2(git_SHA_CTX *context, int fd, void *data, unsigned
int len)
{
Mild NAK to name this function
Excerpts from Jeff King's message of Tue Aug 07 00:10:26 -0400 2012:
Signed-off-by: Jeff King p...@peff.net
Acked-by: Ben Walton bwal...@artsci.utoronto.ca
I agree with your assesment that this is the right way to go (vs
migrating out of stdio) for now. If the changes Tay needs to make
Brandon Casey draf...@gmail.com writes:
On Mon, Aug 6, 2012 at 11:03 PM, Jeff King p...@peff.net wrote:
On Mon, Aug 06, 2012 at 10:44:07PM -0700, Brandon Casey wrote:
Anyone else? :)
Sorry to gang up on you. :)
Heh. :b
I still think your 2/2 is worth doing independently, though. It is
Thomas Gummerer t.gumme...@gmail.com writes:
This part is called even before we know what version of the index
we will read, and before the file is mmaped. The best solution
i think is to drop the check and just call verify_hdr, ...
Exactly. And do the length checking inside verify_hdr() or
On 08/05, Junio C Hamano wrote:
Thomas Gummerer t.gumme...@gmail.com writes:
The new git racy code uses the mtime of cache-entries to smudge
a racy clean entry, and loads the work, of checking the file-system
-ECANTPARSE.
The git racy code for index-v5 uses the mtime of the
hello,
I read this:
http://metalinguist.wordpress.com/2007/12/06/the-woes-of-git-gc-aggressive-and-how-git-deltas-work/
where
git repack -a -d --depth=250 --window=250
is mentioned as a (recommended) alternative to git gc --aggressive.
I am a bit confused, because the page also mentions
A release candidate Git v1.7.12-rc2 is now available for testing
at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
f05297c883b958d04c00a7aba8f234261efd8844 git-1.7.12.rc2.tar.gz
On 08/05, Junio C Hamano wrote:
Thomas Gummerer t.gumme...@gmail.com writes:
Make git read the resolve-undo data from the index.
Since the resolve-undo data is joined with the conflicts in
the ondisk format of the index file version 5, conflicts and
resolved data is read at the same
I am not 100% sure of the root cause of this, but I have gotten the
following error message back from vger via GMail at least twice now:
Delivery to the following recipient failed permanently:
git@vger.kernel.org
Technical details of permanent failure:
Google tried to deliver your
When asciidoc converts a listing block like:
--
$ git log --merge
--
it marks it to be displayed in a monospace font. This works
fine when generating HTML output. However, when generating
docbook output, we override the expansion of a listingblock
to work
Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
git-svn has maintained some private per-repository caches in
.git/svn/.caches to avoid refetching and recalculating some
mergeinfo-related information with every 'git svn fetch'.
This memoization can cause problems, e.g consider
Peter Baumann waste.mana...@gmx.de wrote:
Therefore the easiest solution to clear the cache is to delete the files
on disk in 'git svn reset'. Normally, deleting the files behind the back
of the memoization module would be problematic, because the in-memory
representation would still exist and
On Tue, Aug 07, 2012 at 01:33:23PM -0600, John 'Warthog9' Hawley wrote:
It's pretty simple: you sent HTML mail to vger.kernel.org, and it
explicitly rejects all HTML e-mail. GMail, particularly from Android,
apparently doesn't have a way to bypass sending HTML mail (it's been a
much maligned
On Tue, Aug 7, 2012 at 4:55 PM, Theodore Ts'o ty...@mit.edu wrote:
On Tue, Aug 07, 2012 at 01:33:23PM -0600, John 'Warthog9' Hawley wrote:
It's pretty simple: you sent HTML mail to vger.kernel.org, and it
explicitly rejects all HTML e-mail. GMail, particularly from Android,
apparently doesn't
On Saturday 04 August 2012 23:53:58 Ramkumar Ramachandra wrote:
Hi,
Florian Achleitner wrote:
1. Import linearly and split later:
I think this approach will be a lot less messy if you can cleanly
separate the fetching component from the mapper. Currently, svndump
re-creates the layout of
Jeff King p...@peff.net writes:
I still think your 2/2 is worth doing independently, though. It is silly
that git-prune will not mention pruned objects without -v, but will
mention temporary files. They should be in the same category.
Ok, so I'll queue it as a separate topic with a different
Nguyễn Thái Ngọc Duy skrev 2012-08-06 16.36:
+++ b/read-cache-v5.c
@@ -0,0 +1,1170 @@
+#include cache.h
+#include read-cache.h
+#include resolve-undo.h
+#include cache-tree.h
+
+struct cache_header_v5 {
+ unsigned int hdr_ndir;
+ unsigned int hdr_nfile;
+ unsigned int
On Tue, Aug 07, 2012 at 02:44:51PM -0700, Junio C Hamano wrote:
Ok, so I'll queue it as a separate topic with a different
justification.
-- 8 --
From: Brandon Casey draf...@gmail.com
Date: Mon, 6 Aug 2012 22:01:49 -0700
Subject: [PATCH] prune.c: only print informational message in
On 7 August 2012 17:39, Theodore Ts'o ty...@mit.edu wrote:
On Tue, Aug 07, 2012 at 05:25:02PM -0400, Eugene Sajine wrote:
rant
Don't want to accept HTML messages - fine. But don't tell me which
program to use for my email, especially when I'm sending totally valid
Perhaps this one:
On Tue, Aug 7, 2012 at 2:44 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
I still think your 2/2 is worth doing independently, though. It is silly
that git-prune will not mention pruned objects without -v, but will
mention temporary files. They should be in the
I've been toying with a git-remote-svn which uses fast-import (by
advertising the 'import' capability) to get data into Git.
Unfortunately, I can't get the result of any commands issued to
fast-import, as its stdout is not redirected, and the remote helper API
offers no alternative.
I tried
35 matches
Mail list logo
