Sitaram Chamarty writes:
> Whatever it was that happened to a hundred or more repos on the Jenkins
> project seems to be stirring up this debate in some circles.
Making us so curious ... and then you just leave us hanging there ;-)
Any pointers to this debate?
--
Thomas Rast
t...@thomasrast.c
git-config used a static match array to hold the matches we want to
unset/replace when using --unset or --replace-all. Use a
variable-sized array instead.
This in particular fixes the symptoms git-svn had when storing large
numbers of svn-remote.*.added-placeholder entries in the config file.
Wh
Hi Philip. I don't have any setting like that in either my
~/.gitconfig, or in the .git/config files. I really haven't tweaked
my git config at all.
This is a typical .git/config file:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url
Junio C Hamano wrote:
> Perhaps like this (obviously not tested as these three patches did
> not add any tests ;-)
Sorry about that. I didn't notice t6300-for-each-ref.sh. Will fix in
the next round.
> I also think that there should be a mechanism to do "color:reset"
> after each record is issued
Junio C Hamano wrote:
> builtin/for-each-ref.c: In function 'populate_value':
> builtin/for-each-ref.c:701:13: error: 'refname' may be used uninitialized in
> this function [-Werror=uninitialized]
In my defense, the gcc on my end (4.8.2) doesn't seem to complain. Are
you using extra cflags?
Howe
[top posting, and not preserving cc's because the original email thread
below is just for context; I don't want to force people into a
discussion that they may have considered closed :-)]
Is there *any* way we can preserve a reflog for a deleted branch,
perhaps under logs/refs/deleted//full/ref/na
On Wed, Nov 13, 2013 at 08:43:28AM +0100, Yann COLLETTE wrote:
> Hello,
>
> When I perform the git clone via git, it works. The problem is only
> happening via http.
> I tried to play with http.postBuffer and I set this parameter to
> it's maximum (a little bit before a git clone triggered a memor
Nguyễn Thái Ngọc Duy wrote:
> Strings are only marked for translations, the actual lookup is delayed
> until inside print_ref_status(), so we only have to check for
> porcelain flag once.
I was confused about what this means (why would it be faster to call
gettext() once inside print_ref_status()
On Wed, Nov 13, 2013 at 5:19 AM, Thomas Rast wrote:
> diff --git a/t/t1303-wacky-config.sh b/t/t1303-wacky-config.sh
> index 46103a1..7d55730 100755
> --- a/t/t1303-wacky-config.sh
> +++ b/t/t1303-wacky-config.sh
> @@ -47,4 +58,57 @@ test_expect_success 'do not crash on special long config
> line
From: "Junio C Hamano"
To: "Ken Tanzer"
Sent: Wednesday, November 13, 2013 5:04 PM
Ken Tanzer writes:
I am not very much surprised if such a file misbehaves, because the
"format-patch | am" pipeline is designed to be used on patches that
can be transferred in plain-text e-mail safely. Long
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 second release candidate has been tagged. Hopefully we can have
an uneventful 1.8.5 final next week.
You can find the changes described he
A release candidate Git v1.8.5-rc2 is now available for testing
at the usual places.
We now have updated l10n strings, but other than that there is not
much change since v1.8.5-rc1; hopefully we can have an uneventful
final release mid next week.
The release tarballs are found at:
http://co
"Jason St. John" writes:
> Documentation/git-log.txt:
> -- replace single quotes around options/commands with backticks
> -- use single quotes around references to sections
> -- replaced some double quotes with proper AsciiDoc quotes (e.g.
> ``foo'')
> -- use backticks around files and file
Junio C Hamano writes:
> Ramkumar Ramachandra writes:
>
>> +} else if (!prefixcmp(name, "color")) {
>> +;
>
> How is "%(color:short)" parsed with this code?
>
> This part says, "Yeah, I see something starting with color", and
> then later strchr(name, ':') will po
Jens Lehmann writes:
>> If we were introducing a divider line for machine consumption, I do
>> not think it is wise to let that line even translated...
>
> Ok, but then it won't mean much to readers who don't understand
> English. I assume prefixing all diff lines with "# " is out of
> the questi
Ramkumar Ramachandra writes:
> + } else if (!prefixcmp(name, "color")) {
> + ;
How is "%(color:short)" parsed with this code?
This part says, "Yeah, I see something starting with color", and
then later strchr(name, ':') will point formatp to "short".
Luckily, "%
Junio C Hamano writes:
> You need to squash 78465bb,...
oops; make it 2249926. 784 is a cherry-pick of it on top of this round.
--
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/m
You need to squash 78465bb, which has been queued on the previous
round, in to this step. There also is a similar issue introduced by
the updated 3/3:
builtin/for-each-ref.c: In function 'populate_value':
builtin/for-each-ref.c:701:13: error: 'refname' may be used uninitialized in
this function
Am 12.11.2013 23:20, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> Am 12.11.2013 08:46, schrieb Johannes Sixt:
>>> Am 11.11.2013 22:29, schrieb Jens Lehmann:
The diff below fixes the problem you describe for me. (But I do not
consider it a worthwhile fix in its current form becaus
"Jason St. John" writes:
> rev-list-options.txt:
> -- added line breaks before some "endif" AsciiDoc commands to fix syntax
> highlighting in Vim
> -- added line breaks after some options subheadings to fix syntax
> highlighting in Vim
Can't Vim be fixed instead (just kidding ;-)?
> -
"Jason St. John" writes:
> + Backticks are used around options or commands:
> + `--pretty=oneline`
> + `git rev-list`
I'd prefer to see the objective stated before a particular means to
achieve it. I.e. not "backticks around options and commands", but
"literal examples (e.g. use of command
Ken Tanzer writes:
>> I am not very much surprised if such a file misbehaves, because the
>> "format-patch | am" pipeline is designed to be used on patches that
>> can be transferred in plain-text e-mail safely. Long lines should
>> probably be OK, but mixed CRLF, CR and LF may be problematic.
>
Am 08.11.2013 18:08, schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> What about this:
>>
>> #define HASHMAP_GROW_AT 80
>> #define HASHMAP_SHRINK_AT 16
>
> I am not too enthused for three reasons. The fact that these are
> 100-based numbers is not written down anywhere other than the place
>
On 11/02/2013 12:09 AM, Thomas Rast wrote:
Junio C Hamano writes:
* tr/merge-recursive-index-only (2013-10-28) 3 commits
- merge-recursive: -Xindex-only to leave worktree unchanged
- merge-recursive: internal flag to avoid touching the worktree
- merge-recursive: remove dead conditional
Instead of simply ignoring the value passed to --depth
option when it is zero or negative, now it is caught
and reported.
This will let people know that they were using the
option incorrectly (as depth<0 should be simply invalid,
and under the hood depth==0 didn't mean 'no depth' or
'no history'
Strings are only marked for translations, the actual lookup is delayed
until inside print_ref_status(), so we only have to check for
porcelain flag once.
While at there, mark some error strings in git push for translation
too.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
I was doing something else a
On 2013-11-05 01:00, Ramsay Jones wrote:
[Note: I have never particularly liked htons, htonl et.al., so adding
these htonll/ntohll functions doesn't thrill me! :-D For example see
this post[1], which echo's my sentiments exactly.]
That post actually contradicts your statement, as it clearly s
git-config used a static match array to hold the matches we want to
unset/replace when using --unset or --replace-all. Use a
variable-sized array instead.
This in particular fixes the symptoms git-svn had when storing large
numbers of svn-remote.*.added-placeholder entries in the config file.
Wh
Jason St. John wrote:
> + Backticks are used around options or commands:
> + `--pretty=oneline`
> + `git rev-list`
You might want to include configuration variables like
`remote.pushdefault` here.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to maj
Enhance 'git for-each-ref' with color formatting options. You can now
use the following format in for-each-ref:
%(color:green)%(refname:short)%(color:reset)
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c | 13 +
Introduce %(upstream:track) to display "[ahead M, behind N]" and
%(upstream:trackshort) to display "=", ">", "<", or "<>"
appropriately (inspired by contrib/completion/git-prompt.sh).
Now you can use the following format in for-each-ref:
%(refname:short)%(upstream:trackshort)
to display refs w
'git branch' shows which branch you are currently on with an '*', but
'git for-each-ref' misses this feature. So, extend its format with
%(HEAD) for the same effect.
Now you can use the following format in for-each-ref:
%(HEAD) %(refname:short)
to display an asterisk next to the current ref.
Hi,
v2 uses the more sane %(color:...) as opposed to %C(...) for changing
the color of the output, as suggested by Junio. Everything else is the
same.
Thanks.
Ramkumar Ramachandra (3):
for-each-ref: introduce %(HEAD) asterisk marker
for-each-ref: introduce %(upstream:track[short])
for-each
33 matches
Mail list logo
