Previous description implicitly favored 'true' value for pull.rebase
and pull.branch.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
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
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:
On 8/5/2014 1:34 AM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com 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
Tanay Abhra tanay...@gmail.com 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
On 08/04/2014 03:13 AM, Duy Nguyen wrote:
On Sun, Aug 3, 2014 at 1:13 AM, Torsten Bögershausen tbo...@web.de 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 ;-)
Ramsay Jones ram...@ramsay1.demon.co.uk 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Tanay Abhra tanay...@gmail.com 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,
Signed-off-by: Marc Branchaud marcn...@xiplink.com
---
(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
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?
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 ralf.thie...@gmail.com
---
po/de.po | 131 ++-
1 file changed, 62 insertions(+), 69
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
...
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
Marc Branchaud marcn...@xiplink.com 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
Marc Branchaud marcn...@xiplink.com writes:
Signed-off-by: Marc Branchaud marcn...@xiplink.com
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
On Mon, Aug 4, 2014 at 9:19 PM, Karsten Blees karsten.bl...@gmail.com 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
Junio C Hamano gits...@pobox.com writes:
Marc Branchaud marcn...@xiplink.com 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
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 item
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
-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
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.
|
| *
brian m. carlson sand...@crustytoothpaste.net 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
There are several ways to configure Git to preserve merges.
There is pull.rebase=preserve for all branches and
branch.name.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
From: Junio C Hamano gits...@pobox.com
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
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
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
On 14-08-05 02:43 PM, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Marc Branchaud marcn...@xiplink.com writes:
...
@@ -87,22 +87,20 @@ UI, Workflows Features
* git mergetool learned to drive the vimdiff3 backend.
* mergetool.prompt used to default to 'true',
Linus Arver linusar...@gmail.com writes:
Signed-off-by: Linus Arver linusar...@gmail.com
---
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
---
Linus Arver linusar...@gmail.com writes:
Signed-off-by: Linus Arver linusar...@gmail.com
---
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?
Linus Arver linusar...@gmail.com writes:
Signed-off-by: Linus Arver linusar...@gmail.com
---
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
Linus Arver linusar...@gmail.com writes:
Signed-off-by: Linus Arver linusar...@gmail.com
---
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
---
On Tue, Aug 5, 2014 at 2:56 PM, Nico Williams n...@cryptonector.com 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
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
Sergey Organov sorga...@gmail.com writes:
Previous description implicitly favored 'true' value for pull.rebase
and pull.branch.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,
Ralf Thielow ralf.thie...@gmail.com writes:
There are several ways to configure Git to preserve merges.
There is pull.rebase=preserve for all branches and
branch.name.rebase=preserve for individual branches.
However, there is no configuration option to preserve merges
for all branches when
I'll address the comments about style in a revised patch.
On Aug 4, 2014, at 9:03 PM, Junio C Hamano gits...@pobox.com 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
On Aug 6, 2014, at 6:22 AM, Steffen Prohaska proha...@zib.de wrote:
On Aug 4, 2014, at 9:03 PM, Junio C Hamano gits...@pobox.com 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
On Tue, Aug 05, 2014 at 03:06:00PM -0700, Junio C Hamano wrote:
Linus Arver linusar...@gmail.com writes:
Signed-off-by: Linus Arver linusar...@gmail.com
---
Documentation/git-init.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
On Tue, Aug 05, 2014 at 03:10:30PM -0700, Junio C Hamano wrote:
Linus Arver linusar...@gmail.com writes:
Signed-off-by: Linus Arver linusar...@gmail.com
---
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
On Tue, Aug 05, 2014 at 03:12:21PM -0700, Junio C Hamano wrote:
Linus Arver linusar...@gmail.com writes:
Signed-off-by: Linus Arver linusar...@gmail.com
---
You would need to work on your justification skills ;-) in the log
message. What does this change clarify and in what way?
Oops,
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 proha...@zib.de
---
convert.h | 5 ++---
sha1_file.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
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
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
On Tue, Aug 05, 2014 at 03:14:48PM -0700, Junio C Hamano wrote:
Linus Arver linusar...@gmail.com writes:
Signed-off-by: Linus Arver linusar...@gmail.com
---
Documentation/git-init.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
43 matches
Mail list logo
