* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Jeff King @ 2009-08-11 23:02 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Johannes Schindelin, Bert Wesarg, Junio C Hamano, Daniel Barkalow,
git, Brian Gernhardt
In-Reply-To: <20090812075914.6117@nanako3.lavabit.com>
On Wed, Aug 12, 2009 at 07:59:14AM +0900, Nanako Shiraishi wrote:
> Then how about using a prefix that has been invalid, "vcs::$string",
> for example?
I have no problem with that, and I think it makes it even more visually
obvious what is going. For example:
svn::http://server/path/to/repo
makes the "svn" prefix jump out a bit more.
-Peff
^ permalink raw reply
* Re: [PATCH] Change mentions of "git programs" to "git commands"
From: Nanako Shiraishi @ 2009-08-11 22:59 UTC (permalink / raw)
To: Ori Avtalion; +Cc: Junio C Hamano, git
In-Reply-To: <4A815AAC.2030601@avtalion.name>
Quoting Ori Avtalion <ori@avtalion.name>
> On 08/11/2009 06:58 AM, Nanako Shiraishi wrote:
>> From: Ori Avtalion<ori@avtalion.name>
>> Date: Fri, 7 Aug 2009 17:24:21 +0300
>> Subject: [PATCH] Change mentions of "git programs" to "git commands"
>>
>> Most of the docs and printouts refer to "commands" when discussing what
>> the end users call via the "git" top-level program. We should refer them
>> as "git programs" when we discuss the fact that the commands are
>> implemented as separate programs, but in other contexts, it is better to
>> use the term "git commands" consistently.
>>
>> Signed-off-by: Ori Avtalion<ori@avtalion.name>
>> Signed-off-by: Nanako Shiraishi<nanako3@lavabit.com>
>> ---
>>
>
> Thanks Nanako!
You're welcome, and sorry if I sounded as if I was accusing that you were
wasting other's time by not re-submitting sooner. I only wanted to see a
good patch go in.
> You might want to consider this patch too:
>
> diff --git a/Documentation/git-mailsplit.txt
> b/Documentation/git-mailsplit.txt
> index 5cc94ec..8f1b99b 100644
> --- a/Documentation/git-mailsplit.txt
> +++ b/Documentation/git-mailsplit.txt
> @@ -3,7 +3,7 @@ git-mailsplit(1)
>
> NAME
> ----
> -git-mailsplit - Simple UNIX mbox splitter program
> +git-mailsplit - Simple UNIX mbox splitter
>
> SYNOPSIS
> --------
Sorry, but I don't understand why it is necessary.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: block-sha1: improve code on large-register-set machines
From: Linus Torvalds @ 2009-08-11 22:57 UTC (permalink / raw)
To: Brandon Casey; +Cc: Nicolas Pitre, Git Mailing List, Junio C Hamano
In-Reply-To: <fLYKSyures_wcvAvAV9-MgKQlhk959HJpx-pKz7T1n-Mel7f2RBkMw@cipher.nrlssc.navy.mil>
On Tue, 11 Aug 2009, Brandon Casey wrote:
>
> In that case, why not change the interface of blk_SHA1Block() so that its
> second argument is const unsigned char* and get rid of __d and the { } ?
Because on big-endian, or on architectures like x86 that have an efficient
byte swap, that would be horrible.
You absoluetoy MUST NOT do things a byte at a time in those cases. The
memory operations and the shifting just kills you.
The reason you want to do things a byte at a time on ARM is that ARM
cannot do unaligned accesses well (very modern cores are better, but
rare), and that ARM has no bswap instruction and has fairly cheap shifts.
On no sane architecture is that true. Unaligned loads are fast (and quite
frankly, hardware where unaliged loads aren't fast is just crazy sh*t),
and doing 'bswap' is way faster than doing many shifts and masks.
So everything should be fundamentally word-oriented. Then, broken
architectures that can't handle it should split up the words, not the
other way around.
Linus
^ permalink raw reply
* Re: block-sha1: improve code on large-register-set machines
From: Linus Torvalds @ 2009-08-11 22:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0908111437160.10633@xanadu.home>
On Tue, 11 Aug 2009, Nicolas Pitre wrote:
>
> Well... gcc is really strange in this case (and similar other ones) with
> ARM compilation. A good indicator of the quality of the code is the
> size of the stack frame. When using the "+m" then gcc creates a 816
> byte stack frame, the generated binary grows by approx 3000 bytes, and
> performances is almost halved (7.600s). Looking at the assembly result
> I just can't figure out all the crazy moves taking place. Even the
> version with no barrier what so ever produces better assembly with a
> stack frame of 560 bytes.
Ok, that's just crazy. That function has a required stack size of exactly
64 bytes, and anything more than that is just spilling. And if you end up
with a stack frame of 560 bytes, that means that gcc is doing some _crazy_
spilling.
One thing that strikes me is that I've been just testing with gcc-4.4, and
BenH (who did some tests on PPC where SHA1 is just _trivial_ because it
all fits in the normal register space) noticed that older versions of gcc
that he tested did much worse on this.
I think Artur also posted (x86) numbers with older gcc versions doing
worse. Maybe you're seeing some of that?
Linus
^ permalink raw reply
* sharing git work while downstream from svn?
From: tom fogal @ 2009-08-11 22:55 UTC (permalink / raw)
To: git
How do others manage distributed version control when everyone is
forced to rebase all the time?
To give a concrete example: in one project where I have this issue,
there's a developer who is effectively 'downstream' from me. There's
a few other developers who are peers, w/ commit bits set on the
centralized server. I'll make some patches that should end up on our
centralized trunk, and some that our for our experimental sub-project,
so I use format-patch and send patches around for those.
This gets to be a mess when trunk changes: I'll rebase + potentially
fix some conflicts. Other developers with some of the experimental
patches will svn update, and get similar conflicts. These might differ
in subtle ways, and now exchanging patches gets more difficult.
I'm not sure getting them to use git would even help. Once I rebase,
I screw my downstream. Yet I can't avoid rebasing since I need to
update.
As I recall, some members of the gcc community are handling this
problem, somehow. How do you do it? Or do you just not collaborate at
the git level?
Thanks,
-tom
^ permalink raw reply
* Re: [EGIT] Push to GitHub caused corruption
From: John Bito @ 2009-08-11 22:52 UTC (permalink / raw)
To: git
In-Reply-To: <200908110810.45369.robin.rosenberg@gmail.com>
Running git fsck -full on the repo that I pushed from is clean.
Here's the git fsck -full from GitHub
<mojombo> git fsck --full
<mojombo> broken link from tree
f4f9ecd1875938baa42467dfd6a8134d75fe5de4 to tree
57548924f1eca854dc8db00844f95d3de2c82957
<mojombo> broken link from tree
f4f9ecd1875938baa42467dfd6a8134d75fe5de4 to tree
3d1f74522c3e7c3c03390fae376446fda6eed306
<mojombo> missing tree 3d1f74522c3e7c3c03390fae376446fda6eed306
<mojombo> missing tree 57548924f1eca854dc8db00844f95d3de2c82957
<mojombo> dangling commit ab6ce47159c1eaff0e4bae19291679267de9f669
The repo on GitHub is back where it was before the push. I have a
copy of the corrupt one from GitHub (358MB tar.gz). If there's
something I can do that would help to improve JGit/EGit, please let me
know.
Thanks,
John
On Mon, Aug 10, 2009 at 23:10, Robin Rosenberg<robin.rosenberg@gmail.com> wrote:
> måndag 10 augusti 2009 23:46:34 skrev John Bito <jwbito@gmail.com>:
>> Using the 'release' build of EGit (0.4.9.200906240051) I pushed a
>> commit to GitHub. After that, using git to pull, I get 'bad tree
>> object' resulting in 'remote: aborting due to possible repository
>> corruption on the remote side'. I had a similar problem back in April
>> (using integration builds of 0.4.0). I'm willing to investigate if
>> there's interest in finding the root of the problem.
>
> Fixing problems related to repository integrity is definitely interesting. One
> can live all kinds of problem, as long as they don't destroy anything.
>
> -- robin
>
>
^ permalink raw reply
* Re: How do gmail users try out patches from this list?
From: Nicolas Sebrecht @ 2009-08-11 22:14 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0908111343v73fa475fqb6353dcf2f718101@mail.gmail.com>
The 11/08/09, skillzero@gmail.com wrote:
> Sorry if this is dumb question, but I didn't see any good info in my searches.
>
> How do gmail users normally apply patches that come through the list?
It doesn't rely on your address mail provider but on your local email
workflow/MUA.
> Do you just manually copy and paste the email to patch files and use
> git apply? Do you use a tool to export to mbox files and use git am?
Yes, that's what most users do. As I use local maildirs instead of
mailboxes, I copy the patches (from mutt) into a dedicated maildir (one
per project) and directly 'git am' the e-mails.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [RFC PATCH v3 7/8] Support sparse checkout in unpack_trees() and read-tree
From: skillzero @ 2009-08-11 22:03 UTC (permalink / raw)
To: Jakub Narebski
Cc: Nguyễn Thái Ngọc Duy, git, Johannes Schindelin,
Junio C Hamano
In-Reply-To: <m3ab26owub.fsf@localhost.localdomain>
On Tue, Aug 11, 2009 at 2:38 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> skillzero@gmail.com writes:
>> 2009/8/11 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>
>> > [1] .git/info/sparse has the same syntax as .git/info/exclude. Files
>> > that match the patterns will be set as CE_VALID.
>>
>> Does this mean it will only support excluding paths you don't want
>> rather than letting you only include paths you do want?
>
> Errr... what I read is that paths set by .git/info/sparse would be
> excluded from checkout (marked as assume-unchanged / CE_VALID).
>
> But if it is the same mechanism as gitignore, then you can use !
> prefix to set files (patterns) to include, e.g.
>
> !Documentation/
> *
>
> (I think rules are processed top-down, first matching wins).
I wasn't sure because the .gitignore negation stuff mentions negating
a previously ignored pattern. But for sparse patterns, there likely
wouldn't be a previous pattern. Include patterns are a little
different in that if there are no include patterns (but maybe some
exclude patterns), I think the expectation is that everything will be
included (minus excludes), but if you have some include patterns then
only those paths will be included (minus any excludes).
It's great if it already supports includes as well as excludes
(although it's a little confusing to say !Documentation to mean
"include it"), but I wasn't sure from the comment so I was just
asking.
^ permalink raw reply
* Re: block-sha1: improve code on large-register-set machines
From: Brandon Casey @ 2009-08-11 21:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0908111735010.10633@xanadu.home>
Nicolas Pitre wrote:
> On Tue, 11 Aug 2009, Brandon Casey wrote:
>
>> Nicolas Pitre wrote:
>>> On Tue, 11 Aug 2009, Nicolas Pitre wrote:
>>>
>>>> On Tue, 11 Aug 2009, Linus Torvalds wrote:
>>>>
>>>>> On Tue, 11 Aug 2009, Nicolas Pitre wrote:
>>>>>> #define SHA_SRC(t) \
>>>>>> ({ unsigned char *__d = (unsigned char *)&data[t]; \
>>>>>> (__d[0] << 24) | (__d[1] << 16) | (__d[2] << 8) | (__d[3] << 0); })
>>>>>>
>>>>>> And this provides the exact same performance as the ntohl() based
>>>>>> version (4.980s) except that this now cope with unaligned buffers too.
>>>>> The actual object SHA1 calculations are likely not aligned (we do that
>>>>> object header thing), and if you can't do the htonl() any better way I
>>>>> guess the byte-based thing is the way to go..
>>> OK, even better: 4.400s.
>>>
>>> This is with this instead of the above:
>>>
>>> #define SHA_SRC(t) \
>>> ({ unsigned char *__d = (unsigned char *)data; \
>>> (__d[(t)*4 + 0] << 24) | (__d[(t)*4 + 1] << 16) | \
>>> (__d[(t)*4 + 2] << 8) | (__d[(t)*4 + 3] << 0); })
>>>
>>> The previous version would allocate a new register for __d and then
>>> index it with an offset of 0, 1, 2 or 3. This version always uses the
>>> register containing the data pointer with absolute offsets. The binary
>>> is a bit smaller too.
>> In that case, why not change the interface of blk_SHA1Block() so that its
>> second argument is const unsigned char* and get rid of __d and the { } ?
>
> Because not all architectures care to access the data bytewise. Please
> see the original SHA_SRC definition.
You mean this:
#define SHA_SRC(t) htonl(data[t])
? Or was there a definition before this one?
I don't follow what you are saying. Are you saying that the following two
examples are different?
unsigned int *data;
#define SHA_SRC(t) \
({ unsigned char *__d = (unsigned char *)data; \
(__d[(t)*4 + 0] << 24) | (__d[(t)*4 + 1] << 16) | \
(__d[(t)*4 + 2] << 8) | (__d[(t)*4 + 3] << 0); })
and
unsigned char *data;
#define SHA_SRC(t) \
( (data[(t)*4 + 0] << 24) | (data[(t)*4 + 1] << 16) | \
(data[(t)*4 + 2] << 8) | (data[(t)*4 + 3] << 0) )
-brandon
^ permalink raw reply
* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Jeff King @ 2009-08-11 21:48 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Bert Wesarg, Junio C Hamano, Daniel Barkalow, git,
Brian Gernhardt
In-Reply-To: <alpine.DEB.1.00.0908111817490.4638@intel-tinevez-2-302>
On Tue, Aug 11, 2009 at 06:20:54PM +0200, Johannes Schindelin wrote:
> > o [user@]host.xz:/path/to/repo.git/
>
> That is a valid concern. I'd suggest to disallow @ and . in the protocol
> name (maybe even everything non-alnum). For shortcuts that really read
> like "svn", I think it is not too much asked for to require adjusting the
> URL (by prefixing ssh:// and adjusting the path).
>
> If there is really anybody who uses Git via ssh to access a server called
> "svn", we could just as well have a little fun with them, don't you agree?
It is not actually that unreasonable. I have remotes which point to:
vcs:git/foo.git
where "vcs" is a shorthand for vcs.gtisc.gatech.edu, defined in my
.ssh/config (it's a machine which hosts several different version
control systems). So I could see somebody having something like "svn" if
they were, e.g., hosting a git-to-svn conversion on their company's svn
server.
And as far as asking people in such a situation to change, consider:
1. No matter how small a change, asking for a change means you are
breaking people's current config.
2. ssh:// really is inferior, especially if you are typing it on the
command-line as part of a one-off pull. It is really convenient to
assume you start in your home directory (as above), and to be able
to use tilde-notation to point to the home directories of others
(e.g., "git pull vcs:~mike/foo.git").
-Peff
^ permalink raw reply
* Re: [RFC PATCH v3 7/8] Support sparse checkout in unpack_trees() and read-tree
From: Jakub Narebski @ 2009-08-11 21:38 UTC (permalink / raw)
To: skillzero
Cc: Nguyễn Thái Ngọc Duy, git, Johannes Schindelin,
Junio C Hamano
In-Reply-To: <2729632a0908111418m57e03d8as9c122cbb52efc21a@mail.gmail.com>
skillzero@gmail.com writes:
> 2009/8/11 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> > [1] .git/info/sparse has the same syntax as .git/info/exclude. Files
> > that match the patterns will be set as CE_VALID.
>
> Does this mean it will only support excluding paths you don't want
> rather than letting you only include paths you do want?
Errr... what I read is that paths set by .git/info/sparse would be
excluded from checkout (marked as assume-unchanged / CE_VALID).
But if it is the same mechanism as gitignore, then you can use !
prefix to set files (patterns) to include, e.g.
!Documentation/
*
(I think rules are processed top-down, first matching wins).
> I'm currently using your other patch series that lets you include or
> exclude paths (via config variable) and I find that I mostly use the
> include side of it with only a few excluded paths. This is because I
> typically want to include only a small subset of the repository so
> using excludes would require a pretty large list and any time somebody
> adds new files, I'd have to update the exclude list.
Not true, see above.
--
Jakub Narebski
Git User's Survey 2009
http://tinyurl.com/GitSurvey2009
^ permalink raw reply
* Re: block-sha1: improve code on large-register-set machines
From: Nicolas Pitre @ 2009-08-11 21:36 UTC (permalink / raw)
To: Brandon Casey; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <fLYKSyures_wcvAvAV9-MgKQlhk959HJpx-pKz7T1n-Mel7f2RBkMw@cipher.nrlssc.navy.mil>
On Tue, 11 Aug 2009, Brandon Casey wrote:
> Nicolas Pitre wrote:
> > On Tue, 11 Aug 2009, Nicolas Pitre wrote:
> >
> >> On Tue, 11 Aug 2009, Linus Torvalds wrote:
> >>
> >>> On Tue, 11 Aug 2009, Nicolas Pitre wrote:
> >>>> #define SHA_SRC(t) \
> >>>> ({ unsigned char *__d = (unsigned char *)&data[t]; \
> >>>> (__d[0] << 24) | (__d[1] << 16) | (__d[2] << 8) | (__d[3] << 0); })
> >>>>
> >>>> And this provides the exact same performance as the ntohl() based
> >>>> version (4.980s) except that this now cope with unaligned buffers too.
> >>> The actual object SHA1 calculations are likely not aligned (we do that
> >>> object header thing), and if you can't do the htonl() any better way I
> >>> guess the byte-based thing is the way to go..
> >
> > OK, even better: 4.400s.
> >
> > This is with this instead of the above:
> >
> > #define SHA_SRC(t) \
> > ({ unsigned char *__d = (unsigned char *)data; \
> > (__d[(t)*4 + 0] << 24) | (__d[(t)*4 + 1] << 16) | \
> > (__d[(t)*4 + 2] << 8) | (__d[(t)*4 + 3] << 0); })
> >
> > The previous version would allocate a new register for __d and then
> > index it with an offset of 0, 1, 2 or 3. This version always uses the
> > register containing the data pointer with absolute offsets. The binary
> > is a bit smaller too.
>
> In that case, why not change the interface of blk_SHA1Block() so that its
> second argument is const unsigned char* and get rid of __d and the { } ?
Because not all architectures care to access the data bytewise. Please
see the original SHA_SRC definition.
Nicolas
^ permalink raw reply
* Re: git gc expanding packed data?
From: Nicolas Pitre @ 2009-08-11 21:33 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: git
In-Reply-To: <3ace41890908110317k6e6ada07jc39ea446f9fa246e@mail.gmail.com>
On Tue, 11 Aug 2009, Hin-Tak Leung wrote:
> On Wed, Aug 5, 2009 at 11:39 PM, Nicolas Pitre<nico@cam.org> wrote:
> > Anyway... To solve your problem, you simply need to run 'git gc' with
> > the --prune=now argument to disable that grace period and get rid of
> > those unreferenced objects right away (safe only if no other git
> > activities are taking place at the same time which should be easy to
> > ensure on a workstation). The resulting .git/objects directory size
> > will shrink to about 441 MB. If the gcc.gnu.org git server was doing
> > its job properly, the size of the clone transfer would also be
> > significantly smaller, meaning around 414 MB instead of the current 600+
> > MB.
> >
> > And BTW, using 'git gc --aggressive' with a later git version (or
> > 'git repack -a -f -d --window=250 --depth=250') gives me a .git/objects
> > directory size of 310 MB, meaning that the actual repository with all
> > the trunk history is _smaller_ than the actual source checkout. If that
> > repository was properly repacked on the server, the clone data transfer
> > would be 283 MB. This is less than half the current clone transfer
> > size.
> >
> >
> > Nicolas
> >
>
> 'git gc --prune=now' does work, but 'git gc --prune=now --aggressive'
> (before) and 'git gc --aggressive' (after) both create very large
> (>2GB; I stopped it) packs from the ~400MB-600MB packed objects. I
> noted that you specifically wrote 'with a later git version' -
> presumably there is a some sort of a known and fixed issue there? Just
> curious.
>From git v1.6.3 the --aggressive switch makes for 'git repack' to be
called with --window=250 --depth=250, meaning the equivalent of:
git repack -a -d -f --window=250 --depth=250
Do you still get a huge pack with the above?
> I guess --aggressive doesn't always save space...
If so that is (and was) a bug.
Nicolas
^ permalink raw reply
* Re: How do gmail users try out patches from this list?
From: Emmanuel Trillaud @ 2009-08-11 21:24 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0908111355m1a15d81cs7f33e1bbc5e1701b@mail.gmail.com>
Huuu! Sorry!
I read your mail too fast.
If you manage to save the interresting mails localy in the mailbox
format (claws mail and thunderbird can do that), you can
then use 'git am' to apply the patches (an example:
http://www.kernel.org/pub/software/scm/git/docs/everyday.html#Integrator).
Best regards
Emmanuel Trillaud
Le Tue, 11 Aug 2009 13:55:38 -0700,
Sverre Rabbelier <srabbelier@gmail.com> a écrit :
> Heya,
>
> On Tue, Aug 11, 2009 at 13:47, Emmanuel Trillaud<etrillaud@gmail.com>
> wrote:
> > To quote Documentation/SubmittingPatches:
>
> Not relevant, these instructions are for the other way around; that
> is, sending your patches _to_ the ML, rather than getting patches
> _from_ the ML.
>
^ permalink raw reply
* Re: block-sha1: improve code on large-register-set machines
From: Brandon Casey @ 2009-08-11 21:20 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0908111517390.10633@xanadu.home>
Nicolas Pitre wrote:
> On Tue, 11 Aug 2009, Nicolas Pitre wrote:
>
>> On Tue, 11 Aug 2009, Linus Torvalds wrote:
>>
>>> On Tue, 11 Aug 2009, Nicolas Pitre wrote:
>>>> #define SHA_SRC(t) \
>>>> ({ unsigned char *__d = (unsigned char *)&data[t]; \
>>>> (__d[0] << 24) | (__d[1] << 16) | (__d[2] << 8) | (__d[3] << 0); })
>>>>
>>>> And this provides the exact same performance as the ntohl() based
>>>> version (4.980s) except that this now cope with unaligned buffers too.
>>> The actual object SHA1 calculations are likely not aligned (we do that
>>> object header thing), and if you can't do the htonl() any better way I
>>> guess the byte-based thing is the way to go..
>
> OK, even better: 4.400s.
>
> This is with this instead of the above:
>
> #define SHA_SRC(t) \
> ({ unsigned char *__d = (unsigned char *)data; \
> (__d[(t)*4 + 0] << 24) | (__d[(t)*4 + 1] << 16) | \
> (__d[(t)*4 + 2] << 8) | (__d[(t)*4 + 3] << 0); })
>
> The previous version would allocate a new register for __d and then
> index it with an offset of 0, 1, 2 or 3. This version always uses the
> register containing the data pointer with absolute offsets. The binary
> is a bit smaller too.
In that case, why not change the interface of blk_SHA1Block() so that its
second argument is const unsigned char* and get rid of __d and the { } ?
Then it will look like this:
static void blk_SHA1Block(blk_SHA_CTX *ctx, const unsigned char *data);
...
#define SHA_SRC(t) \
( (data[(t)*4 + 0] << 24) | (data[(t)*4 + 1] << 16) | \
(data[(t)*4 + 2] << 8) | (data[(t)*4 + 3] << 0) )
Plus, we need something like the following to handle storing the hash to
an unaligned buffer (warning copy/pasted):
@@ -73,8 +74,12 @@ void blk_SHA1_Final(unsigned char hashout[20], blk_SHA_CTX *c
/* Output hash
*/
- for (i = 0; i < 5; i++)
- ((unsigned int *)hashout)[i] = htonl(ctx->H[i]);
+ for (i = 0; i < 5; i++) {
+ *hashout++ = (unsigned char) (ctx->H[i] >> 24);
+ *hashout++ = (unsigned char) (ctx->H[i] >> 16);
+ *hashout++ = (unsigned char) (ctx->H[i] >> 8);
+ *hashout++ = (unsigned char) (ctx->H[i] >> 0);
+ }
}
#if defined(__i386__) || defined(__x86_64__)
With these two changes plus a few other minor tweaks, the block-sha1 code compiles
and passes the test suite on sparc (solaris 7) and mips (irix 6.5).
-brandon
^ permalink raw reply
* Re: [RFC PATCH v3 7/8] Support sparse checkout in unpack_trees() and read-tree
From: skillzero @ 2009-08-11 21:18 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1250005446-12047-8-git-send-email-pclouds@gmail.com>
2009/8/11 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> [1] .git/info/sparse has the same syntax as .git/info/exclude. Files
> that match the patterns will be set as CE_VALID.
Does this mean it will only support excluding paths you don't want
rather than letting you only include paths you do want?
I'm currently using your other patch series that lets you include or
exclude paths (via config variable) and I find that I mostly use the
include side of it with only a few excluded paths. This is because I
typically want to include only a small subset of the repository so
using excludes would require a pretty large list and any time somebody
adds new files, I'd have to update the exclude list.
I appreciate the flexibility of the script to control what is included
or excluded, but like some other comments here, I like the simplicity
of having built-in support for including/excluding paths without
having to write a script to do it. Some of my projects run on Windows
so scripting is more difficult there.
^ permalink raw reply
* Re: RFC for 1.7: Do not checkout -b master origin/master on clone
From: Santi Béjar @ 2009-08-11 21:06 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4A818B90.9050206@drmicha.warpmail.net>
2009/8/11 Michael J Gruber <git@drmicha.warpmail.net>:
> One common source of confusion for newcomers is the fact that master is
> given such a special treatment in git. While it is certainly okay and
> helpful to set up a default branch in a new repository (git init) it is
> not at all clear why it should be treated specially in any other
> situation, such as:
>
> - Why is master the only local branch which git clone sets up (git
> checkout -b master origin/master)?
Because master is the default branch in the remote repository?
[...]
> This behaviour not only is hard to justify; in fact it gives users a
> completely wrong impression: by pretending that master is special,
It is not hard to justify (the git clone behavior). master is not
special, it is just the default branch, but you can change it changing
the HEAD symlink.
> but
> also by hiding core concepts (distinguishing local/remote branches,
> detached heads) from the user at a point where that very hiding leads to
> confusion.
>
> Under the hood, it is of course HEAD which is given special treatment
> (and which in the majority of repos points to master), and git clone
> sets up a local branch according to HEAD (and does some other guess work
> when cloning bare repos), which means that git clone shows the same
> "random" behaviour which git svn clone does: Which local branch is set
> up by default depends on the current value of HEAD/most recent commit at
> the time of the cloning operation.
It's not random. And please don't mix the "git clone" and "git svn" case.
> So, I suggest that starting with git 1.7:
>
> - git clone does not set up any local branches at all
I think you should first think if this is going to really help
newcomers. I think this would be worst.
Instead of "why only 'master'?" the question will be "why I don't get
any files in the workdir?"
"git clone checks out the default branch, and this is 'master' by
default" is not that hard.
HTH,
Santi
^ permalink raw reply
* Re: [RFC PATCH v2 4/4] read-tree: add --no-sparse to turn off sparse hook
From: Nguyen Thai Ngoc Duy @ 2009-08-11 7:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0908110846050.4638@intel-tinevez-2-302>
On Tue, Aug 11, 2009 at 1:50 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
>> Why not making the hook to be skipped by default, and pass an explicit
>> option to trigger the hook?
>>
>> I like Dscho's other suggestion to use patterns like .gitignore instead
>> of using hook scripts that needs to be ported across platforms, by the
>> way.
>
> I forgot to mention that I checked dir.c to verify that
> add_excludes_from_file_1() (which is static, so you'll either need to use
> it in the same file, or even better, export it renaming it to something
> like add_excludes_from_file_to_list()) and excluded_1() (same here)
> already do a large part of what you need.
Indeed (and I have that code too). I still like the hook though
because you have more freedom in defining your worktree (and yes, less
portable). I wanted to make something generic enough that you can
build higher "strategies" on top, like .gitignore-based patterns.
Anyway I'll send out another patch for .gitignore patterns tonight and
see how it goes.
--
Duy
^ permalink raw reply
* Re: How do gmail users try out patches from this list?
From: Sverre Rabbelier @ 2009-08-11 20:55 UTC (permalink / raw)
To: Emmanuel Trillaud; +Cc: skillzero, git
In-Reply-To: <20090811224717.785dcd27@eleanor>
Heya,
On Tue, Aug 11, 2009 at 13:47, Emmanuel Trillaud<etrillaud@gmail.com> wrote:
> To quote Documentation/SubmittingPatches:
Not relevant, these instructions are for the other way around; that
is, sending your patches _to_ the ML, rather than getting patches
_from_ the ML.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: How do gmail users try out patches from this list?
From: Emmanuel Trillaud @ 2009-08-11 20:47 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0908111343v73fa475fqb6353dcf2f718101@mail.gmail.com>
To quote Documentation/SubmittingPatches:
GMail does not appear to have any way to turn off line wrapping in the web
interface, so this will mangle any emails that you send. You can however
use any IMAP email client to connect to the google imap server, and
forward the emails through that. Just make sure to disable line wrapping
in that email client. Alternatively, use "git send-email" instead.
Submitting properly formatted patches via Gmail is simple now that
IMAP support is available. First, edit your ~/.gitconfig to specify your
account settings:
[imap]
folder = "[Gmail]/Drafts"
host = imaps://imap.gmail.com
user = user@gmail.com
pass = p4ssw0rd
port = 993
sslverify = false
You might need to instead use: folder = "[Google Mail]/Drafts" if you get
an error that the "Folder doesn't exist".
Next, ensure that your Gmail settings are correct. In "Settings" the
"Use Unicode (UTF-8) encoding for outgoing messages" should be checked.
Once your commits are ready to send to the mailing list, run the following
command to send the patch emails to your Gmail Drafts folder.
$ git format-patch -M --stdout origin/master | git imap-send
Go to your Gmail account, open the Drafts folder, find the patch email,
fill in the To: and CC: fields and send away!
Best Regards
Emmanuel Trillaud
Le Tue, 11 Aug 2009 13:43:13 -0700,
skillzero@gmail.com a écrit :
> Sorry if this is dumb question, but I didn't see any good info in my
> searches.
>
> How do gmail users normally apply patches that come through the list?
> Do you just manually copy and paste the email to patch files and use
> git apply? Do you use a tool to export to mbox files and use git am?
>
> I've been just doing it manually via copy and paste, but it's kinda
> tedious. --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Limit git-gui to display a maximum number of files
From: Dan Zwell @ 2009-08-11 18:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List, raa.lkml
In-Reply-To: <20090811202927.GZ1033@spearce.org>
When there is a large number of new or modified files,
"display_all_files" takes a long time, and git-gui appears to
hang. This change limits the number of files that are displayed.
This limit can be set as gui.maxfilesdisplayed, and is
5000 by default.
A warning is shown when the list of files is truncated.
Signed-off-by: Dan Zwell <dzwell@zwell.net>
---
git-gui.sh | 17 ++++++++++++++++-
po/git-gui.pot | 5 +++++
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 3c0ce26..eae1f81 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -745,6 +745,8 @@ set default_config(gui.newbranchtemplate) {}
set default_config(gui.spellingdictionary) {}
set default_config(gui.fontui) [font configure font_ui]
set default_config(gui.fontdiff) [font configure font_diff]
+# TODO: this option should be added to the git-config documentation
+set default_config(gui.maxfilesdisplayed) 5000
set font_descs {
{fontui font_ui {mc "Main Font"}}
{fontdiff font_diff {mc "Diff/Console Font"}}
@@ -1698,10 +1700,12 @@ proc display_all_files_helper {w path icon_name m} {
$w insert end "[escape_path $path]\n"
}
+set files_warning 0
proc display_all_files {} {
global ui_index ui_workdir
global file_states file_lists
global last_clicked
+ global files_warning
$ui_index conf -state normal
$ui_workdir conf -state normal
@@ -1713,7 +1717,18 @@ proc display_all_files {} {
set file_lists($ui_index) [list]
set file_lists($ui_workdir) [list]
- foreach path [lsort [array names file_states]] {
+ set to_display [lsort [array names file_states]]
+ set display_limit [get_config gui.maxfilesdisplayed]
+ if {[llength $to_display] > $display_limit} {
+ if {!$files_warning} {
+ # do not repeatedly warn:
+ set files_warning 1
+ info_popup [mc "Displaying only %s of %s files." \
+ $display_limit [llength $to_display]]
+ }
+ set to_display [lrange $to_display 0 [expr {$display_limit-1}]]
+ }
+ foreach path $to_display {
set s $file_states($path)
set m [lindex $s 0]
set icon_name [lindex $s 1]
diff --git a/po/git-gui.pot b/po/git-gui.pot
index 53b7d36..074582d 100644
--- a/po/git-gui.pot
+++ b/po/git-gui.pot
@@ -90,6 +90,11 @@ msgstr ""
msgid "Ready."
msgstr ""
+#: git-gui.sh:1726
+#, tcl-format
+msgid "Displaying only %s of %s files."
+msgstr ""
+
#: git-gui.sh:1819
msgid "Unmodified"
msgstr ""
--
1.6.4
^ permalink raw reply related
* Re: unpack a single object
From: Bryan Donlan @ 2009-08-11 20:49 UTC (permalink / raw)
To: tarmigan; +Cc: Git Mailing List
In-Reply-To: <3e8340490908111348o5df64aa1md1ad8901e857ecb6@mail.gmail.com>
On Tue, Aug 11, 2009 at 4:48 PM, Bryan Donlan<bdonlan@gmail.com> wrote:
> On Tue, Aug 11, 2009 at 4:15 PM, tarmigan<tarmigan+lists@gmail.com> wrote:
>> Hi,
>>
>> At work we use SVN. To deal with this I mirror the svn repo with
>> git-svn and have a cron job that runs git svn rebase every hour, and
>> then I rebase from that git repo.
>>
>> Unfortunately, on the computer that runs the cron job, /home ran out
>> of space. After making more space and deleting the
>> svn/trunk/.rev_map, my 'git svn rebase' dies with a
>>> git svn rebase
>> Rebuilding .git/svn/trunk/.rev_map.4279b43a-dd95-8640-b069-b0d2992e4ff2 ...
>> error: Could not read 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
>> fatal: Failed to traverse parents of commit
>> 31c4379db99f05d0942e7c204b38f7b587fb4d3b
>> rev-list --pretty=raw --no-color --reverse refs/remotes/trunk --:
>> command returned error: 128
>>
>> So I look for corruption with
>>> git fsck --full --strict
>> broken link from commit 31c4379db99f05d0942e7c204b38f7b587fb4d3b
>> to commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
>> dangling blob a6027cd01178f19243342c0f6ccaef8fb798dcf4
>> <snipped more dangling blobs>
>> dangling blob 4348d7ebd189208716b44bcf4198c1f29d18e6c3
>> missing commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce ******
>> dangling blob 22757bac2e3433cccd9d7e32fa79d90031e14353
>> dangling blob 1276575eca02976ff677b61a6873562db7db31d7
>> dangling blob f98343007ac9d2f33a81fe25f4d446b045c3167a
>> dangling blob d29043a6e2b87cd0be1f3fb39f0c88283b79409b
>> dangling blob f7d08b39830709c044279d17d3d85cbe813998bb
>> dangling blob 64f14b305164f65c788dc9970deb7dfc79ac7446
>>
>> Thankfully, I have copies of the repo and this object (3d4c2b) in
>> other location and that passes git-fsck. Strangely, it is a commit
>> object from about 18 month ago and should have been in a pack for a
>> long time, so maybe running out of disk space was not the cause.
>>
>> I would rather not copy the whole good repo back to the one that ran
>> out of space because it's multiple gigs. My plan is to just explode
>> the bad pack on of the corrupted repo, explode good pack and then,
>> copy the corrupted object back. So my question is how do I tell which
>> pack contains that object? (I would rather not explode all the packs
>> because of the repo size.) Is there a way to extract a single object
>> from a pack without exploding the whole pack?
>
> You should be able to just extract the single object in question:
>
> goodrepo$ git cat-file commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
> > ~/commit.dat
> goodrepo$ cd ~/badrepo
> badrepo$ git read-file -t commit ~/commit.dat
> (should output 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce)
>
> At this point your repo should be repaired.
>
Err, that should read git hash-object, not git read-file.
^ permalink raw reply
* Re: unpack a single object
From: Bryan Donlan @ 2009-08-11 20:48 UTC (permalink / raw)
To: tarmigan; +Cc: Git Mailing List
In-Reply-To: <905315640908111315j459b81f2jc414f2a09c6b830e@mail.gmail.com>
On Tue, Aug 11, 2009 at 4:15 PM, tarmigan<tarmigan+lists@gmail.com> wrote:
> Hi,
>
> At work we use SVN. To deal with this I mirror the svn repo with
> git-svn and have a cron job that runs git svn rebase every hour, and
> then I rebase from that git repo.
>
> Unfortunately, on the computer that runs the cron job, /home ran out
> of space. After making more space and deleting the
> svn/trunk/.rev_map, my 'git svn rebase' dies with a
>> git svn rebase
> Rebuilding .git/svn/trunk/.rev_map.4279b43a-dd95-8640-b069-b0d2992e4ff2 ...
> error: Could not read 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
> fatal: Failed to traverse parents of commit
> 31c4379db99f05d0942e7c204b38f7b587fb4d3b
> rev-list --pretty=raw --no-color --reverse refs/remotes/trunk --:
> command returned error: 128
>
> So I look for corruption with
>> git fsck --full --strict
> broken link from commit 31c4379db99f05d0942e7c204b38f7b587fb4d3b
> to commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
> dangling blob a6027cd01178f19243342c0f6ccaef8fb798dcf4
> <snipped more dangling blobs>
> dangling blob 4348d7ebd189208716b44bcf4198c1f29d18e6c3
> missing commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce ******
> dangling blob 22757bac2e3433cccd9d7e32fa79d90031e14353
> dangling blob 1276575eca02976ff677b61a6873562db7db31d7
> dangling blob f98343007ac9d2f33a81fe25f4d446b045c3167a
> dangling blob d29043a6e2b87cd0be1f3fb39f0c88283b79409b
> dangling blob f7d08b39830709c044279d17d3d85cbe813998bb
> dangling blob 64f14b305164f65c788dc9970deb7dfc79ac7446
>
> Thankfully, I have copies of the repo and this object (3d4c2b) in
> other location and that passes git-fsck. Strangely, it is a commit
> object from about 18 month ago and should have been in a pack for a
> long time, so maybe running out of disk space was not the cause.
>
> I would rather not copy the whole good repo back to the one that ran
> out of space because it's multiple gigs. My plan is to just explode
> the bad pack on of the corrupted repo, explode good pack and then,
> copy the corrupted object back. So my question is how do I tell which
> pack contains that object? (I would rather not explode all the packs
> because of the repo size.) Is there a way to extract a single object
> from a pack without exploding the whole pack?
You should be able to just extract the single object in question:
goodrepo$ git cat-file commit 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce
> ~/commit.dat
goodrepo$ cd ~/badrepo
badrepo$ git read-file -t commit ~/commit.dat
(should output 3d4c2b0225e7605a7e2a38ffc44dcb888589f4ce)
At this point your repo should be repaired.
^ permalink raw reply
* Re: How do gmail users try out patches from this list?
From: Russ Dill @ 2009-08-11 20:47 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0908111343v73fa475fqb6353dcf2f718101@mail.gmail.com>
> Sorry if this is dumb question, but I didn't see any good info in my searches.
>
> How do gmail users normally apply patches that come through the list?
> Do you just manually copy and paste the email to patch files and use
> git apply? Do you use a tool to export to mbox files and use git am?
>
> I've been just doing it manually via copy and paste, but it's kinda tedious.
Use the POP or IMAP to access your gmail account.
^ permalink raw reply
* How do gmail users try out patches from this list?
From: skillzero @ 2009-08-11 20:43 UTC (permalink / raw)
To: git
Sorry if this is dumb question, but I didn't see any good info in my searches.
How do gmail users normally apply patches that come through the list?
Do you just manually copy and paste the email to patch files and use
git apply? Do you use a tool to export to mbox files and use git am?
I've been just doing it manually via copy and paste, but it's kinda tedious.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).