The objective of GSoC program is to learn how to work on
projects as a part of an open source community, and working
in Git project is not only about writing your own patches.
Constructively critiquing design and implementation of
patches by other people is also an important skill you need
to learn
It now acts like "cd ''" and does not barf and treats
it as a no-op. This is useful if a caller function
does not want to change directory and hence gives no
path value, which would have generally caused git to
output an undesired error message.
Included a simple test to check the same, as suggest
On 03/05/2015 11:08 PM, Junio C Hamano wrote:
Michael Haggerty writes:
I would expect that the following .gitattributes file
* eol=crlf
*.png -text
would leave EOL translation turned off for PNG files. In other words, I
would expect that explicitly setting "-text" would tak
Signed-off-by: Akshay Aurora
---
This is my first patch for a GSoC Microproject, would be great to have your
feedback.
revision.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/revision.c b/revision.c
index bd027bc..d578652 100644
--- a/revision.c
+++ b/revision.c
@@ -224
On 03/05/2015 05:07 PM, Michael Haggerty wrote:
One likely reason for fdopen() to fail is the lack of memory for
allocating a FILE structure. When that happens, try freeing some
memory and calling fdopen() again in the hope that it will work the
second time.
This change was suggested by Jonathan
Not sure, why this mail is not showing on Gmane.
I used git to send the email, and tested it by sending the patch to
myself before sending it to the list.
On Fri, Mar 6, 2015 at 12:40 AM, Akshay Aurora wrote:
> Signed-off-by: Akshay Aurora
> ---
> This is my first patch for a GSoC Microproject,
On 03/04/2015 08:55 PM, Michael J Gruber wrote:
> Yes, that article has a few really weak lines of arguments, such as the
> tutorial count.
Here's his definition of the main draw of a DVCS:
No, the only thing that a DVCS gets you, by definition, is that
everyone gets a copy of the full o
I have a repo whose workdir tends to get pretty dirty as I jump around from
branch to branch tending weeds and whatnot. Sometimes when I try to switch
branches git refuses because of local file changes.
git checkout otherbranch
error: Your local changes to the following files would be over
On Thu, Mar 5, 2015 at 5:46 PM, Prudhvee Narasimha Sadha
wrote:
> Hi,
> here is my patch for the micro project, Please review the code.
>
>
> prudh@prudh-Studio-1569:~/git$ git diff
Please see Documentation/SubmittingPatches and maybe have a look
at the format-patch manpage.
Thanks,
Stefan
Hi,
here is my patch for the micro project, Please review the code.
prudh@prudh-Studio-1569:~/git$ git diff
diff --git a/git.c b/git.c
index 8c7ee9c..364788b 100644
--- a/git.c
+++ b/git.c
@@ -205,6 +205,8 @@ static int handle_options(const char ***argv, int *argc, int
8GB of RAM.
Sorry, typo.
Steve
On Thu, Mar 5, 2015 at 7:25 PM, Duy Nguyen wrote:
> On Fri, Mar 6, 2015 at 4:03 AM, Stephen Morton
> wrote:
>> I'm experiencing very slow git pushes. On the order of 1 minute to push a
>> trivial one-line change. When I set GIT_TRACE=1, I see that it seems to be
On Fri, Mar 6, 2015 at 4:03 AM, Stephen Morton
wrote:
> I'm experiencing very slow git pushes. On the order of 1 minute to push a
> trivial one-line change. When I set GIT_TRACE=1, I see that it seems to be
> taking a lot of time in the pack-objects phase.
>
> Others are not seeing this with the s
Karthik Nayak writes:
> +const char *sha1_object_info_literally(const unsigned char *sha1)
> +{
> + enum object_type type;
> + struct strbuf sb = STRBUF_INIT;
> + struct object_info oi = {NULL};
> +
> + oi.typename = &sb;
> + oi.typep = &type;
> + if (sha1_object_info_exte
Okay, I've had a look at Paul's patch for this. Sorry again for the
dupe, I must've missed it before. I guess I'll attempt another
microproject.
However, I feel like my patch is really all that's neccessary; I don't
think we should try to use both files if they exist -- I consider
Paul's approach
On Thu, 5 Mar 2015 23:38:19 +0100
Christian Couder wrote:
> Hi,
>
> Last year, on the ideas page:
>
> http://git.github.io/SoC-2014-Ideas.html
>
> we also had the following improvement:
>
> "in some cases, git bisect may test too many merge bases, thus slowing
> down the bisection (making it
René Scharfe writes:
> Clear the git_zstream variable at the start of git_deflate_init() etc.
> so that callers don't have to do that.
>
> Signed-off-by: Rene Scharfe
Nice. "git grep -B1 git_deflate_init" tells me that all existing
callers of the function do this memset(). Clearly the above i
Clear the git_zstream variable at the start of git_deflate_init() etc.
so that callers don't have to do that.
Signed-off-by: Rene Scharfe
---
archive-zip.c | 2 --
builtin/index-pack.c | 1 -
builtin/pack-objects.c | 2 --
bulk-checkin.c | 1 -
diff.c | 1 -
fa
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
A few more batches of topics have been merged to 'master', including
both fixes and enhancements. First maintenance release for v2.3 was
cut wit
Hi,
On Thu, Mar 5, 2015 at 9:51 PM, Luis Ressel wrote:
> I'm contributing this patch in preparation for a GSoC15 application with
> the git project. In particular, I'm interested in the two bisect
> improvements listed on the Ideas page. Does anyone have other
> suggestions for potential improvem
Christian Couder writes:
> On Tue, Feb 24, 2015 at 11:09 PM, Jeff King wrote:
>> I wanted to make one more announcement about this, since a few more
>> details have been posted at:
>>
>> http://git-merge.com/
>>
>> since my last announcement. Specifically, I wanted to call attention to
>> the
Luis Ressel writes:
> Oh, and should I add a testcase for the new functionality introduced by
> this patch? And if yes, what exactly should I test?
Absolutely.
Thinking things through to design what needs to be tested is part of
the exercise ;-) You need to demonstrate that the new feature kic
Michael Haggerty writes:
> I would expect that the following .gitattributes file
>
> * eol=crlf
> *.png -text
>
> would leave EOL translation turned off for PNG files. In other words, I
> would expect that explicitly setting "-text" would take precedence over
> the fact that setti
Mårten Kongstad writes:
> v3: change how tests count (part of) the dirstat number of lines: instead of
> 'grep -c', use 'grep >filename && test_line_count'. Thanks to Torsten
> Bögershausen and SZEDER Gábor for pointing out how to improve the tests.
Thanks.
I'd squash the following on top befor
Karthik Nayak writes:
> Add a test to check whether "git -C ''" works without giving an
> error. This is achieved by adding a commit and checking the log
> using "git -C ''" and comparing the log message with the commit
> message.
Why choose something complex like commit and log, though?
Wouldn
I'm contributing this patch in preparation for a GSoC15 application with
the git project. In particular, I'm interested in the two bisect
improvements listed on the Ideas page. Does anyone have other
suggestions for potential improvements of git bisect that would be
suitable for such a GSoC project
credential-store will use ${XDG_CONFIG_HOME}/credentials to store
credentials if this file already exists and no --file option is given.
Otherwise it'll fall back to ~/.git-credentials (status quo).
Signed-off-by: Luis Ressel
---
Documentation/git-credential-store.txt | 4 +++-
credential-store.
(Apologies, after a day I'm cross-posting from git.users. I think the question
is maybe too technical for that group.)
I'm experiencing very slow git pushes. On the order of 1 minute to push a
trivial one-line change. When I set GIT_TRACE=1, I see that it seems to be
taking a lot of time in the pa
Hi,
On Tue, Feb 24, 2015 at 11:09 PM, Jeff King wrote:
> I wanted to make one more announcement about this, since a few more
> details have been posted at:
>
> http://git-merge.com/
>
> since my last announcement. Specifically, I wanted to call attention to
> the contributor's summit on the 8th
On 2015-03-05 17.38, Michael Haggerty wrote:
> I would expect that the following .gitattributes file
>
> * eol=crlf
> *.png -text
>
> would leave EOL translation turned off for PNG files. In other words, I
> would expect that explicitly setting "-text" would take precedence over
>
Junio C Hamano writes:
> Extending this line of thought further.
>
> If I am reading your patch 3/3 right, "status -v -v" shows the
> header when there are patches to be shown for the category. I am
> not sure if that is the most helpful way for the users, when either
> c/i xor i/w diffs is mis
Junio C Hamano writes:
> Michael J Gruber writes:
>
>> - Do we want the header line also for "status -v"? (I would say yes, but that
>> would be a change to current behaviour.)
>
> I would not object to it very strongly, but I do not see a point in
> changing the behaviour.
>
> And I do not se
Michael J Gruber writes:
> v3 has the following changes:
> - new leading patch by Junio to clean up t7508 (slightly modified by myself)
> - adjust tests accordingly
> - revert back to standard c/,i/ resp. i/,w/ diff prefixes with a header line
>
> Open questionis for 3/3:
> - Do we need the heade
Michael Haggerty writes:
> One likely reason for fdopen() to fail is the lack of memory for
> allocating a FILE structure. When that happens, try freeing some
> memory and calling fdopen() again in the hope that it will work the
> second time.
In codepaths where we are likely under memory pressu
Set the text flag for ZIP archive entries that look like text files so
that unzip -a can be used to perform end-of-line conversions. Info-ZIP
zip does the same.
Detect binary files the same way as git diff and git grep do, namely by
checking for the attribute "diff" and its negation "-diff", and
Michael Haggerty writes:
> One likely reason for the failure of fdopen() is a lack of free
> memory.
Interesting.
Did you find this by code inspection?
Or did you actually hit this issue in real life, and applying this
patch helped? The latter would indicate that this failure is rather
common
"Gondek, Andreas" writes:
> after upgrading the Git installation on one of our development servers
> from 1.9.0-rc3 to 2.3.1 we are experiencing strange behavior of merge
> drivers.
Do you see the same with something slightly older, like say v2.2.0?
The only change that I can think of offhand t
Paul Tan writes:
> On Wed, Mar 4, 2015 at 7:01 AM, Junio C Hamano wrote:
>> Paul Tan writes:
>>
>>> struct credential entry = CREDENTIAL_INIT;
>>> + int found_credential = 0;
>>>
>>> fh = fopen(fn, "r");
>>> if (!fh) {
>>> if (errno != ENOENT)
>>>
made changes to "cat-file" to include a "--literally"
option which prints the type of the object without any
complaints.
Signed-off-by: Karthik Nayak
---
builtin/cat-file.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/builtin/cat-file.c b/builtin
Add "sha1_object_info_literally()" which is to be used when
the "literally" option is given to get the type of object
and return it. It internally uses "sha1_object_info_extended()".
Add "unpack_sha1_header_literally()" to unpack sha headers
which may be greater than 32 bytes, which is the thresho
Third version of the patch submitted to add "-literlly" option
to "cat-file"
http://article.gmane.org/gmane.comp.version-control.git/264383
Thanks to Eric, Junio and David for suggesting changes on my
first version.
Thanks to Junio for suggestions on my second version.
Changes from previous ver
Add a "struct strbuf *typename" to object_info to hold the
typename when the literally option is used. Add a flag to
notify functions when literally is used.
Signed-off-by: Karthik Nayak
---
cache.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cache.h b/cache.h
index 4d02efc..949ef4c 10
On Thu, Mar 5, 2015 at 8:07 AM, Michael Haggerty wrote:
> One likely reason for the failure of fdopen() is a lack of free
> memory.
>
> Also expose a new function, fdopen_with_retry(), which retries on
> ENOMEM but doesn't die() on errors. In a moment this function will be
> used elsewhere.
>
> Su
I would expect that the following .gitattributes file
* eol=crlf
*.png -text
would leave EOL translation turned off for PNG files. In other words, I
would expect that explicitly setting "-text" would take precedence over
the fact that setting "eol" implies that a file should be co
Signed-off-by: Michael Haggerty
---
daemon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/daemon.c b/daemon.c
index c3edd96..1d76ccf 100644
--- a/daemon.c
+++ b/daemon.c
@@ -421,8 +421,8 @@ static void copy_to_log(int fd)
struct strbuf line = STRBUF_INIT;
One likely reason for the failure of fdopen() is a lack of free
memory.
Also expose a new function, fdopen_with_retry(), which retries on
ENOMEM but doesn't die() on errors. In a moment this function will be
used elsewhere.
Suggested-by: Jonathan Nieder
Signed-off-by: Michael Haggerty
---
git-
Suggested-by: Jonathan Nieder
Signed-off-by: Michael Haggerty
---
Jonathan's original suggestion was that this function should call
xfdopen(). But a couple of callers of fdopen_lock_file() try to
recover if it fails, so I decided to do it this way instead.
lockfile.c | 2 +-
1 file changed, 1 i
One likely reason for fdopen() to fail is the lack of memory for
allocating a FILE structure. When that happens, try freeing some
memory and calling fdopen() again in the hope that it will work the
second time.
This change was suggested by Jonathan Nieder [1]
In the first patch it is unsatisfying
Signed-off-by: Michael Haggerty
---
vcs-svn/line_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vcs-svn/line_buffer.c b/vcs-svn/line_buffer.c
index 57cc1ce..10791cf 100644
--- a/vcs-svn/line_buffer.c
+++ b/vcs-svn/line_buffer.c
@@ -19,7 +19,7 @@ int buffer_init(struc
Signed-off-by: Michael Haggerty
---
server-info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/server-info.c b/server-info.c
index 34b0253..8c6f662 100644
--- a/server-info.c
+++ b/server-info.c
@@ -20,7 +20,7 @@ static int update_info_file(char *path, int (*generate)(FILE
On Wed, Mar 4, 2015 at 5:03 PM, Stefan Beller wrote:
>
> If anyone wants to experiment with the data I gathered, I can make them
> available.
>
All data of `ls-remote` including the gathering script is found at
(112 kB .tar.xz)
https://drive.google.com/file/d/0B7E93UKgFAfjcHRvM1N2YjBfTzA/view?us
Am 05.03.2015 um 03:16 schrieb Junio C Hamano:
René Scharfe writes:
No sign-off, yet, because I'm not sure we really need another option.
E.g. --text=all doesn't seem to be actually useful, but it was easy to
implement. Info-ZIP's zip always creates archives like --text=auto
does, so perhaps
Am 04.03.2015 um 22:13 schrieb René Scharfe:
diff --git a/archive-zip.c b/archive-zip.c
index 4bde019..3767940 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -5,6 +5,7 @@
#include "archive.h"
#include "streaming.h"
#include "utf8.h"
+#include "xdiff-interface.h"
static int zip_date;
Hi,
seems to be a bug: If adding a submodule from an https URL with a certificate
issued by StartSSL (or even a private/self-signed one?) leads to the following
error:
$ git -c http.sslverify=false submodule add https://example.com/git/xxx.git
Cloning into 'xxx'...
fatal: unable to access
git commit and git status in long format show the diff between HEAD
and the index when given -v. This allows previewing a commit to be made.
They also list tracked files with unstaged changes, but without a diff.
Introduce '-v -v' which shows the diff between the index and the
worktree in additio
"status -v" had no test. Include one.
This also requires changing the .gitignore subtests, which is a good thing:
they include testing a .gitignore pattern now.
Signed-off-by: Michael J Gruber
---
t/t7508-status.sh | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --gi
v3 has the following changes:
- new leading patch by Junio to clean up t7508 (slightly modified by myself)
- adjust tests accordingly
- revert back to standard c/,i/ resp. i/,w/ diff prefixes with a header line
Open questionis for 3/3:
- Do we need the header to stick out even more? (I don't think
From: Junio C Hamano
These files are used to observe the behaviour of the 'status'
command and if there weren't any such observer, the expected
output from 'status' wouldn't even mention them.
Place them in .gitignore to unclutter the output expected by the
tests. An added benefit is that futur
oops, I forgot to say that this happen with git 2.3.1.
On 03/05/2015 02:55 PM, Francis Moreau wrote:
> Hi,
>
> I have a suspect case which happens when rebasing a branch.
>
> I'm using the post-rewrite hook and during certain circumstance, my hook
> is called by git-rebase with wrong parameters:
Hi,
I have a suspect case which happens when rebasing a branch.
I'm using the post-rewrite hook and during certain circumstance, my hook
is called by git-rebase with wrong parameters: argument is
not related to one.
This actually happens when git-rebase stops and reports:
The previous cherr
Hello,
after upgrading the Git installation on one of our development servers from
1.9.0-rc3 to 2.3.1 we are experiencing strange behavior of merge drivers.
A merge driver registered as "* merge=" in the
.gitattributes is now executed even if there isn't any merge conflict. This
only happens f
On 03/03/2015 12:44 AM, Junio C Hamano wrote:
> [...]
> I was about to suggest another alternative.
>
> Pretend as if Git internally used SHA-512 (or whatever hash you
> want to use) instead of SHA-1, compute the object names that
> way. Recompute the contents of a tree object is by r
Add a test to check whether "git -C ''" works
without giving an error. This is achieved by
adding a commit and checking the log using
"git -C ''" and comparing the log message with
the commit message.
Signed-off-by: Karthik Nayak
---
t/t0056-git-C.sh | 10 ++
1 file changed, 10 insertion
On 03/05/2015 04:27 PM, Karthik Nayak wrote:
Add a test to check whether "git -C ''" works
without giving an error. This is achieved by
adding a commit and checking the log using
"git -C ''" and comparing the log message with
the commit message.
Signed-off-by: Karthik Nayak
---
t/t0056-git-C
Add a test to check whether "git -C ''" works
without giving an error. This is achieved by
adding a commit and checking the log using
"git -C ''" and comparing the log message with
the commit message.
Signed-off-by: Karthik Nayak
---
t/t0056-git-C.sh | 10 ++
1 file changed, 10 insertion
It now acts like "cd ''" and does not barf and treats
it as a no-op, this is usefull if a caller function
does not want to change directory and hence gives no
path value, which would have generally caused git to
output an undesired error message.
Signed-off-by: Karthik Nayak
---
git.c | 12 +
This is a prep step for further refactoring. Besides reindentation and
s/shallows\./shallows->/g, no other changes are expected.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
upload-pack.c | 99 +++
1 file changed, 52 insertions(+), 47 deletions(
Signed-off-by: Nguyễn Thái Ngọc Duy
---
upload-pack.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/upload-pack.c b/upload-pack.c
index 69a3828..e616e19 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -592,6 +592,18 @@ static void deepen(int depth, const struct object_
Signed-off-by: Nguyễn Thái Ngọc Duy
---
upload-pack.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 74f48f9..ea030f3 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -531,6 +531,20 @@ error:
}
}
+sta
Signed-off-by: Nguyễn Thái Ngọc Duy
---
upload-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index ea030f3..79f5525 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -547,7 +547,7 @@ static void send_shallow(struct commit_list *resu
Signed-off-by: Nguyễn Thái Ngọc Duy
---
upload-pack.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 79f5525..69a3828 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -545,21 +545,10 @@ static void send_
Instead of a custom commit walker like get_shallow_commits(), this new
function uses rev-list to mark SHALLOW to all reachable commits. The
definition of reachable is to be defined by the protocol later. This
makes it more flexible to define shallow boundary.
Note: if a commit has one not_shallow
On Thu, Mar 5, 2015 at 5:05 AM, Philip Oakley wrote:
> Given the mention of the GSoC ideas list, I thought it worth writing out one
> of my little ideas..
>
>
> A possible idea is to add a date based variant of shallow clone :
>
> 'git clone --date ...'
>
> in the same vein as the existing depth
On 04/03/15 23:01, Junio C Hamano wrote:
> Anton Trunov writes:
>
>> For the code version before applying this patch the following scenario
>> will take place if "git merge -Xignore-all-space remote" gets executed.
>>
>> base file:
>> 1st line
>> 2nd line
>>
>> master file:
>> 1st line
>> 2nd
73 matches
Mail list logo
