Translate 99 new messages came from git.pot update in
28b3cff (l10n: git.pot: v1.8.4 round 1 (99 new, 46 removed)).
Signed-off-by: Ralf Thielow
---
Hi Thomas,
thanks for review!
> -"Arbeitsverzeichnis von Submodul in '$sm_path' enthält lokale Änderungen; "
> -"verwenden Sie '-f' um diese zu
This commit introduces the VIEW_NO_PARENT_NAV flag and adds it to the
log view. This allows the scrolling commands to fall through from the
pager to the diff when the diff is viewed in the log mode.
Signed-Off-By: Kumar Appaiah
---
tig.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
On Thu, Aug 1, 2013 at 3:29 AM, Dale R. Worley wrote:
> I've run into a problem (with Git 1.8.3.3) where I cannot add a
> symbolic link (as such) to the repository *if* its path is given
> absolutely; instead Git adds the file the symbolic link points to.
> (If I give the path relatively, Git does
Jeff King writes:
> 1. Git-config expects pre-canonicalized variable names (so http.noepsv
> instead of "http.noEPSV"). I think the "git config --get" code path
> does this for the caller, so we should probably do the same for
> "--get-urlmatch". And it is even easier here, becau
On Wed, Jul 31, 2013 at 04:03:01PM -0700, Kyle J. McKay wrote:
> > 1. Git-config expects pre-canonicalized variable names (so
> >http.noepsv
> >instead of "http.noEPSV"). I think the "git config --get" code
> >path
> >does this for the caller, so we should probably do the same for
> >"
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Hopefully the 1.8.4-rc1 tomorrow with topics marked for 'master'
in this issue of "What's cooking" report.
You can find the changes described h
Stefan Beller writes:
> On 07/31/13 00:28, Junio C Hamano wrote:
>>
>> we could just do
>>
>> #define OPT_CMDMODE(s, l, v, h) \
>> { OPTION_CMDMODE, (s), (l), (v), NULL, \
>> (h), PARSE_OPT_NOARG|PARSE_OPT_NONEG, NULL, (s) }
>>
>
> I agree that's a better proposal than mine.
By the
On Jul 31, 2013, at 15:45, Jeff King wrote:
On Wed, Jul 31, 2013 at 12:26:08PM -0700, Junio C Hamano wrote:
Using the same urlmatch_config_entry() infrastructure, add a new
mode "--get-urlmatch" to the "git config" command, to learn values
for the "virtual" two-level variables customized for t
On Wed, Jul 31, 2013 at 10:13:20PM +0200, Thomas Rast wrote:
> When using pathspec filtering in combination with diff-based log
> output, parent simplification happens before the diff is computed.
> The diff is therefore against the *simplified* parents.
>
> This works okay, arguably by accident,
On Thu, Aug 01, 2013 at 12:25:32AM +0200, Jens Müller wrote:
> Hi all!
>
> I mainly use Git for version control, but have also tried out Mercurial.
> While I don't really like Mercurial in general, the idea of maintaining
> clearly separated patches with Mercurial Queues (MQ) is quite appealing.
>
On Wed, Jul 31, 2013 at 12:26:08PM -0700, Junio C Hamano wrote:
> Using the same urlmatch_config_entry() infrastructure, add a new
> mode "--get-urlmatch" to the "git config" command, to learn values
> for the "virtual" two-level variables customized for the specific
> URL.
>
> git config [--
Use the urlmatch_config_entry() to wrap the underlying
http_options() two-level variable parser in order to set
http. to the value with the most specific URL in the
configuration.
Signed-off-by: Jeff King
Signed-off-by: Kyle J. McKay
Signed-off-by: Junio C Hamano
---
Somehow I managed to screw
Hi all!
I mainly use Git for version control, but have also tried out Mercurial.
While I don't really like Mercurial in general, the idea of maintaining
clearly separated patches with Mercurial Queues (MQ) is quite appealing.
Therefore, I am looking for something similar (but easier to use, more
"
Thomas Rast writes:
> We spell config variables in camelCase instead of with_underscores.
>
> Signed-off-by: Thomas Rast
> ---
>
> I figure since we don't have the variable in any release yet *and* the
> worst possible outcome is that someone sees the advice message again,
> the consistency is w
Thanks for a quick turnaround. Will replace the two patches with
these and queue.
--
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 Wed, Jul 31, 2013 at 05:31:47PM -0400, Dale R. Worley wrote:
> Notice that the whole commit message has been formatted as if it is
> part of the Subject line, and the line breaks in the commit message
> have been refilled.
>
> The file Documentation/SubmittingPatches says that "git format-patch
On Wed, Jul 31, 2013 at 02:31:34PM -0700, Brandon Casey wrote:
> On Wed, Jul 31, 2013 at 2:21 PM, Fredrik Gustafsson wrote:
> > On Wed, Jul 31, 2013 at 11:08:21PM +0200, Antoine Pelisse wrote:
> >> On Wed, Jul 31, 2013 at 9:51 PM, Brandon Casey wrote:
> >> > --
I'm working on writing a patch, but I'm running into a problem. The
patch itself is from this commit:
$ git log -1
commit 07a25537909dd277426818a39d9bc4235e755383
Author: Dale Worley
Date: Thu Jul 18 18:43:12 2013 -0400
open() returns -1 on failure, and indeed 0 is a p
On Wed, Jul 31, 2013 at 2:21 PM, Fredrik Gustafsson wrote:
> On Wed, Jul 31, 2013 at 11:08:21PM +0200, Antoine Pelisse wrote:
>> On Wed, Jul 31, 2013 at 9:51 PM, Brandon Casey wrote:
>> > ---
>> > This email message i
Antoine Pelisse writes:
> On Wed, Jul 31, 2013 at 9:51 PM, Brandon Casey wrote:
>> ---
>> This email message is for the sole use of the intended recipient(s) and may
>> contain
>> confidential information. Any unau
On Wed, Jul 31, 2013 at 2:08 PM, Antoine Pelisse wrote:
> On Wed, Jul 31, 2013 at 9:51 PM, Brandon Casey wrote:
>> ---
>> This email message is for the sole use of the intended recipient(s) and may
>> contain
>> conf
On Wed, Jul 31, 2013 at 11:08:21PM +0200, Antoine Pelisse wrote:
> On Wed, Jul 31, 2013 at 9:51 PM, Brandon Casey wrote:
> > ---
> > This email message is for the sole use of the intended recipient(s) and may
> > cont
On Wed, Jul 31, 2013 at 9:51 PM, Brandon Casey wrote:
> ---
> This email message is for the sole use of the intended recipient(s) and may
> contain
> confidential information. Any unauthorized review, use, disclosure
Hi Ralf
I made a feeble attempt to work directly on de.po so that I could send a
patch instead, but your patch was again linewrapping damaged at the last
line here at least:
-"Arbeitsverzeichnis von Submodul in '$sm_path' enthält lokale Änderungen; "
-"verwenden Sie '-f' um diese zu verwerfen
Use the urlmatch_config_entry() to wrap the underlying
http_options() two-level variable parser in order to set
http. to the value with the most specific URL in the
configuration.
Signed-off-by: Jeff King
Signed-off-by: Kyle J. McKay
Signed-off-by: Junio C Hamano
---
.gitignore |
This patch simply provides two alternative versions of the 2/6 and 4/6
patches previously sent as part of the:
[PATCH v6 0/6] http.. and friends
series. They are intended simply as complete alternatives to parts 2 and 4
that include the following changes:
2/4 - Include 1-line documentation up
Some http.* configuration variables need to take values customized
for the URL we are talking to. We may want to set http.sslVerify to
true in general but to false only for a certain site, for example,
with a configuration file like this:
[http]
sslVerify = true
[h
On Jul 31, 2013, at 12:26, Junio C Hamano wrote:
From: "Kyle J. McKay"
Use the urlmatch_config_entry() to wrap the underlying
http_options() two-level variable parser in order to set
http. to the value with the most specific URL in the
configuration.
Signed-off-by: Kyle J. McKay
Signed-off-b
On Jul 31, 2013, at 12:26, Junio C Hamano wrote:
From: "Kyle J. McKay"
Some http.* configuration variables need to take values customized
for the URL we are talking to. We may want to set http.sslVerify to
true in general but to false only for a certain site, for example,
with a configuration
I've run into a problem (with Git 1.8.3.3) where I cannot add a
symbolic link (as such) to the repository *if* its path is given
absolutely; instead Git adds the file the symbolic link points to.
(If I give the path relatively, Git does what I expect, that is, adds
the symbolic link.)
I've written
We spell config variables in camelCase instead of with_underscores.
Signed-off-by: Thomas Rast
---
I figure since we don't have the variable in any release yet *and* the
worst possible outcome is that someone sees the advice message again,
the consistency is worth the change.
advice.c| 2
When using pathspec filtering in combination with diff-based log
output, parent simplification happens before the diff is computed.
The diff is therefore against the *simplified* parents.
This works okay, arguably by accident, in the normal case:
simplification reduces to one parent as long as the
From: Brandon Casey
When the number of open packs exceeds pack_max_fds, unuse_one_window()
is called repeatedly to attempt to release the least-recently-used
pack windows, which, as a side-effect, will also close a pack file
after closing its last open window. If a pack file has been opened,
but
From: Brandon Casey
Now that close_one_pack() has been introduced to handle file
descriptor pressure, it is not strictly necessary to close the
pack file descriptor in unuse_one_window() when we're under memory
pressure.
Jeff King provided a justification for leaving the pack file open:
If y
Ramsay Jones writes:
> Junio C Hamano wrote:
>> So here is a bit of refactoring to extract the logic to find the
>> entry $section..$key from the configuration that best
>> matches the given $url to answer "what value $section.$key should be
>> for $url?" out of http.c (primarily because we never
This is my attempt to reroll Kyle's http.. series.
It adds a general .. support at the
infrastructure level and then rebuild http.. support on
top of it. A useful side effect of doing it this way is that it
avoids having to touch the two-name parser http_options() at all.
The same infrastructure
Using the same urlmatch_config_entry() infrastructure, add a new
mode "--get-urlmatch" to the "git config" command, to learn values
for the "virtual" two-level variables customized for the specific
URL.
git config [--] --get-urlmatch [.]
With . fully specified, the configuration data for
..
The existing code triggers only when the configuration variable is
set to true. Once the variable is set to true in a more generic
configuration file (e.g. ~/.gitconfig), it cannot be overriden to
false in the repository specific one (e.g. .git/config).
Signed-off-by: Junio C Hamano
---
http.c
Existing configuration parsing functions (e.g. http_options() in
http.c) know how to parse two-level configuration variable names.
We would like to exploit them and parse something like this:
[http]
sslVerify = true
[http "https://weak.example.com";]
From: "Kyle J. McKay"
Use the urlmatch_config_entry() to wrap the underlying
http_options() two-level variable parser in order to set
http. to the value with the most specific URL in the
configuration.
Signed-off-by: Kyle J. McKay
Signed-off-by: Junio C Hamano
---
.gitignore |
In order to reuse the logic to format the configuration value while
honouring the requested type, split this function into two.
Signed-off-by: Junio C Hamano
---
builtin/config.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/buil
From: "Kyle J. McKay"
Some http.* configuration variables need to take values customized
for the URL we are talking to. We may want to set http.sslVerify to
true in general but to false only for a certain site, for example,
with a configuration file like this:
[http]
ssl
Ramsay Jones writes:
>> I am personally in favor of this simpler solution. Comments?
>
> I had expected this to me marked for 'master'.
>
> Has this simply been overlooked, or do you have reservations about
> applying this patch?
I am just being careful and do want to keep it cooking in 'next'
Junio C Hamano wrote:
> So here is a bit of refactoring to extract the logic to find the
> entry $section..$key from the configuration that best
> matches the given $url to answer "what value $section.$key should be
> for $url?" out of http.c (primarily because we never want to link
> "git cofnig"
Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.
>
> The shape of the upcoming release is pretty much known by now; all
> the topics that are marked for 'master' in
Junio C Hamano wrote (Wed, Jul 31, 2013 at 10:03:15AM
-0700):
> Dirk Wallenstein writes:
>
> > diff --git a/Documentation/howto/rebase-from-internal-branch.txt
> > b/Documentation/howto/rebase-from-internal-branch.txt
> > index 19ab604..aefe5b1 100644
> > --- a/Documentation/howto/rebase-from-
On Wed, Jul 31, 2013 at 12:28 PM, Stefan Beller
wrote:
> The --no-create was parsed with OPT_BOOLEAN, which has a counting up
> logic implemented. Since b04ba2bb (parse-options: deprecate OPT_BOOLEAN,
> 2011-09-27) the OPT_BOOLEAN is deprecated and is only a define:
> /* Deprecated synonym
On Wed, Jul 31, 2013 at 12:28 PM, Stefan Beller
wrote:
> The --no-create was parsed with OPT_BOOLEAN, which has a counting up
> logic implemented. Since b04ba2bb (parse-options: deprecate OPT_BOOLEAN,
> 2011-09-27) the OPT_BOOLEAN is deprecated and is only a define:
> /* Deprecated synonym
On Wed, Jul 31, 2013 at 12:28 PM, Stefan Beller
wrote:
> This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN,
> 2011-09-27). hash-object is a plumbing layer command, so better
> not change the input/output behavior for now.
>
> Unfortunately we have these lines relying on the cou
On Wed, Jul 31, 2013 at 12:28 PM, Stefan Beller
wrote:
> This patch allows users to use the short form -q on
> log and format-patch, which was non possible before.
It would make sense for documentation updates to accompany these changes.
> Signed-off-by: Stefan Beller
> ---
> builtin/log.c | 5
Dirk Wallenstein writes:
> diff --git a/Documentation/howto/rebase-from-internal-branch.txt
> b/Documentation/howto/rebase-from-internal-branch.txt
> index 19ab604..aefe5b1 100644
> --- a/Documentation/howto/rebase-from-internal-branch.txt
> +++ b/Documentation/howto/rebase-from-internal-branch.
On Wed, Jul 31, 2013 at 06:54:07PM +0200, Dirk Wallenstein wrote:
> I really think that tabs are generally bad here. So, this will
> remove all tabs from the howto folder and prevent indenting with tabs
> through gitattributes.
>
> Dirk Wallenstein (2):
> howto: Suppress indentation with tabs
>
The AsciiDoc files in the 'howto' folder are installed as documentation
and AsciiDoc files are meant to be read and printed as is. To quote the
AsciiDoc Home Page:
AsciiDoc files are designed to be viewed, edited and printed
directly or translated to other presentation formats using the
Because tabs have a variable width, the layout can diverge from what the
author intended. Replace all tabs with spaces to the next column that
is a multiple of 8.
This fixes several ascii art sketches and a code example where viewing
it with a tab-width other than 8 lead to wrong indentation.
Si
I really think that tabs are generally bad here. So, this will
remove all tabs from the howto folder and prevent indenting with tabs
through gitattributes.
Dirk Wallenstein (2):
howto: Suppress indentation with tabs
howto: Eliminate all tabs
Documentation/howto/.gitattributes
The --no-create was parsed with OPT_BOOLEAN, which has a counting up
logic implemented. Since b04ba2bb (parse-options: deprecate OPT_BOOLEAN,
2011-09-27) the OPT_BOOLEAN is deprecated and is only a define:
/* Deprecated synonym */
#define OPTION_BOOLEAN OPTION_COUNTUP
However the v
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN,
2011-09-27). hash-object is a plumbing layer command, so better
not change the input/output behavior for now.
Unfortunately we have these lines relying on the count up mechanism of
OPT_BOOLEAN:
if (hashstdin > 1)
Now that the variables are readin by OPT_BOOL, which makes sure
to have the values being 0 or 1 after reading, we do not need
the double negation to map any other value to 1 for integer
variables.
Signed-off-by: Stefan Beller
---
builtin/branch.c | 3 ++-
builtin/commit.c | 2 +-
builtin/nam
This patch allows users to use the short form -q on
log and format-patch, which was non possible before.
Signed-off-by: Stefan Beller
---
builtin/log.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 1dafbd0..ed4dec4 100644
--- a/built
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN,
2011-09-27).
This commit introduces a change for the users, after this patch
you can pass one of the config level flags multiple times:
Before:
$ git config --global --global --list
error: only one config file a
The revert command comes with their own implementation of checking
for exclusiveness of parameters.
Now that the OPT_CMDMODE is in place, we can also rely on that macro
instead of cooking that solution for each command itself.
This commit also replaces OPT_BOOLEAN, which was deprecated by b04ba2bb
Signed-off-by: Stefan Beller
---
builtin/checkout.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 8b48f4a..ed39cec 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -228,8 +228,6 @@ static int checkout_path
I am rerolling "Removing deprecated parsing macros" series.
Now with more patches! ;)
The patches apply on top of origin/jc/parseopt-command-modes
Within the builtin/ folder all occurrences of OPT_BOOLEAN have been removed.
Now we only need to review the usage of it in parse-options as used in
OP
As of b04ba2bb4 OPTION_BOOLEAN was deprecated.
This commit removes all occurrences of OPTION_BOOLEAN.
In b04ba2bb4 Junio suggested to replace it with either
OPTION_SET_INT or OPTION_COUNTUP instead. However a pattern, which
occurred often with the OPTION_BOOLEAN was a hidden boolean parameter.
So I
Jens Lehmann writes:
> Am 29.07.2013 21:37, schrieb Thomas Rast:
>> Thomas Rast writes:
>>
>>> Thomas Rast writes:
>>>
Now that git log -L has hit master, I figure it's time to discuss the
corresponding change to gitk.
>>>
>>> Paul, any news on this? Any chance we can get it into th
To answer my own question...
My issue turned to be caused by a bad graft in my repo (unfortunately,
since hardened with filter-branch) that was making the commit that
modified F on Y reachable from X. The graft was an (incorrectly
executed) attempt to deal with the "3+ parent" problem that sometim
On 07/30/13 00:05, René Scharfe wrote:
> Am 29.07.2013 21:49, schrieb Stefan Beller:
>> const struct option builtin_log_options[] = {
>> -OPT_BOOL(0, "quiet", &quiet, N_("suppress diff output")),
>> +OPT_BOOL('q', "quiet", &quiet, N_("suppress diff output")),
>
> You can shor
On 07/31/13 00:28, Junio C Hamano wrote:
>
> we could just do
>
> #define OPT_CMDMODE(s, l, v, h) \
> { OPTION_CMDMODE, (s), (l), (v), NULL, \
> (h), PARSE_OPT_NOARG|PARSE_OPT_NONEG, NULL, (s) }
>
I agree that's a better proposal than mine.
signature.asc
Description: OpenPGP digita
I am getting some unexpected results from a merge and I'd like to
understand why.
I have two commits X and Y that I want to merge.
git merge-base X Y # yields B
git diff B X -- F # is empty
git diff B Y -- F # contains the change I want merged
git rev-list X ^B -- F # is empty
git rev-list Y ^B
On Tue, Jul 30, 2013 at 09:50:03PM +0200, Jens Lehmann wrote:
> +/* Update gitfile and core.worktree setting to connect work tree and git dir
> */
> +void connect_work_tree_and_git_dir(const char *work_tree, const char
> *git_dir)
> +{
> + struct strbuf file_name = STRBUF_INIT;
> + struct
58960978 and 99780b0a added tests which demonstrated bugs (crashes) in
range-set and line-log when handed empty ranges specified via "log
-LX:file" where X is one greater than the last line of the file. After
these tests were added, it was realized that the ability to specify an
empty range is a l
Empty ranges -L,+0 and -L,-0 are nonsensical in the context of blame yet
they are accepted (in fact, both are interpreted as -L1,Y where Y is
end-of-file). Report them as invalid.
Signed-off-by: Eric Sunshine
---
line-range.c| 2 +-
t/annotate-tests.sh | 4 ++--
2 files changed, 3 insert
A bounds checking bug allows the X in -LX to extend one line past the
end of file. For example, given a file with 5 lines, -L6 is accepted as
valid. Demonstrate this problem.
While here, also add tests to check that the remaining cases of X and Y
in -LX,Y are handled correctly at and in the vicini
Empty ranges -L,+0 and -L,-0 are nonsensical in the context of blame yet
they are accepted. They should be errors. Demonstrate this shortcoming.
Signed-off-by: Eric Sunshine
---
t/annotate-tests.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/annotate-tests.sh b/t/annotate-tests
A bounds checking bug allows the X in -LX to extend one line past the
end of file. For example, given a file with 5 lines, -L6 is accepted as
valid. Demonstrate this problem.
While here, also add tests to check that the remaining cases of X and Y
in -LX,Y are handled correctly at and in the vicini
Empty ranges -LX,+0 and -LX,-0 are nonsensical in the context of blame
yet they are accepted. They should be errors. Demonstrate this
shortcoming.
Signed-off-by: Eric Sunshine
---
t/annotate-tests.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/annotate-tests.sh b/t/annotate-tes
When 12da1d1f added -L support to git-log, a broken bounds check was
copied from git-blame -L which incorrectly allows -LX to extend one line
past end of file without reporting an error. Instead, it generates an
empty range. Fix this bug.
Signed-off-by: Eric Sunshine
---
line-log.c |
Checking all bogus -L syntax forms in a single test makes it difficult
to identify the offender when one case fails. Decompose this
conglomerate test in order to check each bad syntax case separately.
Signed-off-by: Eric Sunshine
---
t/annotate-tests.sh | 32 +---
1 f
While working on multiple -L support for git-blame, I encountered more
issues with the existing -L facility in git-blame and git-log. This
series fixes these problems and adds a slew of new tests.
Patch 6/11 (t4211: retire soon-to-be unimplementable tests) may be
controversial. Removal of these te
Empty ranges -LX,+0 and -LX,-0 are nonsensical in the context of blame
yet they are accepted (in fact, both are interpreted as -LX,+2). Report
them as invalid.
Signed-off-by: Eric Sunshine
---
line-range.c| 2 ++
t/annotate-tests.sh | 4 ++--
2 files changed, 4 insertions(+), 2 deletion
Since inception, -LX,Y has correctly reported an out-of-range error when
Y is beyond end of file, however, X was not checked, and an out-of-range
X would cause a crash. 92f9e273 (blame: prevent a segv when -L given
start > EOF; 2010-02-08) attempted to rectify this shortcoming but has
its own off-
Add boundary case tests, with and without -L, for empty file; file with
one partial line; file with one full line.
The empty file test without -L is of particular interest. Historically,
this case has been supported (empty blame output) and this test protects
against regression by a subsequent pat
82 matches
Mail list logo
