On Mon, Oct 28, 2013 at 3:46 AM, Johan Herland wrote:
> On Sun, Oct 27, 2013 at 8:04 PM, Christian Couder
> wrote:
>>
>> If "git commit" processes these arguments and puts the result in the
>> commit message file that is passed to the
>> prepare-commit-msg hook, then this hook can still get them
Hi,
What can be done to limit amount of space occupied on clone and checkout? I
know about shallow clone and sparse checkout, anything else?
Preferably I would split repository into multiple repositories but I worry that
working with multiple directories would be much more troublesome. But ma
Guten Tag ,
Bitte nehmen Sie meine aufrichtigen Entschuldigungen an, wenn meine E-mail Ihre
persönliche Ethik nicht trifft.
Für ich weiß, dass dies wie ein vollständiges Eindringen zu Ihrer Ruhe scheinen
kann, aber zurzeit ,dies ist meine Option für Kommunikation zu Ihnen.
Dies könnte fremd o
Guten Tag ,
Bitte nehmen Sie meine aufrichtigen Entschuldigungen an, wenn meine E-mail Ihre
persönliche Ethik nicht trifft.
Für ich weiß, dass dies wie ein vollständiges Eindringen zu Ihrer Ruhe scheinen
kann, aber zurzeit ,dies ist meine Option für Kommunikation zu Ihnen.
Dies könnte fremd o
On Mon, Oct 28, 2013 at 10:08 AM, Junio C Hamano wrote:
>
> Thinking aloud further, what I had in mind was along the lines of
> the following.
>
> * The most generic external interface would be spelled as
>
> --trailer [=]
>
>where can be things like "signoff", "closes", "acked-by",
>
Due to an interaction between the way libcurl handles GSSAPI authentication over
HTTP and the way git uses libcurl, large pushes (those over http.postBuffer
bytes) would fail due to an authentication failure requiring a rewind of the
curl buffer. Such a rewind was not possible because the data did
On Sat, Oct 26, 2013 at 10:34:42PM +, brian m. carlson wrote:
> Enable the use of the Expect: 100-continue header for large requests where the
> server offers GSSAPI authentication to avoid this issue, since the request
> would
> otherwise fail. This allows git to get the authentication data
On Mon, Oct 28, 2013 at 12:29:32PM +0100, Johan Herland wrote:
> > A hook-based solution could do this. But a built-in "all-purpose"
> > handler like "footer.Fixes.arg=commit", which was intended to be
> > reusable, wouldn't be able to do such footer-specific extra work without
> > having to crea
On Mon, Oct 28, 2013 at 11:10:13PM +0100, Thomas Rast wrote:
> * In your list
>
> > Fixes:
> > Reported-by:
> > Suggested-by:
> > Improved-by:
> > Acked-by:
> > Reviewed-by:
> > Tested-by:
> > Signed-off-by:
>
> and I might add
>
> Cherry-picked-from:
> Reverts:
>
>
On Mon, Oct 28, 2013 at 01:57:13PM -0700, Junio C Hamano wrote:
> > +i5601=0
> > +# $1 url
> > +# $2 none|host
> > +# $3 path
> > +test_clone_url () {
> > + i5601=$(($i5601 + 1))
> > + >"$TRASH_DIRECTORY/ssh-output" &&
> > + test_might_fail git clone "$1" tmp$i5601 &&
> > {
> > -
On Mon, Oct 28, 2013 at 09:16:19PM +0100, Torsten Bögershausen wrote:
> Commit 8d3d28f5 added test cases for URLs which should be ssh.
>
> Add more tests testing all the combinations:
> -IPv4 or IPv6
> -path starting with "/" or with "/~"
> -with and without the ssh:// scheme
>
> Add tests fo
On Tue, Oct 29, 2013 at 01:54:31AM +0100, Simon Ruderich wrote:
> I just compiled Git v1.8.4.2 on Debian Wheezy amd64 and test
> t5570 fails (with GIT_TEST_GIT_DAEMON=1):
> [...]
> Bisecting leads to this commit:
>
> commit 68b939b2f097b6675c4aaa17869aa81b25cb
> Author: Jeff King
>
As of the last commit, we can use "perl" instead of
"$PERL_PATH" when running tests, as the former is now a
function which uses the latter. As the shorter "perl" is
easier on the eyes, let's switch to using it everywhere.
This is not quite a mechanical s/$PERL_PATH/perl/
replacement, though. There
Once upon a time, we assumed that calling a bare "perl" in
the test scripts was OK, because we would find the perl from
the user's PATH, and we were only asking that perl to do
basic operations that work even on old versions of perl.
Later, we found that some systems really prefer to use
$PERL_PAT
Several of the built shell commands invoke a bare "perl" to
perform some one-liners. This will use the first perl in the
PATH rather than the one specified by the user's SHELL_PATH.
We are not asking these perl invocations to do anything
exotic, so typically any old system perl will do; however,
in
On Mon, Oct 28, 2013 at 02:04:20PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Speaking of which, is there any reason to use the ugly "$PERL_PATH"
> > everywhere, and not simply do:
> >
> > perl () {
> > "$PERL_PATH" "$@"
> > }
> >
> > in test-lib.sh?
>
> Sounds like a nice po
Hello,
I just compiled Git v1.8.4.2 on Debian Wheezy amd64 and test
t5570 fails (with GIT_TEST_GIT_DAEMON=1):
--- expect 2013-10-28 23:27:26.792409631 +
+++ output 2013-10-28 23:27:26.788409614 +
@@ -1 +1,2 @@
+Cloning into 'nowhere'...
fatal: remote error:
On Tue, Oct 29, 2013 at 10:09:53AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2013-10-28 at 09:59 +0100, Christoph Hellwig wrote:
> > Btw, can we please take away this discussion from ksummit-attendees? It's
> > got
> > absolutely nothing to do with kernel summit and is getting fairly annoyin
On Tue, Oct 29, 2013 at 10:09:53AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2013-10-28 at 09:59 +0100, Christoph Hellwig wrote:
> > Btw, can we please take away this discussion from ksummit-attendees? It's
> > got
> > absolutely nothing to do with kernel summit and is getting fairly annoyin
Hi,
I'm seeing a test failure with git-1.8.4 on powerpc-darwin8:
[11:00:56] t9903-bash-prompt.sh ...
not ok 13 - prompt - interactive rebase
not ok 14 - prompt - rebase merge
Details here:
http://paste.lisp.org/display/139525
The odd thing is that when I run
On Mon, 2013-10-28 at 09:59 +0100, Christoph Hellwig wrote:
> Btw, can we please take away this discussion from ksummit-attendees? It's got
> absolutely nothing to do with kernel summit and is getting fairly annoying.
Ack. Additionally, iirc, we had decided that
- We don't cross post multiple l
We offer Loan for 3% if you are interested do send details.contact Mr Tony
Bowyer: coastalfinanceloanf...@hotmail.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-
On Fri, Oct 25, 2013 at 02:04:38AM -0400, Jeff King wrote:
> diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
> new file mode 100755
> index 000..0868725
> --- /dev/null
> +++ b/t/t5310-pack-bitmaps.sh
> @@ -0,0 +1,114 @@
> +#!/bin/sh
> +
> +test_description='exercise basic bitmap
Johan Herland writes:
> But I still don't see exactly what this option should do (inside "git
> commit") that would end up being useful across most/all projects, and
> not just something that could more easily be implemented in the
> *commit-msg hooks for relevant projects.
[Ok, admittedly I don
Ben Walton writes:
> It's an escape. Without it, sed throws:
The shell removes it before sed can see it.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe f
Hi Karsten
Junio C Hamano writes:
> * kb/fast-hashmap (2013-10-22) 12 commits
> - remove old hash.[ch] implementation
> - read-cache.c: fix memory leaks caused by removed cache entries
I found more valgrind breakage related to this commit, in t2101.[3567]
(sorry for only reporting them so lat
Ignore this version. The immediate followup quotes PERL_PATH.
On Mon, Oct 28, 2013 at 9:40 PM, Ben Walton wrote:
> Solaris' tr (both /usr/bin/ and /usr/xpg4/bin) uses the System V
> semantics for tr whereby string1's length is truncated to the length
> of string2 if string2 is shorter. The BSD se
On Mon, Oct 28, 2013 at 9:04 PM, Jonathan Nieder wrote:
> Jeff King wrote:
>
>> Speaking of which, is there any reason to use the ugly "$PERL_PATH"
>> everywhere, and not simply do:
>>
>> perl () {
>> "$PERL_PATH" "$@"
>> }
>>
>> in test-lib.sh?
>
> Sounds like a nice potential improvement
Solaris' tr (both /usr/bin/ and /usr/xpg4/bin) uses the System V
semantics for tr whereby string1's length is truncated to the length
of string2 if string2 is shorter. The BSD semantics, as used by GNU tr
see string2 padded to the length of string1 using the final character
in string2. POSIX explic
Solaris' tr (both /usr/bin/ and /usr/xpg4/bin) uses the System V
semantics for tr whereby string1's length is truncated to the length
of string2 if string2 is shorter. The BSD semantics, as used by GNU tr
see string2 padded to the length of string1 using the final character
in string2. POSIX explic
Ben Walton writes:
> Per the other discussion about replacing all PERL_PATH with a shell
> function named perl, should I update this patch to use $PERL_PATH in
> the meantime so that it can be batch updated when the function is
> added in a separate patch?
Yeah, sounds like a good plan, and very
On Mon, Oct 28, 2013 at 9:04 PM, Ben Walton wrote:
> I'm happy to defer to your judgement on this - If you'd like the tests
> wrapped, I'll do so.
>
> Thanks
> -Ben
>
> On Mon, Oct 28, 2013 at 7:08 PM, Junio C Hamano wrote:
>> Jonathan Nieder writes:
>>
>>> Johannes Sixt wrote:
>>>
In other
On Mon, Oct 28, 2013 at 5:39 PM, Andreas Schwab wrote:
> Ben Walton writes:
>
>> diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
>> index 3fb4b97..0126154 100755
>> --- a/t/t4015-diff-whitespace.sh
>> +++ b/t/t4015-diff-whitespace.sh
>> @@ -145,7 +145,8 @@ test_expect_success
I'm happy to defer to your judgement on this - If you'd like the tests
wrapped, I'll do so.
Thanks
-Ben
On Mon, Oct 28, 2013 at 7:08 PM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> Johannes Sixt wrote:
>>
>>> In other tests, we check for prerequisite PERL, i.e., we are prepared
>>> tha
On Mon, Oct 28, 2013 at 8:45 PM, Karsten Blees wrote:
>> The new `hashmap.c` covers the first case quite well (albeit slightly
>> more verbosely than I'd like), but in the second case it doesn't quite
>> work. Since the new hash needs to embed the "struct hashmap_entry" on
>> all its values (to al
Jeff King wrote:
> Speaking of which, is there any reason to use the ugly "$PERL_PATH"
> everywhere, and not simply do:
>
> perl () {
> "$PERL_PATH" "$@"
> }
>
> in test-lib.sh?
Sounds like a nice potential improvement to me. :)
Thanks,
Jonathan
--
To unsubscribe from this list: send the
Torsten Bögershausen writes:
> (This does apply on pu, not on master.
Hmph. At least for me, it applies down to cabb411f (Merge branch
'nd/clone-local-with-colon', 2013-10-14) just fine. Puzzled.
> diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
> index 1d1c875..a126f08 100755
> --- a/t/t560
On Sun, Oct 27, 2013 at 12:34:30AM +0200, Christian Couder wrote:
> Commit 5b0864070 (sha1_object_info_extended: make type calculation
> optional, Jul 12 2013) changed the return value of the
> sha1_object_info_extended function to 0/-1 for success/error.
>
> Previously this function returned the
Commit 8d3d28f5 added test cases for URLs which should be ssh.
Add more tests testing all the combinations:
-IPv4 or IPv6
-path starting with "/" or with "/~"
-with and without the ssh:// scheme
Add tests for ssh:// with port number.
When a git repository "foo:bar" exist, git clone will call
On Mon, Oct 28, 2013 at 12:22:16PM -0700, Jonathan Nieder wrote:
> The git build system supports a NO_PERL switch to avoid installing
> perl bindings or other features (like "git add --patch") that rely on
> perl on runtime, but even with NO_PERL it has not been possible for a
> long time to run t
Am 28.10.2013 20:22, schrieb Jonathan Nieder:
> The git build system supports a NO_PERL switch to avoid installing
> perl bindings or other features (like "git add --patch") that rely on
> perl on runtime, but even with NO_PERL it has not been possible for a
> long time to run tests without perl.
Am 28.10.2013 17:16, schrieb Vicent Martí:
> On Mon, Oct 28, 2013 at 4:48 PM, Junio C Hamano wrote:
>>> jk/pack-bitmap adds khash.h, which from a first glance looks like yet
>>> another hash table implementation. I was just wondering if kb's new
>>> hash tables can cover the need of pack-bitmap.c
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
It is already 10th week of this cycle, but somehow I completely
forgot where in the cycle we were. Sorry about that.
I'll tag 1.8.5-rc0 in a f
The git build system supports a NO_PERL switch to avoid installing
perl bindings or other features (like "git add --patch") that rely on
perl on runtime, but even with NO_PERL it has not been possible for a
long time to run tests without perl. Helpers such as
nul_to_q () {
The latest maintenance release Git v1.8.4.2 is now available 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:
f2e9317703553b4215700605c15d0f3a30623a9d git-1.8.4.2.tar.gz
b0d5e7e24aba1af4a8e1a4fa9c894c3a6
John Keeping writes:
> The --reflog name has the advantage that it makes clear that this is
> looking at something more than the commit graph and I don't think
> --fork-point does imply that.
I think I understand what you are saying, but that "more than the
commit graph" part in your reasoning i
Michael Haggerty writes:
>> True but when fetching other references, tags relevant to the
>> history being fetched by default should automatically follow, so the
>> above explains why "fetch --tags" is not a useful thing to do daily.
>
> Maybe not necessary in many scenarios, but is it harmful fo
Jonathan Nieder writes:
> Johannes Sixt wrote:
>
>> In other tests, we check for prerequisite PERL, i.e., we are prepared
>> that perl is not available. Shouldn't we do that here, too?
>
> I think the tests assume there's a perl present even when the PERL
> prereq isn't present already. E.g.:
>
Johannes Sixt wrote:
> In other tests, we check for prerequisite PERL, i.e., we are prepared
> that perl is not available. Shouldn't we do that here, too?
I think the tests assume there's a perl present even when the PERL
prereq isn't present already. E.g.:
nul_to_q () {
Am 28.10.2013 10:13, schrieb Ben Walton:
> Solaris' tr (both /usr/bin/ and /usr/xpg4/bin) uses the System V
> semantics for tr whereby string1's length is truncated to the length
> of string2 if string2 is shorter. The BSD semantics, as used by GNU tr
> see string2 padded to the length of string1 u
Ben Walton writes:
> diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
> index 3fb4b97..0126154 100755
> --- a/t/t4015-diff-whitespace.sh
> +++ b/t/t4015-diff-whitespace.sh
> @@ -145,7 +145,8 @@ test_expect_success 'another test, with
> --ignore-space-at-eol' 'test_cmp expect
Milton Soares Filho writes:
> On 28 October 2013 13:41, Junio C Hamano wrote:
>> I agree to all of the above, including the ugliness of 'x' ;-)
>>
>> A "blank" may however be hard to spot, if the range is limited,
>> though. For example,
>
> A 'x' looks like termination points in some specifica
On 28 October 2013 13:41, Junio C Hamano wrote:
> I agree to all of the above, including the ugliness of 'x' ;-)
>
> A "blank" may however be hard to spot, if the range is limited,
> though. For example,
A 'x' looks like termination points in some specification languages
such as SDL and MSC and
Junio C Hamano writes:
> Roberto Tyley writes:
>> On 21/09/2013 23:16, Keshav Kini wrote:
>>> [SNIP]
>>> This situation came about because the BFG Repo-Cleaner doesn't write new
>>> reflog entries after creating its new objects and moving refs around.
>>
>> True enough - I don't think the BFG doe
Junio C Hamano writes:
> [administrivia: please avoid culling addresses from To:/Cc: lines]
Yikes, sorry about that. I've been sending messages through Gmane
rather than via email, and I didn't realize the list didn't
automatically send messages to the appropriate people who are only
reading the
Vicent Martí writes:
> On Mon, Oct 28, 2013 at 4:48 PM, Junio C Hamano wrote:
>>> jk/pack-bitmap adds khash.h, which from a first glance looks like yet
>>> another hash table implementation. I was just wondering if kb's new
>>> hash tables can cover the need of pack-bitmap.c too so we can remove
Michael Haggerty writes:
> When investigating the exact semantics of tag-following, I discovered
> that the tag auto-following behavior of "git fetch" is more ambitious
> than I would have expected: it fetches any tag that references an object
> that is known to the local repository, *even if tha
On Mon, Oct 28, 2013 at 4:48 PM, Junio C Hamano wrote:
>> jk/pack-bitmap adds khash.h, which from a first glance looks like yet
>> another hash table implementation. I was just wondering if kb's new
>> hash tables can cover the need of pack-bitmap.c too so we can remove
>> khash.h later..
>
> Good
Duy Nguyen writes:
> On Sat, Oct 26, 2013 at 6:23 AM, Junio C Hamano wrote:
>> * kb/fast-hashmap (2013-10-22) 12 commits
>> - remove old hash.[ch] implementation
>> - read-cache.c: fix memory leaks caused by removed cache entries
>> - name-hash.c: remove cache entries instead of marking them
"Philip Oakley" writes:
> Isn't the origin of the description that it looks like a stick (cane),
> and 'sticked' is a modern verbing of that form? That's what I'd
> assumed anyway.
>
> Googleing "Sticked option" only linked back to Git.
I know web is not the authoritative source of information ;
[administrivia: please avoid culling addresses from To:/Cc: lines]
Keshav Kini writes:
> What about just putting an extra blank line after every root commit line
> (possibly except the last one)? That should make it plenty easy to see
> where the root commits are in --oneline mode. I think it
Jeff King writes:
> On Fri, Oct 25, 2013 at 08:26:29PM -0400, Jeff King wrote:
>
>> On Fri, Oct 25, 2013 at 04:06:19PM -0700, Junio C Hamano wrote:
>>
>> > Jeff King writes:
>> >
>> > > diff --git a/pack-bitmap.c b/pack-bitmap.c
>> > > new file mode 100644
>> > > index 000..73c52fd
>> > >
Michael Haggerty writes:
> On 10/24/2013 11:11 PM, Junio C Hamano wrote:
> ...
>> We should just lose "It is similar to using" from 10/15 and start
>> over, perhaps? Add the first paragraph of the below in 10/15 and
>> add the rest in 11/15, or something.
>>
>> --tags::
>> Req
Martin von Zweigbergk writes:
>> + bases = get_merge_bases_many(derived, revs.nr, revs.commit, 0);
>> + ...
>> + if (revs.nr <= i)
>> + return 1; /* not found */
>> +
>> + printf("%s\n", sha1_to_hex(bases->item->object.sha1));
>> + free_commit_list(bases);
>>
(Resending without HTML, so that it reaches the ML).
On Fri, Oct 11, 2013 at 11:32 AM, Paolo Giarrusso wrote:
>
> On Wed, Oct 9, 2013 at 11:11 PM, Jonathan Nieder wrote:
> > Paolo Giarrusso wrote:
> >
> >> Seeing the email, I wonder whether there's hope something like that
> >> can be preserved
When investigating the exact semantics of tag-following, I discovered
that the tag auto-following behavior of "git fetch" is more ambitious
than I would have expected: it fetches any tag that references an object
that is known to the local repository, *even if that object is not
currently reachable
On Mon, Oct 28, 2013 at 10:02 AM, Michael Haggerty wrote:
> On 10/27/2013 08:14 AM, Josh Triplett wrote:
>> On Sun, Oct 27, 2013 at 06:42:44AM +0100, Michael Haggerty wrote:
>>> On 10/27/2013 02:34 AM, Josh Triplett wrote:
>>> I wonder if the two features could
>>> be combined in some way?
>>>
>>>
Hi there,
I'm trying to use a well-past date for a git commit, before the UNIX Epoch, but
this does not work for the reasons below. I'm on Mac OS X 10.8, git version
1.8.3.4, and `sizeof(time_t) == 8`. The date I'm trying to set is October 4,
1958, that is around timestamp -354808800.
First techn
Hi,
Why a fork? Well, the short answer is; my patches are not being applied.
What is git-fc? It is a friendly fork, and by that I mean that it's a
fork that won't deviate from the mainline, it is more like a branch.
This branch will move forward close to Git's mainline, and it could be
merged at
Solaris' tr (both /usr/bin/ and /usr/xpg4/bin) uses the System V
semantics for tr whereby string1's length is truncated to the length
of string2 if string2 is shorter. The BSD semantics, as used by GNU tr
see string2 padded to the length of string1 using the final character
in string2. POSIX explic
On 10/27/2013 08:14 AM, Josh Triplett wrote:
> On Sun, Oct 27, 2013 at 06:42:44AM +0100, Michael Haggerty wrote:
>> On 10/27/2013 02:34 AM, Josh Triplett wrote:
>> [...]
>> First of all, let me show my ignorance. How formalized is the use of
>> metadata lines at the end of a commit message? I don
Junio C Hamano writes:
> There are unbound number of kinds of trailers people would want to
> add, depending on their projects' needs. We should not have to add
> a specific support for a tailer like this one, before thinking
> through to see if we can add generic support for adding arbitrary
>
On Tue, Jun 18, 2013 at 11:31 PM, Junio C Hamano wrote:
Sorry for the very slow reply. This got lost in my inbox and I forgot about it.
> Ben Walton writes:
>
>> Solaris' tr (both /usr/bin/ and /usr/xpg4/bin) fail to handle the case
>> where the first argument is a multi-character set and the s
Btw, can we please take away this discussion from ksummit-attendees? It's got
absolutely nothing to do with kernel summit and is getting fairly annoying.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo
On 10/28/2013 08:16 AM, Josh Triplett wrote:
> On Sun, Oct 27, 2013 at 06:52:18PM -0700, Junio C Hamano wrote:
>> There are unbound number of kinds of trailers people would want to
>> add, depending on their projects' needs. We should not have to add
>> a specific support for a tailer like this on
On Sun, Oct 27, 2013 at 06:52:18PM -0700, Junio C Hamano wrote:
> There are unbound number of kinds of trailers people would want to
> add, depending on their projects' needs. We should not have to add
> a specific support for a tailer like this one, before thinking
> through to see if we can add
76 matches
Mail list logo
