Jeff King 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 install{,-doc,-ht
Hi Karsten,
Thanks, you helped me a lot. I see now, that logoutputencoding
is for commit header data, not for whole log output. The name
is little missleading, so do description:
i18n.logOutputEncoding
Encoding to use when displaying logs.
Regarding git-log / git-diff output, there are basica
Jeff King writes:
> The data looks OK in user-manual.texi, but "--" is converted to "-" in
> git.info. So either:
>
> 1. There is a bug in makeinfo, which should not be doing this
> conversion inside a "@display" section.
The texinfo manual says that @display does not change the font (unl
On Tue, Aug 7, 2012 at 12:46 AM, Junio C Hamano 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).
>
> For exampl
On 08/05, Junio C Hamano wrote:
> Thomas Gummerer 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)
> >
> > e
On 08/05, Junio C Hamano wrote:
> Thomas Gummerer 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 with any
Excerpts from Jeff King's message of Tue Aug 07 00:10:26 -0400 2012:
> Signed-off-by: Jeff King
Acked-by: Ben Walton
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
require the migration then it can become part
Brandon Casey writes:
> On Mon, Aug 6, 2012 at 11:03 PM, Jeff King 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-
Thomas Gummerer 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 its
callee where
On 08/05, Junio C Hamano wrote:
> Thomas Gummerer 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 cache-entries as
smudge m
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 that
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
931259a22e9d126c5c48deea0c
On Tue, Aug 07, 2012 at 08:22:21PM +0200, Felix Natter wrote:
> 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 --ag
On 08/05, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > + stat_crc = crc32(stat_crc, (Bytef*)&stat, 4);
> > + stat = htonl(ce->ce_ino);
> > + stat_crc = crc32(stat_crc, (Bytef*)&stat, 4);
> > + stat = htonl(ce->ce_size);
> > + stat_crc = crc32(stat_crc, (Bytef*)&stat, 4);
> > +
Jeff King writes:
> So the packing parameters are the same these days for either method.
> Note that "git gc --aggressive" will also use "-f" to recompute all
> deltas. This is more expensive, but gives git more flexibility if the
> old deltas were sub-optimal (typically, this is the case if the
On 08/05, Junio C Hamano wrote:
> Thomas Gummerer 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 time, an
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 messa
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 bug).
Before you ask, no I very much doubt vger will change it's policy with
On Tue, Aug 07, 2012 at 09:17:50AM +0200, David Kastrup wrote:
> Not really: @display does not change fonts, merely indentation. From
> the Texinfo manual:
> [...]
> But in non-typewriter fonts, -- is a shorthand for an en-dash (see
> "conventions" in the Texinfo manual):
Thanks, that's the miss
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 a
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 th
Greetings,
we maintain a "central/main" git repository which our developers clone
from. We want to synchronize this "central" git repository with
Subversion. I know this is not the recommended way to do this, but this
was the choice that was made. The "central" git repository was originally
Peter Baumann 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 contain wrong da
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 malign
On Tue, Aug 7, 2012 at 4:55 PM, Theodore Ts'o 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 have a
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 la
On Tue, Aug 07, 2012 at 05:25:02PM -0400, Eugene Sajine wrote:
>
> 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
> message, so take my plain text message part and use it.
>
The problem is that HTML mess
Jeff King 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
justifica
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 h
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
> Date: Mon, 6 Aug 2012 22:01:49 -0700
> Subject: [PATCH] prune.c: only print informational message in show_only or
> v
On 7 August 2012 17:39, Theodore Ts'o wrote:
> On Tue, Aug 07, 2012 at 05:25:02PM -0400, Eugene Sajine wrote:
>>
>> 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:
https://code.google.c
On Tue, Aug 7, 2012 at 2:44 PM, Junio C Hamano wrote:
> Jeff King 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,
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 m
Thomas Rast 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 was added to the GSoC
Junio C Hamano 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 in v2 (pro
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 g...@github.com:ope
Nguyen Thai Ngoc Duy 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 wants to add, yo
Rich Pixley 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
> rich@cobra> git r
[..]
> - 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 o
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 longer
On Tue, Aug 07, 2012 at 08:45:10PM +, Eric Wong wrote:
> Peter Baumann 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 th
42 matches
Mail list logo
