Hi Brandon McCaig,
On Thu, Mar 13, 2014 at 9:06 PM, Brandon McCaig wrote:
> Jagan:
>
> On Thu, Mar 13, 2014 at 4:56 AM, Jagan Teki wrote:
>> Hi,
>
> Hello,
>
>> I have two branches.
>> - master-b1
>> - master-b2
>>
>> Suppose I'm in master-b1 then did a change
>> on master-b1
>> $ git add test/i
On 03/13/2014 11:07 PM, Jeff King wrote:
> On Thu, Mar 13, 2014 at 03:01:09PM -0700, Shawn Pearce wrote:
>
>>> It would definitely be good to have throughput measurements while
>>> writing out the pack. However, I'm not sure we have anything useful to
>>> count. We know the total number of objects
On Fri, Mar 14, 2014 at 4:43 PM, Michael Haggerty wrote:
> Would it be practical to change it to a percentage of bytes written?
> Then we'd have progress info that is both convenient *and* truthful.
I agreed for a second, then remembered that we don't know the final
pack size until we finish writ
On Wed, Mar 12, 2014 at 3:36 AM, Jeff King wrote:
> If the client is limited to setting a few flags, then something like
> http can get away with:
>
> GET
> foo.git/info/refs?service=git-upload-pack&advertise-symrefs&refspec=refs/heads/*
>
> And it does not need to worry about upload-pack2 at a
On Mon, Mar 10, 2014 at 6:28 PM, demerphq wrote:
> I had the impression, and I would not be surprised if they had the
> impression that the git development community is relatively
> unconcerned about performance issues on larger repositories.
>
> There have been other reports, which are difficult
On 14-03-14 12:37 AM, Andrew Wong wrote:
> During a merge, "--mixed" is most likely not what the user wants. Using
> "--mixed" during a merge would leave the merged changes and new files
> mixed in with the local changes. The user would have to manually clean
> up the work tree, which is non-trivia
2014-03-14 0:57 GMT-04:00 Jeff King :
> This discussion ended up encompassing a lot of other related cleanups. I
> hope we didn't scare you away. :)
I don't think you could; this community is much more accepting than
other software communities around the web. The fact that I received
constructive
On Fri, Mar 14, 2014 at 05:21:59PM +0700, Duy Nguyen wrote:
> On Fri, Mar 14, 2014 at 4:43 PM, Michael Haggerty
> wrote:
> > Would it be practical to change it to a percentage of bytes written?
> > Then we'd have progress info that is both convenient *and* truthful.
>
> I agreed for a second, t
2014-03-13 12:05 GMT-04:00 Michael Haggerty :
> It is very, very unlikely that you inverted the sense of dozens of tests
> throughout the Git code base and the tests ran correctly. I rather
> think that you made a mistake when testing. You should double- and
> triple-check that you really ran the
Apply for GSOC.The microprojects is rewriter diff-index.c
Signed-off-by: ubuntu733
---
diff-no-index.c | 11 ++-
dir.h |3 ++-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 8e10bff..91ece64 100644
--- a/diff-no-inde
On Fri, Mar 14, 2014 at 5:37 AM, Duy Nguyen wrote:
> On Wed, Mar 12, 2014 at 3:36 AM, Jeff King wrote:
>> If the client is limited to setting a few flags, then something like
>> http can get away with:
>>
>> GET
>> foo.git/info/refs?service=git-upload-pack&advertise-symrefs&refspec=refs/heads/
Eric Sunshine writes:
> Thanks for the resubmission. Comments below.
Thanks, Eric, for helping so many micro exercises.
> On Thu, Mar 13, 2014 at 4:20 PM, Yao Zhao wrote:
>> Subject: [PATCH] GSoC Change multiple if-else statements to be table-driven
>
> It's a good idea to let reviewers know t
Quint Guvernator writes:
> I'll be re-reading this thread and working on this patch over the
> weekend to try to identify the more straightforward hunks I could
> submit in a patch.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vg
On Fri, Mar 14, 2014 at 10:33 AM, Marc Branchaud wrote:
> I know this approach was suggested earlier, but given these dangers it seems
> silly to give this big warning on a plain "git reset" but still go ahead and
> do the things the warning talks about.
>
> Is there any issue with changing "git r
Hi,
Welcome to the Git community, and welcome to the GSOC program. Below are
some comments to give you a taste of what a review looks like on this
list. Do take the comments seriously (they should be addressed), but
don't take them badly: critic is meant to be constructive.
ubuntu733 writes:
^^^
Hi,
I have two branch in one repo that I need to maintain for 2 different
deliveries.
Say branch1 and branch2 in test.git repo.
test.git
- branch1
foo_v1/text.txt
foo_v2/text.txt
- branch2
foo/text.txt
branch1 is developers branch all source looks version'ed manner and
branch2 is
Don't know what happen, I'm unable to join #git channel
[23:40] hi
[23:40] == Cannot send to channel: #git
Can any one help!
On Fri, Mar 14, 2014 at 11:09 PM, Jagan Teki wrote:
> Hi,
>
> I have two branch in one repo that I need to maintain for 2 different
> deliveries.
> Say branch1 and branch
Thank you for your comments.I will amend those issues .As a Chinese
student,what name should I use?My Chinese name is ok?
I am very interest in Open source.What can I do to increase my chance?
At 2014-03-15 01:10:57,"Matthieu Moy" wrote:
>Hi,
>
>Welcome to the Git community, and welcome to the GS
Thank you for your comments.I will amend those issues .As a Chinese
student,what name should I use?My Chinese name is ok?
At 2014-03-15 01:10:57,"Matthieu Moy" wrote:
>Hi,
>
>Welcome to the Git community, and welcome to the GSOC program. Below are
>some comments to give you a taste of what a revi
I thought you had the URLs backwards, but that doesn't seem to be the
problem, assuming I am reading your transcription correctly. Maybe the
'insteadOf' is being applied in addition to (and cancelling out) the
pushInsteadOf. Does it work as expected if you remove one or the
other?
In any case, it
沈承恩 writes:
> Thank you for your comments.I will amend those issues .As a Chinese
> student,what name should I use?My Chinese name is ok?
I guess it is. The git.git history already has contribution from 张忠山
for example (I don't know if it is chineese, but it looks so from my
French eyes).
> I a
On Fri, Mar 14, 2014 at 1:39 PM, Jagan Teki wrote:
> Suppose developer send 10 patches on branch1 where are changes in terms
> of _/ then I need to apply on my local repo branch1, till now
> is fine then I need to apply same 10 patches on to my branch2 where source
> tree which is quite question
On Sat, Mar 15, 2014 at 12:48 AM, Andrew Wong wrote:
> On Fri, Mar 14, 2014 at 1:39 PM, Jagan Teki wrote:
>> Suppose developer send 10 patches on branch1 where are changes in terms
>> of _/ then I need to apply on my local repo branch1, till now
>> is fine then I need to apply same 10 patches on
On Fri, Mar 14, 2014 at 4:01 PM, Jagan Teki wrote:
> On Sat, Mar 15, 2014 at 12:48 AM, Andrew Wong wrote:
>> On Fri, Mar 14, 2014 at 1:39 PM, Jagan Teki wrote:
>>> Suppose developer send 10 patches on branch1 where are changes in terms
>>> of _/ then I need to apply on my local repo branch1, til
Andrew Wong writes:
> On Fri, Mar 14, 2014 at 10:33 AM, Marc Branchaud wrote:
>> I know this approach was suggested earlier, but given these dangers it seems
>> silly to give this big warning on a plain "git reset" but still go ahead and
>> do the things the warning talks about.
>>
>> Is there a
In this commit:
https://github.com/git/git/commit/10a49587fabde88c0afbc80a99d97fae91811f5f
git subtree add for a remote repository and branch was fundamentally broken.
It works by chance if a local branch exists that matches the name of
the desired remote branch. Thus, "master" happens to work a
On Sat, Mar 15, 2014 at 2:07 AM, Andrew Wong wrote:
> On Fri, Mar 14, 2014 at 4:01 PM, Jagan Teki wrote:
>> On Sat, Mar 15, 2014 at 12:48 AM, Andrew Wong wrote:
>>> On Fri, Mar 14, 2014 at 1:39 PM, Jagan Teki
>>> wrote:
Suppose developer send 10 patches on branch1 where are changes in ter
Jeff King writes:
> On Sat, Mar 01, 2014 at 12:01:44PM +0100, Matthieu Moy wrote:
>
>> Jeff King writes:
>>
>> > If we had the keys in-memory, we could reverse this: config code asks
>> > for keys it cares about, and we can do an optimized lookup (binary
>> > search, hash, etc).
>>
>> I'm actu
Since 83d842dc8 "make test" using prove fails for some setups in t5541
with:
"Parse errors: No plan found in TAP output"
Running t5541 on its own fails with:
"error: Can't use skip_all after running some tests"
This happens because "start_httpd" (which determines if the test is to
be skip
Signed-off-by: TamerTas
---
Thanks again for the feedback it's been a great learning experience. Comments
Below :)
I have refactored the commit [1] to * suggested changes [2].
format-patch was placing 2 hyphens instead of 3 but it's fixed now.
I've turned the table into a multidimensional one a
On Fri, Mar 14, 2014 at 4:55 PM, Junio C Hamano wrote:
>> For the users that really did mean "--merge", the warning is silly.
>> It's basically saying "We know that you're about to mess up your work
>> tree, but we let you mess up anyway. Learn the correct way so that you
>> don't mess up next tim
On Fri, Mar 14, 2014 at 10:18:32PM +0100, Jens Lehmann wrote:
> Since 83d842dc8 "make test" using prove fails for some setups in t5541
> with:
>
>"Parse errors: No plan found in TAP output"
>
> Running t5541 on its own fails with:
>
>"error: Can't use skip_all after running some tests"
Jeff King writes:
> One option would be to _always_ define test_terminal
That looks like the right direction to go.
> Something like the patch below (looks like we should be using $PERL_PATH
> instead of "perl", too).
;-) Also a SP between test_terminal and (), perhaps.
> diff --git a/t/
On Fri, Mar 14, 2014 at 4:57 PM, Jagan Teki wrote:
> Mr.J> git cherry-pick -X subtree=foo
> cc70089614de16b46c08f32ea61c972fea2132ce
> 14e9c9b20e3bf914f6a38ec720896b3d67f94c90
> error: could not apply cc70089... A
> hint: after resolving the conflicts, mark the corrected paths
> hi
On Fri, Mar 14, 2014 at 02:47:14PM -0700, Junio C Hamano wrote:
> > Something like the patch below (looks like we should be using $PERL_PATH
> > instead of "perl", too).
Actually, we don't need to do this, as of 94221d2 (t: use perl instead
of "$PERL_PATH" where applicable, 2013-10-28). If only t
Jeff King writes:
> On Fri, Mar 14, 2014 at 02:47:14PM -0700, Junio C Hamano wrote:
>
>> > Something like the patch below (looks like we should be using $PERL_PATH
>> > instead of "perl", too).
>
> Actually, we don't need to do this, as of 94221d2 (t: use perl instead
> of "$PERL_PATH" where appl
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
More topics merged to 'master', some of which have been cooking
before the v1.9.0 final release.
You can find the changes described here in the
Am 14.03.2014 22:57, schrieb Jeff King:
> On Fri, Mar 14, 2014 at 02:47:14PM -0700, Junio C Hamano wrote:
>
>>> Something like the patch below (looks like we should be using $PERL_PATH
>>> instead of "perl", too).
>
> Actually, we don't need to do this, as of 94221d2 (t: use perl instead
> of "$P
On Fri, Mar 14, 2014 at 11:45 PM, Shawn Pearce wrote:
> On Fri, Mar 14, 2014 at 5:37 AM, Duy Nguyen wrote:
>> On Wed, Mar 12, 2014 at 3:36 AM, Jeff King wrote:
>>> If the client is limited to setting a few flags, then something like
>>> http can get away with:
>>>
>>> GET
>>> foo.git/info/ref
On Mar 13, Jonathan Nieder wrote:
> May we have your sign-off? (See Documentation/SubmittingPatches
> section "Sign your work" for what this means.
I could have found that myself .. thanks! I'll try to follow it
now. :)
I'll resend the patch. Hopefully I'll do it right.
> Would it make sense to
On Fri, Mar 14, 2014 at 10:29 PM, Jeff King wrote:
>> If an object is reused, we already know its compressed size. If it's
>> not reused and is a loose object, we could use on-disk size. It's a
>> lot harder to estimate an not-reused, deltified object. All we have is
>> the uncompressed size, and
to avoid shell dependent behavior.
When your system shell (/bin/sh) is a dash backslash sequences
in strings are interpreted by the echo command. A commit message
which ends with the string '\n' may result in a garbage line in
the todo list of an interactive rebase which causes the rebase
to fail.
when variables may contain backslash sequences.
Backslash sequences are interpreted as control characters
by the echo command of some shells (e.g. dash).
Signed-off-by: Uwe Storbeck
---
t/test-lib.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-
This commit adds a test to verify the correct behavior when
rebase -i is used to autosquash fixup! commits where the commit
message contains a backslash sequence (\n).
When echo is used instead of printf to handle such a commit
message the test will fail on shells (e.g. dash) where the echo
comman
On Fri, Mar 14, 2014 at 4:30 PM, Duy Nguyen wrote:
> On Fri, Mar 14, 2014 at 11:45 PM, Shawn Pearce wrote:
>>
>> You missed the SSH case. It doesn't have this slot to hide the data into.
>
> Right now we run this for ssh case: "ssh git-upload-pack
> ". New client can do this instead
>
> ssh git
Uwe Storbeck wrote:
> Backslash sequences are interpreted as control characters
> by the echo command of some shells (e.g. dash).
This has bothered me for a while but never enough to do anything about
it. Thanks for fixing it.
> Signed-off-by: Uwe Storbeck
Reviewed-by: Jonathan Nieder
(patc
>From c422507408824403ed18e89ec0bbc32b8764e09c Mon Sep 17 00:00:00 2001
From: Shubham Chaudhary
Date: Sat, 15 Mar 2014 05:56:18 +0530
Subject: [PATCH] [GSoC] Use strchrnul to save additional scan of string
Some strings are scanned twice unnecessarily, once with strchr() and
then with strlen().
I
On Tue, Mar 11, 2014 at 8:49 AM, Jeff King wrote:
> Right, I recall the general feeling being that such a system would work,
> and the transition would be managed by a config variable like
> "remote.*.useUploadPack2". Probably with settings like:
>
> true:
> always try, but allow fall back t
On Fri, Mar 14, 2014 at 03:05:45PM -0700, Junio C Hamano wrote:
> > Actually, we don't need to do this, as of 94221d2 (t: use perl instead
> > of "$PERL_PATH" where applicable, 2013-10-28). If only the author of
> > that commit were here to correct me...
>
> Yuck. I forgot all about that, too.
>
K*i t c h e n Designer London. Thirty Ex D1splay K*i t c h e n s To Clear. W
w w . e x d I s p la y k I t ch e n s 1 . c o .u k £ 595 Each with
appliances.
--
View this message in context:
http://git.661346.n2.nabble.com/Kitchen-Designer-London-tp7605683.html
Sent from the git mailing list
Here are patches to make the pack-objects progress meters behave the
same both with and without pack reuse. The first one is basically the
patch I posted earlier.
The second one drops the "Reusing existing pack", and just rolls those
numbers into "Counting objects". I have mixed feelings on it. _I
When the "--all-progress" option is in effect, pack-objects
shows a progress report for the "writing" phase. If the
repository has bitmaps and we are reusing a packfile, the
user sees no progress update until the whole packfile is
sent. Since this is typically the bulk of what is being
written, it
When we are sending a pack for push or fetch, we may reuse a
chunk of packfile without even parsing it. The progress
meter then looks like this:
Reusing existing pack: 3440489, done.
Counting objects: 3, done.
The first line shows that we are reusing a large chunk of
objects, and then we furt
The pack bitmap format requires that we have a single bit
for each object in the pack, and that each object's bitmap
represents its complete set of reachable objects. Therefore
we have no way to represent the bitmap of an object which
references objects outside the pack.
We notice this problem whi
On Sat, Mar 15, 2014 at 06:19:08AM +0530, Shubham Chaudhary wrote:
> From c422507408824403ed18e89ec0bbc32b8764e09c Mon Sep 17 00:00:00 2001
You can drop this line; it's just part of the mbox format.
> From: Shubham Chaudhary
> Date: Sat, 15 Mar 2014 05:56:18 +0530
> Subject: [PATCH] [GSoC] Use
Before writing the shallow file, we stat() the existing file
to make sure it has not been updated since our operation
began. However, we do not do so under a lock, so there is a
possible race:
1. Process A takes the lock.
2. Process B calls check_shallow_file_for_update and finds
no upda
Forgot to mention, this is one of the microprojects for GSoC this
year. Would be great to have some feedback.
On Fri, Mar 14, 2014 at 6:09 PM, Akshay Aurora wrote:
> I have renamed diff-no-index.c:read_directory() to read_dir() to avoid name
> collision with dir.c:read_directory()
>
> Signed-off
57 matches
Mail list logo
