On Tue, Aug 05, 2014 at 03:14:48PM -0700, Junio C Hamano wrote:
> Linus Arver writes:
>
> > Signed-off-by: Linus Arver
> > ---
> > Documentation/git-init.txt | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/git-init.txt b/Documentation/git-init.
It is only the path that matters in the decision whether to filter or
not. Clarify this by making path the single argument of
would_convert_to_git().
Signed-off-by: Steffen Prohaska
---
convert.h | 5 ++---
sha1_file.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/con
The main difference to the previous version is that I've split off the
refactoring into a separate commit. The rest is polishing the style.
Steffen Prohaska (2):
convert: Refactor would_convert_to_git() to single arg 'path'
convert: Stream from fd to required clean filter instead of mmap
co
The data is streamed to the filter process anyway. Better avoid mapping
the file if possible. This is especially useful if a clean filter
reduces the size, for example if it computes a sha1 for binary data,
like git media. The file size that the previous implementation could
handle was limited b
On Tue, Aug 05, 2014 at 03:12:21PM -0700, Junio C Hamano wrote:
> Linus Arver writes:
>
> > Signed-off-by: Linus Arver
> > ---
>
> You would need to work on your justification skills ;-) in the log
> message. What does this change "clarify" and in what way?
Oops, sorry. I guess I should have
On Tue, Aug 05, 2014 at 03:10:30PM -0700, Junio C Hamano wrote:
> Linus Arver writes:
>
> > Signed-off-by: Linus Arver
> > ---
>
> This seems to reword and also reformat at the same time, but was the
> latter change (i.e. to unindent the bulletted items and to remove
> blank lines between items
On Tue, Aug 05, 2014 at 03:06:00PM -0700, Junio C Hamano wrote:
> Linus Arver writes:
>
> > Signed-off-by: Linus Arver
> > ---
> > Documentation/git-init.txt | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/git-init.txt b/Documentation/git-init.
On Aug 6, 2014, at 6:22 AM, Steffen Prohaska wrote:
> On Aug 4, 2014, at 9:03 PM, Junio C Hamano wrote:
>
>>> + return apply_filter(path, 0, 0, -1, 0, ca.drv->clean);
>>
>> What's the significance of "-1" here? Does somebody in the
>> callchain from apply_filter() check if fd < 0 and act d
I'll address the comments about style in a revised patch.
On Aug 4, 2014, at 9:03 PM, Junio C Hamano wrote:
>> +return apply_filter(path, 0, 0, -1, 0, ca.drv->clean);
>
> What's the significance of "-1" here? Does somebody in the
> callchain from apply_filter() check if fd < 0 and act dif
Ralf Thielow writes:
> There are several ways to configure Git to preserve merges.
> There is "pull.rebase=preserve" for all branches and
> "branch..rebase=preserve" for individual branches.
> However, there is no configuration option to preserve merges
> for all branches when running git-rebase.
Sergey Organov writes:
> Previous description implicitly favored 'true' value for "pull.rebase"
> and "pull..rebase" options,
I do not share that impression. It is true that 'true' is described
first before 'preserve', which can be argued that it is being
implicitly favoured, but we have to pic
Excellent. Thanks!
--
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.html
On Tue, Aug 5, 2014 at 2:56 PM, Nico Williams wrote:
> Personally (a user of, not a maintainer of, git) I really want some
> alternative backends. In particular I'm after something like Fossil's
> use of SQLite3; I want a SQLite3 backend for several reasons, not the
> least of which is the power
Linus Arver writes:
> Signed-off-by: Linus Arver
> ---
> Documentation/git-init.txt | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
> index b94d165..16e9f9c 100644
> --- a/Documentation/git-init.txt
> +++ b/D
Linus Arver writes:
> Signed-off-by: Linus Arver
> ---
You would need to work on your justification skills ;-) in the log
message. What does this change "clarify" and in what way?
> Documentation/git-init.txt | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git
Linus Arver writes:
> Signed-off-by: Linus Arver
> ---
This seems to reword and also reformat at the same time, but was the
latter change (i.e. to unindent the bulletted items and to remove
blank lines between items) necessary?
> Documentation/git-init.txt | 14 +-
> 1 file change
Linus Arver writes:
> Signed-off-by: Linus Arver
> ---
> Documentation/git-init.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
> index afd721e..5ed5859 100644
> --- a/Documentation/git-init.txt
> +++ b/D
On 14-08-05 02:43 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Marc Branchaud writes:
>> ...
>>> @@ -87,22 +87,20 @@ UI, Workflows & Features
>>> * "git mergetool" learned to drive the vimdiff3 backend.
>>>
>>> * mergetool.prompt used to default to 'true', always asking "do you
Personally (a user of, not a maintainer of, git) I really want some
alternative backends. In particular I'm after something like Fossil's
use of SQLite3; I want a SQLite3 backend for several reasons, not the
least of which is the power of SQL for looking at history.
I'm not sure that I necessaril
List, Michael,
Please see
https://github.com/rsahlberg/git/tree/backend-struct-db-2
for an example of a pluggable backend for refs storage.
This series contain changes to make it possible to add new backends
for handling/storage of refs and implements one new backend :
refs-be-be.c .
This new ba
From: "Junio C Hamano"
Continued: this message covers the last part.
| Repository Administration[[Repository Administration]]
| --
|
| A repository administrator uses the following tools to set up
| and maintain access to the repository by d
There are several ways to configure Git to preserve merges.
There is "pull.rebase=preserve" for all branches and
"branch..rebase=preserve" for individual branches.
However, there is no configuration option to preserve merges
for all branches when running git-rebase.
This patch introduces a new con
"brian m. carlson" writes:
> It wouldn't make sense for these configuration variables to be
> required for Git in general to function. 'Required' in this context
> means required for git imap-send to work.
>
> Noticed while trying to figure out what the sentence describing
> imap.tunnel meant.
>
Continued: this message covers the last part.
| Repository Administration[[Repository Administration]]
| --
|
| A repository administrator uses the following tools to set up
| and maintain access to the repository by developers.
|
| * linkgit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
In git add -i when staging the modifications piecemail by patching there
should be a command for showing more context.
It can be sometimes difficult to determine whether any hunk should be staged
without refering to more source code.
As a comm
On Mon, Aug 04, 2014 at 09:20:02PM +0200, Karsten Blees wrote:
> > I don't see any reason to avoid the packed attribute, if it helps us. As
> > you noted, anything using __attribute__ probably supports it, and if
> > not, we can conditionally #define PACKED_STRUCT or something, like we do
> > for
On Mon, Aug 04, 2014 at 09:19:46PM +0200, Karsten Blees wrote:
> Hmm, I wonder if it wouldn't be simpler to read / write the desired on-disk
> structure directly, without copying to a uchar[6] first.
Probably. My initial attempt was to keep together the read/write logic
about which sizes each ite
Junio C Hamano writes:
> Marc Branchaud writes:
> ...
>> @@ -87,22 +87,20 @@ UI, Workflows & Features
>> * "git mergetool" learned to drive the vimdiff3 backend.
>>
>> * mergetool.prompt used to default to 'true', always asking "do you
>> - really want to run the tool on this path?". Am
On Mon, Aug 4, 2014 at 9:19 PM, Karsten Blees wrote:
> This raises the question why we read via mmap at all
The first version of the pack bitmap format I wrote for GitHub was 50%
faster to load than this one because it was designed to be mmapable.
Eventually we moved to the JGit-compatible bitmap
Marc Branchaud writes:
> Signed-off-by: Marc Branchaud
> diff --git a/Documentation/RelNotes/2.1.0.txt
> b/Documentation/RelNotes/2.1.0.txt
Many are indeed grammatical errors, and many others make the result
easier to read, even if the original weren't incorrect per-se.
> @@ -87,22 +87,20 @@
Marc Branchaud writes:
> On 14-08-04 06:31 PM, Junio C Hamano wrote:
>>
>> * "git grep" learned grep.fullname configuration variable to force
>>"--full-name" to be default. This may cause regressions on
>>scripted users that do not expect this new behaviour.
>
> Should this be noted in
"Philip Oakley" writes:
> From: "Junio C Hamano"
> ...
>> Nowhere I am assuming that "the reader is creating paches based on
>> wherever someone else had got to". Sorry, but I have no idea what
>> you are complaining about.
>
> I think we are talking at cross purposes. My starting point is that
Translate 38 new messages came from git.pot update in fe05e19
(l10n: git.pot: v2.1.0 round 1 (38 new, 9 removed)).
Signed-off-by: Ralf Thielow
---
po/de.po | 131 ++-
1 file changed, 62 insertions(+), 69 deletions(-)
diff --git a/po/de
On 14-08-04 06:31 PM, Junio C Hamano wrote:
>
> * "git grep" learned grep.fullname configuration variable to force
>"--full-name" to be default. This may cause regressions on
>scripted users that do not expect this new behaviour.
Should this be noted in the backward compatibility notes?
Signed-off-by: Marc Branchaud
---
(Note that I did not reflow lines to keep them a specific length.)
Documentation/RelNotes/2.1.0.txt | 108 +++
1 file changed, 53 insertions(+), 55 deletions(-)
diff --git a/Documentation/RelNotes/2.1.0.txt b/Documentation/R
Matthieu Moy writes:
> Tanay Abhra writes:
>
>> Currently works like the old git_config() error reporting path. If err is
>> set to "NULL",
>> it would print no error message and just the die message. If given something
>> like,
>>
>> git_config_die(key, "value '%s' is not allowed", valu
Ramsay Jones writes:
> On 04/08/14 23:31, Junio C Hamano wrote:
>>
>> * The leaf function to check validity of a refname format has been
>>micro-optimized, using SSE2 instructions when available. A few
>>breakages during its development have been caught and fixed already
>>but ther
On 08/04/2014 03:13 AM, Duy Nguyen wrote:
> On Sun, Aug 3, 2014 at 1:13 AM, Torsten Bögershausen wrote:
> [...]
>> My first impression reading this patch was to rename
>> clear_filename() into free_and_clear_filename() or better free_filename(),
>> but I never pressed the send button ;-)
>>
>> Rea
Tanay Abhra writes:
> Matthieu, I have finished the new version, but instead of flooding the
> mailing list with
> a series again, I wanted to confirm if the new git_config_die() is alright.
>
> NORETURN __attribute__((format(printf, 2, 3)))
> void git_die_config(const char *key, con
On 8/5/2014 1:34 AM, Matthieu Moy wrote:
> Tanay Abhra writes:
>
>> I was aping the old git_config() system, it also does exactly what you
>> described
>> above. for example, builtin/gc.c line 91,
>>
>> if (!strcmp(var, "gc.pruneexpire")) {
>> if (value && strcmp(value,
On 8/5/2014 7:27 PM, Ramsay Jones wrote:
>
> Commit 3a2a9527 ("config: add `git_die_config()` to the config-set
> API", 01-08-2014) added git_die_config() and git_die_config_linenr()
> functions, but forgot to include the NORETURN attribute in their
> declarations. Sparse complains like so:
>
>
Commit 3a2a9527 ("config: add `git_die_config()` to the config-set
API", 01-08-2014) added git_die_config() and git_die_config_linenr()
functions, but forgot to include the NORETURN attribute in their
declarations. Sparse complains like so:
SP config.c
config.c:1567:6: error: symbol '
Previous description implicitly favored 'true' value for "pull.rebase"
and "pull..rebase" options, when for some workflows 'preserve'
is the right choice, and for others it hardly makes any difference.
Therefore, 'preserve' should be preferred in general, unless the user
knows exactly what she is d
43 matches
Mail list logo
