On Thu, Mar 20, 2014 at 11:35:03AM +0200, George Papanikolaou wrote:
> Hi again guys,
> I forgot to add the signed-of line to the tiny patch I sent earlier for GSOC.
> Any ideas about the changes?
> Thanks...
You don't give any detail on the inefficiencies, or what specific
benchmark is made fast
Thanks for the submission. Comments below to give you a taste of the
Git review process...
On Thu, Mar 20, 2014 at 6:04 AM, MustafaOrkunAcar
wrote:
> Subject: Rewritten fetch-pack.c:filter_refs() using starts_with() instead of
> memcmp()
Use imperative mood: "Rewrite" rather than "Rewritten". M
On Thu, Mar 20, 2014 at 02:15:29PM -0400, Brian Bourn wrote:
> Going through the annals of the listserve thus far I've found a few
> discussions which provide some insight towards this process as well as
> some experimental patches that never seem to have made it
> through[1][2][3][4]
Reading the
On Thu, Mar 20, 2014 at 10:21 PM, Duy Nguyen wrote:
> On Fri, Mar 21, 2014 at 08:51:18AM +0700, Duy Nguyen wrote:
>> On Thu, Mar 20, 2014 at 11:08 PM, Stefan Zager wrote:
>> > Duy, would you like to re-post your patch without the new pread
>> > implementation?
>>
>> I will but let me try out the
On Thu, Mar 20, 2014 at 10:56:58PM -, Philip Oakley wrote:
> >This is by design. Git-log does not calculate or show merge diffs
> >unless
> >"-c" or "--cc" is specified, and thus no diff-filter can match.
>
> This is hard to discern from the log(1) man page as this conflates
> commit inclusio
On Fri, Mar 21, 2014 at 08:51:18AM +0700, Duy Nguyen wrote:
> On Thu, Mar 20, 2014 at 11:08 PM, Stefan Zager wrote:
> > Duy, would you like to re-post your patch without the new pread
> > implementation?
>
> I will but let me try out the sliding window idea first. My quick
> tests on git.git sho
On Thu, Mar 20, 2014 at 05:25:22PM +, Tanay Abhra wrote:
> I have gone through commit.c, builtin/commit.c and api-config.txt but one
> thing I cannot find is which functions handle writing config file to disk
> after adding a new variable,value pair(for example git config my.option
> true) . I
Thanks for the submission. Comments below to give you a feel for the
Git review process...
On Thu, Mar 20, 2014 at 1:48 AM, blacksimit wrote:
> Subject: Rewritten fsck.c:fsck_commit() through using starts_with() instead
> of memcmp()
Use imperative mood ("rewrite" instead of "rewritten"). Keep
On Fri, Mar 21, 2014 at 2:43 PM, Jeff King wrote:
> Thanks, the new text looks good to me. Please follow SubmittingPatches
> (notably, you need to sign-off your work, and please send patches inline
> rather than as attachments).
Ah, didn't see that file.
>From 6e1fc126ece37c6201d0c16b76c6c87781f
On Thu, Mar 20, 2014 at 7:56 AM, Aleksey Mokhovikov wrote:
> On 03/19/2014 04:21 PM, Eric Sunshine wrote:
>> Thanks for the resubmission. Comments below...
>>
>> On Tue, Mar 18, 2014 at 10:33 AM, Aleksey Mokhovikov
>> wrote:
>>> Subject: [PATCH][GSOC] Selection of the verbose message is replaced
On Fri, Mar 21, 2014 at 10:46:15AM +1100, Chris Angelico wrote:
> oohh. Heh. I thought the "porcelain" sections of git were the
> lower-level or machine-readable versions of other tools, and didn't
> really think of mine as fitting into that.
The term sometimes gets used confusingly. The
Hello again,
Please it would be very helpful for me to get some comments on this
proposal I would be very grateful towards anyone who could take some
time to look at it, even if it's just the wording.
Regards,
Brian Bourn
On Thu, Mar 20, 2014 at 2:15 PM, Brian Bourn wrote:
> Hi all,
>
> This is
On 3/20/2014 1:18 PM, Eric Sunshine wrote:
On Thu, Mar 20, 2014 at 4:44 AM, Ilya Bobyr wrote:
Built-in commands can specify names for option arguments when usage text
is generated for a command. sh based commands should be able to do the
same.
Option argument name hint is any text that comes
Thanks for the submission. Comments below to give you a feel for the
Git review process...
On Thu, Mar 20, 2014 at 9:54 PM, Ashwin Jha wrote:
> Subject: [PATCH] GSoC Miniproject 15. Rewrite fsck.c:fsck_commit()
The subject becomes part of the permanent Git history, but the fact
that this is a GS
On Thu, Mar 20, 2014 at 3:39 PM, George Papanikolaou
wrote:
> Removing the bloat of checking for both '\r' and '\n' with the prettier
> iswspace() function which checks for other characters as well. (read: \f \t
> \v)
Use imperative mood. "Remove" rather than "Removing".
Bloat? Prettier? Subjec
modified fsck.c:fsck_commit(). Replaced memcmp() with starts_with() function.
starts_with() seems much more relevant than memcmp(). It uses one less argument
and its return value makes more sense.
skip_prefix() is not used as it uses strcmp() internally which seems
unnecessarily
for current task.
On Thu, Mar 20, 2014 at 11:08 PM, Stefan Zager wrote:
> Duy, would you like to re-post your patch without the new pread
> implementation?
I will but let me try out the sliding window idea first. My quick
tests on git.git show me we may only need 21k mmap instead of 177k
pread. That hints some po
On Fri, Mar 21, 2014 at 4:56 AM, Stefan Zager wrote:
>> Considering all that, Duy's solution of opening separate file descriptors
>> per thread seems to be the best pattern for future multi-threaded work.
>
> Does that mean you would endorse the (N threads) * (M pack files)
> approach to threadin
On Fri, Mar 21, 2014 at 2:15 AM, Junio C Hamano wrote:
>> * Get rid of saved_linear, use another flag in struct object instead
>
> I cannot offhand say if I like this change or not. A flag bit is a
> scarce and limited resource; commit slabs felt more suited for
> implementation of corner case e
On Wed, Mar 19, 2014 at 03:39:42PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Fri, Mar 07, 2014 at 08:08:37AM +0100, Christian Couder wrote:
> >
> >> > Be it graft or replace, I do not think we want to invite people to
> >> > use these mechansims too lightly to locally rewrite the
On Thu, Mar 20, 2014 at 8:40 PM, Eric Sunshine wrote:
> On Wed, Mar 19, 2014 at 7:12 PM, Dragos Foianu
> wrote:
>> Eric Sunshine sunshineco.com> writes:
>>> On Tue, Mar 18, 2014 at 6:31 PM, Eric Sunshine
>> sunshineco.com> wrote:
>>>
>>> One other observation: You have a one-off error in your
On Wed, Mar 19, 2014 at 7:12 PM, Dragos Foianu wrote:
> Eric Sunshine sunshineco.com> writes:
>> On Tue, Mar 18, 2014 at 6:31 PM, Eric Sunshine
> sunshineco.com> wrote:
>>
>> One other observation: You have a one-off error in your out-of-bounds
>> check. It should be 'index >= sizeof...'
>
> Wel
On Wed, Mar 19, 2014 at 9:44 AM, Othman Darraz wrote:
> Subject: fsck.c:fsck_commit() use skip_prefix() and starts_with()
Add a space after the colon. Add a colon after fsck_commit().
> make buffer const char* because the content of the memory referenced by this
> variable doesn't change in thi
On Thu, Mar 20, 2014 at 3:52 PM, Andrei Dinu wrote:
> Avoid the conflict between read_directory() from diff-no-index.c and
> read_directory() from "dir.h"
This message is lacking a bit of information. Since diff-no-index.c
does not presently include dir.h, the reader is left to wonder why you
nee
On Wed, Mar 19, 2014 at 01:38:32PM +0100, David Kastrup wrote:
> The default of 16MiB causes serious thrashing for large delta chains
> combined with large files.
Does it make much sense to bump this without also bumping
MAX_DELTA_CACHE in sha1_file.c? In my measurements of linux.git, bumping
the
On Fri, Mar 21, 2014 at 10:38 AM, Jeff King wrote:
>> A comment there to the effect that "Third party tools may also define
>> their own variables" or something would make it clear that this is the
>> intention.
>
> I think this sentence from the section you linked is meant to express
> that:
>
>
On Fri, Mar 21, 2014 at 03:51:16AM +1100, Chris Angelico wrote:
> > 1. I would say yes. git config is made to be extended and doesn't
> > require a config item to be known.
> > 2. Namespacing the config items like you did is a good thing to do so
> > it won't interfere with other options.
>
> Exc
On Wed, Mar 19, 2014 at 10:34:29PM +, Dragos Foianu wrote:
> The name_rev function recursively calls itself which is why the backtrace is
> so big. Unfortunately, for repos with long histories it can lead to Stack
> Overflows. This is pretty much what happened in your case.
>
> I tested it on
Junio and Eric,
Thank you for the reviews and helpful advice.
I should have read more past commit messages before send patch.
Regards,
2014-03-21 3:20 GMT+09:00 Junio C Hamano :
> Hiroyuki Sano writes:
>
>> fsck_tree() has two different ways to set a flag,
>> which are the followings:
>>
>>
Many tests do something like:
(
mkdir foo &&
cd foo &&
git init
)
You can do the same these days with "git init foo", which
makes the tests shorter and simpler to read.
Signed-off-by: Jeff King
---
Unlike the last patch, this one _could_ have an affect. I made the
as
Many tests use subshells, but don't actually change the
shell environment. They were probably cargo-culted from
earlier tests which did need subshells. Drop the useless
ones.
Signed-off-by: Jeff King
---
These ones should produce no behavior change at all; they're purely
mechanical "(foo && bar)"
We've hand-rolled several "if" statements looking for
failures. We can use test_must_fail here, which is shorter
and more robust.
Note that we modify the commands slightly (to use "git init
foo" rather than "cd foo && git init") to avoid dealing with
a subshell, but this should not affect the outc
On 3/20/2014 11:38 AM, Junio C Hamano wrote:
Ilya Bobyr writes:
Built-in commands can specify names for option arguments when usage text
is generated for a command. sh based commands should be able to do the
same.
Option argument name hint is any text that comes after [*=?!] after the
argume
We hand-set several config options using :
git config -f $HOME/.gitconfig ...
Instead, we can use "test_config_global". Not only is this
more readable, but it cleans up for us so that subsequent
tests aren't polluted by our settings.
Signed-off-by: Jeff King
---
t/t0001-init.sh | 11
t0001 predates the test_path_is_* helpers, and uses "test
-f" and "test -d" directly. Using the helpers provides
better debugging output, and are a little more robust.
As opposed to "! test -d", test_path_is_missing will
actually makes sure the path does not exist at all.
Signed-off-by: Jeff King
In the final test of t0001, we have a repo whose .git is a
symlink to a directory "here", and we use
"--separate-git-dir" to migrate that to a .git file pointing
to a different directory. We check that the data is migrated
to the new directory and that .git looks like a git-file.
We also check tha
Doing:
GIT_CONFIG=foo git config ...
is equivalent to:
git config --file=foo ...
The latter is easier to read and slightly less error-prone,
because of issues with one-shot variables and shell
functions (e.g., you cannot use the former with
test_must_fail).
Note that we explicitly leave on
This lets us get rid of an extra "env" invocation in the
middle, and is slightly more readable.
Signed-off-by: Jeff King
---
The case that started this all...
This is also the only reason this series needs to go on top of David's
patch.
t/t1300-repo-config.sh | 8
1 file changed, 4 in
Some tests want to check or set config in another
repository. E.g., t1000 creates repositories and makes sure
that their core.bare and core.worktree settings are what we
expect. We can do this with:
GIT_CONFIG=$repo/.git/config git config ...
but it better shows the intent to just enter the rep
Several test scripts manually unset GIT_CONFIG and other
GIT_* variables. These are generally taken care of for us by
test-lib.sh already.
Unsetting these is not only useless, but can be confusing to
a reader, who may wonder why some tests in a script unset
them and others do not (t0001 is particu
This is already handled by the mass GIT_* unsetting added by
95a1d12 (tests: scrub environment of GIT_* variables,
2011-03-15).
Signed-off-by: Jeff King
---
t/test-lib.sh | 1 -
1 file changed, 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 1531c24..625f06e 100644
--- a/t/test-l
Thanks for the quick reply.
When I send a new patch, should I fold these changes into the original
commit, or should I send them as a separate commit?
>> diff --git a/builtin/apply.c b/builtin/apply.c
>> index b0d0986..6013e19 100644
>> --- a/builtin/apply.c
>> +++ b/builtin/apply.c
>> @@ -4061,7
Once upon a time, the setting of GIT_CONFIG in the
environment could affect how tests ran. Commit 9c3796f (Fix
setting config variables with an alternative GIT_CONFIG,
2006-06-20) unconditionally set GIT_CONFIG in the Makefile
when running tests to give us a known starting point.
This is insuffici
On Wed, Mar 19, 2014 at 10:28:46AM -0700, Junio C Hamano wrote:
> [git config --file versus GIT_CONFIG=]
>
> Thanks. Then I think it makes sense to do such a conversion but it
> probably should be done on top of this patch (we could do it before
> this patch), not as a part of this patch.
Here's
From: "Jeff King"
On Thu, Feb 20, 2014 at 08:35:33AM +0100, Ephrim Khong wrote:
Hi, git log seems to omit merge commits that delete a file
if --follow or
--diff-filter=D is given. Below is a testcase. I'm not sure if it is
desired
behaviour for --diff-filter=D, but it's probably not correct
th
Signed-off-by: Justin Lebar
---
builtin/clean.c | 6 +++---
builtin/commit.c | 2 +-
git-add--interactive.perl | 4 ++--
perl/Git/SVN.pm | 4 ++--
sha1_file.c | 2 +-
t/t1001-read-tree-m-2way.sh | 2 +-
t/t40
I got annoyed by git's awkward use of "nor" in man pages and in git add -p, so
I went ahead and audited all uses of "nor" in the tree. One might be able to
argue that some of the uses I've changed are technically acceptable, but that's
a pretty low bar to set for ourselves. I aimed to make everyt
On Thu, Mar 20, 2014 at 6:16 PM, Justin Lebar wrote:
> Signed-off-by: Justin Lebar
> ---
> Makefile| 2 +-
> builtin/apply.c | 2 +-
> builtin/checkout.c | 2 +-
> builtin/log.c
Torsten Bögershausen writes:
> On 03/20/2014 10:09 PM, Junio C Hamano wrote:
>> * ap/remote-hg-skip-null-bookmarks (2014-03-19) 1 commit
>> - remote-hg: do not fail on invalid bookmarks
>>
>> Will merge to 'next'.
> Hmm, am I the only one who has 11 failures in test-hg-hg-git.sh,
Still? I t
David Kastrup writes:
> Junio C Hamano writes:
>
>> Duy Nguyen writes:
>>
>>> The only
>>> downside I see is large blobs will be packed undeltified, which could
>>> increase pack size if you have lots of them.
>>
>> I think that is something that can be tweaked, unless the user tells
>> us oth
Junio C Hamano writes:
> Quite a few topics are still outside 'pu' and I suspect some of the
> larger ones deserve deeper reviews to help moving them to 'next'.
> In principle, I'd prefer to keep any large topic that touch core
> part of the system cooking in 'next' for at least a full cycle, and
Signed-off-by: Justin Lebar
---
contrib/examples/git-commit.sh | 2 +-
contrib/svn-fe/svn-fe.txt | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/examples/git-commit.sh b/contrib/examples/git-commit.sh
index 23ffb02..4aab1a6 100755
--- a/contrib/examples/git-c
Signed-off-by: Justin Lebar
---
Makefile| 2 +-
builtin/apply.c | 2 +-
builtin/checkout.c | 2 +-
builtin/log.c | 2 +-
builtin/pack-objects.c | 2 +-
built
Signed-off-by: Justin Lebar
---
Documentation/CodingGuidelines | 4 ++--
Documentation/config.txt| 6 +++---
Documentation/diff-generate-patch.txt | 2 +-
Documentation/diff-options.txt | 2 +-
Documentation/e
On 03/20/2014 10:09 PM, Junio C Hamano wrote:
* ap/remote-hg-skip-null-bookmarks (2014-03-19) 1 commit
- remote-hg: do not fail on invalid bookmarks
Will merge to 'next'.
Hmm, am I the only one who has 11 failures in test-hg-hg-git.sh,
like this:
(Tested under Debian 7, commit 04570b241ddb5
On Thu, Mar 20, 2014 at 2:35 PM, Karsten Blees wrote:
> Am 20.03.2014 17:08, schrieb Stefan Zager:
>
>> Going forward, there is still a lot of performance that gets left on
>> the table when you rule out threaded file access. There are not so
>> many calls to read, mmap, and pread in the code; it
Am 20.03.2014 17:08, schrieb Stefan Zager:
> On Thu, Mar 20, 2014 at 6:54 AM, Karsten Blees
> wrote:
>> Am 19.03.2014 01:46, schrieb sza...@chromium.org:
>>> This adds a Windows implementation of pread. Note that it is NOT
>>> safe to intersperse calls to read() and pread() on a file
>>> descrip
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> The only
>> downside I see is large blobs will be packed undeltified, which could
>> increase pack size if you have lots of them.
>
> I think that is something that can be tweaked, unless the user tells
> us otherwise via command line override, w
On Thursday, March 20, 2014 01:45:21 PM Junio C Hamano wrote:
> There hasn't been any argument for this patch, either.
>
> It is not like we are still in year 2007; timing result in a small
> project like Git itself is not a good enough argument to change a
> well established default at this late
I think I misunderstand the project as Moy said. I thought the purpose of
project is to store configuration into memory between multiple git calls. Sorry.
Moy, thanks for explaining. You said API should be hided. Is that means I
should indicate an arbitary feature in old version or new feature w
Дилян Палаузов writes:
> diff --git a/Makefile b/Makefile
> index dddaf4f..dce4694 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -59,9 +59,9 @@ all::
> # FreeBSD can use either, but MinGW and some others need to use
> # libcharset.h's locale_charset() instead.
> #
> -# Define CHARSET_LIB to y
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, many of them fallouts from GSoC
microprojects.
Michael Andreen writes:
> There hasn't been any arguments against this patch. Just updated the message
> with a note about --no-minimal.
There hasn't been any argument for this patch, either.
It is not like we are still in year 2007; timing result in a small
project like Git itself is not a go
Currently git blame has a big problem finding copies and moves when you
split up a big file into smaller ones. One example in the git repository
is 2cf565c, which split the documentation into smaller files.
In 582aa00 XDF_NEED_MINIMAL was removed as the default for performance
reasons, mainly for
On Thu, Mar 20, 2014 at 4:44 AM, Ilya Bobyr wrote:
> Built-in commands can specify names for option arguments when usage text
> is generated for a command. sh based commands should be able to do the
> same.
>
> Option argument name hint is any text that comes after [*=?!] after the
> argument nam
On Thu, Feb 20, 2014 at 08:35:33AM +0100, Ephrim Khong wrote:
> Hi, git log seems to omit merge commits that delete a file if --follow or
> --diff-filter=D is given. Below is a testcase. I'm not sure if it is desired
> behaviour for --diff-filter=D, but it's probably not correct that --follow
> _r
Avoid the conflict between read_directory() from diff-no-index.c and
read_directory() from "dir.h"
Signed-off-by: Andrei Dinu
---
I plan on applying to GSOC 2014
Submit again on the list for an older bug that I solved, to show you that
I received your feedback and I reviewed my code, num
Sorry it looks like I missed some basic documentation:
http://git-scm.com/docs/git-rebase
This issue (combining preserve merges with interactive option) is
described in the BUGS section.
Is there a way I can go about this without losing my merge commits?
On Thu, Mar 20, 2014 at 2:37 PM, Robert D
Removing the bloat of checking for both '\r' and '\n' with the prettier
iswspace() function which checks for other characters as well. (read: \f \t \v)
---
This is one more try to clean up this fuzzy_matchlines() function as part of a
microproject for GSOC. The rest more clarrified microprojects w
I have a local-only branch with just under 70 commits. I also have
merge commits on this branch.
The log of the top few commits on my branch looks like so:
* de651ff (20 minutes ago) (HEAD, survey) Robert Dailey - WIP:
GOTO implementation
* 2a68a23 (21 minutes ago) Robert Dailey - Mov
David Tran writes:
> Ordinarily, we would say "VAR=VAL command" to execute a tested command with
> environment variable(s) set only for that command. This however does not work
> if 'command' is a shell function (most notably 'test_must_fail'); the result
> of the assignment is retained and affec
Nguyễn Thái Ngọc Duy gmail.com> writes:
> This could could help highlight files in ls-files or status output, or
> even diff --name-only (but that's questionable).
>
> This code is from coreutils.git commit
> 7326d1f1a67edf21947ae98194f98c38b6e9e527 file src/ls.c. This is the
> last GPL-2 commit
Nguyễn Thái Ngọc Duy writes:
> Option explanation is in rev-list-options.txt. The interaction with -z
> is left undecided.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
Thanks.
> * Revert back to the old option name --show-linear-break
> * Get rid of saved_linear, use another flag in struct
Ordinarily, we would say "VAR=VAL command" to execute a tested command with
environment variable(s) set only for that command. This however does not work
if 'command' is a shell function (most notably 'test_must_fail'); the result
of the assignment is retained and affects later commands.
To avoid
Junio C Hamano writes:
> In other words, "it is brief and to the point" merely _allows_ these
> statements to be expressed in the latter form; it does not say
> anything about which is better between the former and the latter.
In any case, that is a minor point. I'll queue the patch on 'pu',
wi
Ilya Bobyr writes:
> Built-in commands can specify names for option arguments when usage text
> is generated for a command. sh based commands should be able to do the
> same.
>
> Option argument name hint is any text that comes after [*=?!] after the
> argument name up to the first whitespace.
Hi all,
This is a first draft of my Proposal for GSoC, I'd love feedback about
what I might be missing and any other files I should read regarding
this, so far I have read most of tag.c, branch.c,
builtin/for-each-ref.c, parse-options.c. once again I hope I can get
the same amount of helpful feedb
Hiroyuki Sano writes:
> fsck_tree() has two different ways to set a flag,
> which are the followings:
>
> 1. Using a if-statement that guards assignment.
>
> 2. Using a bitwise-or assignment operator.
>
> Currently, many with the former way,
> and one with the latter way.
>
> In this patch, u
Astril Hayato writes:
> User config file location now complies with the XDG base directory
> specification
>
> Signed-off-by: Astril Hayato
> ---
> Documentation/gitk.txt | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/gitk.txt b/Documentation/
Matthieu Moy writes:
> "git status --branch --porcelain" displays the status of the branch
> (ahead, behind, gone), and used gettext to translate the string.
>
> Use hardcoded strings when --porcelain is used, but keep the gettext
> translation for "git status --short" which is essentially the sa
Duy Nguyen writes:
> On Thu, Mar 20, 2014 at 6:46 PM, Matthieu Moy
> wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> git-compat-util.h does not seem to carry S_IXUGO. Anyway as far as Git
>>> is concerned, we only care one executable bit. Hard code it.
>>
>> Why not use S_IXUSR instead of a hardc
Matthieu Moy writes:
> Why?
>
> (In general, explaining why you chose something is more important than
> explaining what you chose)
Good educational comment. Thanks.
> A tree (AST, Abstract syntax tree) can be interesting if you have some
> source-to-source transformations to do on the configu
Hi,
I have gone through commit.c, builtin/commit.c and api-config.txt but one
thing I cannot find is which functions handle writing config file to disk
after adding a new variable,value pair(for example git config my.option
true) . It is also marked TODO on the api-config.txt file. Can somebody he
Dragos Foianu writes:
> parse_dirstat_params() goes through a chain of if statements using
> strcmp to parse parameters. When the parameter is a digit, the
> value must go through all comparisons before the function realises
> it is a digit. Optimise this logic by only going through the chain
> o
On Fri, Mar 21, 2014 at 3:53 AM, Junio C Hamano wrote:
> Chris Angelico writes:
>
>> file. It doesn't really care about the full history, and wants to be
>> reasonably fast (as the user is waiting for it). It's just a
>> convenience, so correctness isn't a huge issue. The easiest way to
>> keep i
Duy Nguyen writes:
> On Thu, Mar 20, 2014 at 5:11 AM, Junio C Hamano wrote:
> ...
>> I know that the 512MiB default for the bitFileThreashold (aka
>> "forget about delta compression") came out of thin air. It was just
>> "1GB is always too huge for anybody, so let's cut it in half and
>> declar
On 03/11/2014 10:41 PM, Brad King wrote:
> On Tue, Mar 11, 2014 at 4:06 PM, Junio C Hamano wrote:
>> I may be misremembering things, but your first sentence quoted above
>> was exactly my reaction while reviewing the original change, and I
>> might have even raised that as an issue myself, saying
Chris Angelico writes:
> file. It doesn't really care about the full history, and wants to be
> reasonably fast (as the user is waiting for it). It's just a
> convenience, so correctness isn't a huge issue. The easiest way to
> keep it moving through quickly is to limit the search:
>
> $ git log
On Thu, Mar 20, 2014 at 11:53 PM, Kevin wrote:
> On Wed, Mar 19, 2014 at 12:16 PM, Chris Angelico wrote:
>> Two parts to the question, then. Firstly, is it acceptable to use 'git
>> config' for a hook like this? And secondly, either: Is there a naming
>> convention to follow? or, what alternative
Jonathan Nieder writes:
> Junio C Hamano wrote:
> ...
>> I am a bit reluctant to name the helper "sane_echo" to declare "echo
>> that interprets backslashes in the string is insane", though. For
>> these "print a single line" uses, we are only interested in using a
>> subset of the features offe
Hello,
I have completed my microproject under the guidance of Eric, After
going through the code and
previous mailing lists. I have drafted my Proposal. Still going
through the code
as of now and figuring things out. Would be great to have your
suggestions on my proposal, so that i can improve it b
On Thu, Mar 20, 2014 at 6:54 AM, Karsten Blees wrote:
> Am 19.03.2014 01:46, schrieb sza...@chromium.org:
>> This adds a Windows implementation of pread. Note that it is NOT
>> safe to intersperse calls to read() and pread() on a file
>> descriptor.
>
> This is a bad idea. You're basically fixing
Hello,
My name is Guanglin Xu. I am a second-year master student at Sun
Yat-sen University in China, majoring in Software Engineering. I am
also a perspective PhD student matriculated in the US. I'm planning on
doing summer projects which I can work remotely. The GSoC 2014 program
of Git project i
We offer all purpose loan at 3% interest rate. Contact Us for more details by
Email:santanderfinancegr...@gmail.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-info.
Am 19.03.2014 01:46, schrieb sza...@chromium.org:
> This adds a Windows implementation of pread. Note that it is NOT
> safe to intersperse calls to read() and pread() on a file
> descriptor.
This is a bad idea. You're basically fixing the multi-threaded issue twice,
while at the same time breaki
Hi,
Sorry for this late reply, I was busy for past few days.
On Fri, Mar 14, 2014 at 12:34 PM, Jeff King wrote:
> On Wed, Mar 12, 2014 at 04:19:23PM +0800, Yuxuan Shui wrote:
>
>> I'm Yuxuan Shui, a undergraduate student from China. I'm applying for
>> GSoC 2014, and here is my proposal:
>>
>> I
User config file location now complies with the XDG base directory specification
Signed-off-by: Astril Hayato
---
Documentation/gitk.txt | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 1e9e38a..7e03fcc 100644
--
On Wed, Mar 19, 2014 at 12:16 PM, Chris Angelico wrote:
> Two parts to the question, then. Firstly, is it acceptable to use 'git
> config' for a hook like this? And secondly, either: Is there a naming
> convention to follow? or, what alternative would you recommend?
1. I would say yes. git config
On Thu, Mar 20, 2014 at 6:46 PM, Matthieu Moy
wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> git-compat-util.h does not seem to carry S_IXUGO. Anyway as far as Git
>> is concerned, we only care one executable bit. Hard code it.
>
> Why not use S_IXUSR instead of a hardcoded value? (already used in
>
"git status --branch --porcelain" displays the status of the branch
(ahead, behind, gone), and used gettext to translate the string.
Use hardcoded strings when --porcelain is used, but keep the gettext
translation for "git status --short" which is essentially the same, but
meant to be read by a hu
1 - 100 of 124 matches
Mail list logo
