Wincent Colaiuta writes:
> On Jul 14, 2012, at 10:25 PM, Junio C Hamano wrote:
>
>> I did not see anything wrong doing what you described in the
>> post-receive, even though having the hook in the "scratch" felt
>> strange, as the "copying from authoritative" would also want to be
>> automated an
On Jul 14, 2012, at 10:25 PM, Junio C Hamano wrote:
> Wincent Colaiuta writes:
>
>> Specifically, I was thinking of doing the following:
>>
>> - on pushing into our authoritative repo, we replicate to a second
>> "scratch" repo where all the dirty work gets done
>>
>> - the scratch repo has a
Štěpán Němec writes:
> - (glossary) the quotes around the Wikipedia URL prevented its
> linkification in frontends that support it; remove them
>
> - (manual) newer version (SHA-1) == following, older == preceding, not
> the other way around
>
> - trivial typo and wording fixes
>
> Signed-off
Wincent Colaiuta writes:
> At $day_job we want to start publishing a subtree of our codebase as
> open source. As we audit and prep more sections of the code base,
> we'll be broadening the subtree(s) that we export, until eventually we
> want as close as possible to the whole thing to be open so
Hi,
At $day_job we want to start publishing a subtree of our codebase as open
source. As we audit and prep more sections of the code base, we'll be
broadening the subtree(s) that we export, until eventually we want as close as
possible to the whole thing to be open source.
The resulting public
On 07/14/2012 11:46 AM, Stefan Näwe wrote:
From: Michael Haggerty alum.mit.edu>
Add a new Python script, contrib/hooks/post-receive-multimail.py, that
can be used to send notification emails describing pushes into a git
repository. This script is derived from
contrib/hooks/post-receive-mail, b
Perhaps having a file named something like:
.git_foreign_scm_empty_dir or some shorter name.
With the contents of the fast importer empty directory info put in there; If
any book keeping is needed.
It also looks like you strip out meta-data.
perhaps a file like:
.git_foreign_scm_metadata
We
On Sat, Jul 14, 2012 at 7:41 AM, Felix Natter wrote:
> hello,
>
> when converting a repo from bzr to git:
>
> mkdir freeplane-git1
> cd freeplane-git1
> git init .
> bzr fast-export --plain --export-marks=../marks.bzr ../trunk/ | git
> fast-import --export-marks=../marks.git
> git checkout
>
> Em
On Sun, Jul 15, 2012 at 12:26 AM, Junio C Hamano wrote:
> "Zeeshan Ali (Khattak)" writes:
>
>> What about '^' and '^^' that I suggested?
>>
While I see your "~" much distasteful compared to "^", you still
>>>
>>> s/dist/less dist/; sorry ;-)
>>
>> Why?
>
> That "^^" is the most important rea
- (glossary) the quotes around the Wikipedia URL prevented its
linkification in frontends that support it; remove them
- (manual) newer version (SHA-1) == following, older == preceding, not
the other way around
- trivial typo and wording fixes
Signed-off-by: Štěpán Němec
---
Documentation/
't' is currently always a numeric constant, but it can't hurt to
prepare for the day that it becomes useful for a caller to pass in a
more complex expression.
Suggested-by: Linus Torvalds
Signed-off-by: Jonathan Nieder
---
block-sha1/sha1.c |4 ++--
1 file changed, 2 insertions(+), 2 deleti
"Zeeshan Ali (Khattak)" writes:
> What about '^' and '^^' that I suggested?
>
>>> While I see your "~" much distasteful compared to "^", you still
>>
>> s/dist/less dist/; sorry ;-)
>
> Why?
That "^^" is the most important reason why your "^ is the same as
HEAD^" is flawed, and goes against my t
Looks good to me. I'd suggest doing the macro argument expansion in
#define SHA_SRC(t) get_be32((unsigned char *) block + t*4)
with parenthesis around 't', but that's a fairly independent thing.
The old code didn't do that either.
Linus
--
To unsubscribe from this list: send the lin
With 660231aa (block-sha1: support for architectures with memory
alignment restrictions, 2009-08-12), blk_SHA1_Update was modified to
access 32-bit chunks of memory one byte at a time on arches that
prefer that:
#define get_be32(p)( \
(*((unsigned char *)(p) + 0) << 24)
On Sat, Jul 14, 2012 at 11:34 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Stefan Näwe writes:
>>
>>> Zeeshan Ali (Khattak gnome.org> writes:
Many times I want to refer to 'HEAD^', 'HEAD^^' and sometimes even
further up the tree. It would be really nice if I didn't hav
Junio C Hamano writes:
> Stefan Näwe writes:
>
>> Zeeshan Ali (Khattak gnome.org> writes:
>>>
>>> Many times I want to refer to 'HEAD^', 'HEAD^^' and sometimes even
>>> further up the tree. It would be really nice if I didn't have to type
>>> 'HEAD^' but could only type '^'. Bash completion ma
Jeff King writes:
> But given that this is not even configurable in the current code, I
> really wonder if it needs to have its own color at all. Do people really
> want to set the color of this message separately? Maybe we should just
> use WT_STATUS_HEADER instead.
I would prefer that myself,
Stefan Näwe writes:
> Zeeshan Ali (Khattak gnome.org> writes:
>>
>> Many times I want to refer to 'HEAD^', 'HEAD^^' and sometimes even
>> further up the tree. It would be really nice if I didn't have to type
>> 'HEAD^' but could only type '^'. Bash completion make things easier
>> but it automa
Alexander Strasser writes:
> As the whole series is not that important I think it should be OK to
> wait a little longer, isn't it?
I thought the series queued in 'pu' was more or less done from my
point of view, but wanted to know if you wanted to polish it
further, as I prefer waiting for pe
On Sat, Jul 14, 2012 at 12:50 PM, Jonathan Nieder wrote:
> After the patch, what reason does gcc have to expect that 'block' is
> 32-bit aligned except when it is? The code (including the code I
> didn't touch) never casts from char * to int * except in get/put_be32
> on arches that don't mind un
Linus Torvalds wrote:
> On Sat, Jul 14, 2012 at 12:59 AM, Jonathan Nieder wrote:
>> Unfortunately, on big-endian architectures, if p is a pointer to
>> unsigned int then current gcc assumes it is properly aligned and
>> converts this construct to a 32-bit load.
>
> This patch seems to entirely de
On Sat, Jul 14, 2012 at 12:59 AM, Jonathan Nieder wrote:
>
> Unfortunately, on big-endian architectures, if p is a pointer to
> unsigned int then current gcc assumes it is properly aligned and
> converts this construct to a 32-bit load.
This patch seems to entirely depend on the location of the c
On 14.07.12 19:52, Michael J Gruber wrote:
> t3910 is skipped for most users because it requires a filesystem which
> does automatic conversion between different utf-8 types. Currently, this
> results in a skipped test with "no reason given".
>
> Use the skip_all mechanism from our test suite so t
t3910 is skipped for most users because it requires a filesystem which
does automatic conversion between different utf-8 types. Currently, this
results in a skipped test with "no reason given".
Use the skip_all mechanism from our test suite so that a reason for
skipping the test is given to the us
hello,
when converting a repo from bzr to git:
mkdir freeplane-git1
cd freeplane-git1
git init .
bzr fast-export --plain --export-marks=../marks.bzr ../trunk/ | git fast-import
--export-marks=../marks.git
git checkout
Empty directories are not contained in the git working index. This is
because
Andreas Schwab writes:
> Jeff King writes:
>
>> On Fri, Jul 13, 2012 at 11:04:21AM +0200, Andreas Schwab wrote:
>>
>>> > If you run only the bzr half of your command and inspect the output, you
>>> > will see that the file in question is mentioned twice. Once in a commit
>>> > on "refs/heads/ma
Hi,
Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with '-' are
> only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
[...]
> [New Topics]
>
> * as/t4012-style-updates (2012-07-12) 7 commits
> - t4012: use 'printf' instead of 'dd'
p...@padd.com wrote on Thu, 05 Jul 2012 08:30 -0400:
> l...@diamand.org wrote on Thu, 05 Jul 2012 08:20 +0100:
> > On 04/07/12 14:34, Pete Wyckoff wrote:
> > >The code is unused. Delete.
> >
> > I've used that non-interactive code path in the past, in the very
> > early days of using it (setting
On Sat, Jul 14, 2012 at 08:28:28AM -0400, Jeff King wrote:
> My intent was that this would also let "color.status.inprogress"
> override it, in case a user really wanted a green message or something.
> However, I notice that the original series did not add such a config
> option, so this color can
The "status" command recently learned to describe the
in-progress operation in its long output format (e.g.,
rebasing, am, etc). The color for this message defaults to
"normal" (i.e., no color). However, if the user has set
their default header color to something besides normal, then
the message st
I saw the problem first on pu, some time ago,
but it dissappeared after cloning git.git into another directory.
Now it appeared on next as well, so it's time to look a little bit deeper.
This test case of t1450 fails:
test_expect_success 'tag pointing to something else than its type' '
To debug
On Sat, Jul 14, 2012 at 12:37 PM, Tay Ray Chuan wrote:
> Hi Stefan,
>
> On Sat, Jul 14, 2012 at 5:46 PM, Stefan Näwe wrote:
>>
>> Do you have a fork of git.git somewhere that contains the script?
>> (I find it so much easier these days to simply fetch another repo instead
>> of applying patches w
Zeeshan Ali (Khattak gnome.org> writes:
>
> Hi,
> Many times I want to refer to 'HEAD^', 'HEAD^^' and sometimes even
> further up the tree. It would be really nice if I didn't have to type
> 'HEAD^' but could only type '^'. Bash completion make things easier
> but it automatically inserts a sp
alum.mit.edu> writes:
>
> From: Michael Haggerty alum.mit.edu>
>
> Add a new Python script, contrib/hooks/post-receive-multimail.py, that
> can be used to send notification emails describing pushes into a git
> repository. This script is derived from
> contrib/hooks/post-receive-mail, but ha
On Fri, Jul 13, 2012 at 03:12:47PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yeah, this was my analysis, too. Though reading get_revision-1, it seems
> > like we can actually set SHOWN, but I wasn't able to trigger any change
> > of behavior in practice. I think it is because we mus
With 660231aa (block-sha1: support for architectures with memory
alignment restrictions, 2009-08-12), blk_SHA1_Update was modified to
work reasonably on RISC-y architectures by accessing 32-bit values one
byte at a time on machines that prefer that:
#define get_unaligned_be32(p)( \
36 matches
Mail list logo
