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])
'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.
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 artag...@gmail.com
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c
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 with terse
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
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.
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
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 pclo...@gmail.com
---
I was
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 depth0 should be simply invalid,
and under the hood depth==0 didn't mean 'no depth' or
'no history'
On 11/02/2013 12:09 AM, Thomas Rast wrote:
Junio C Hamano gits...@pobox.com 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
Am 08.11.2013 18:08, schrieb Junio C Hamano:
Karsten Blees karsten.bl...@gmail.com 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
Ken Tanzer ken.tan...@gmail.com 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
Jason St. John jstj...@purdue.edu 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
Jason St. John jstj...@purdue.edu 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
Am 12.11.2013 23:20, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de 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
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
Junio C Hamano gits...@pobox.com 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
Ramkumar Ramachandra artag...@gmail.com 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.
Jens Lehmann jens.lehm...@web.de 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
Junio C Hamano gits...@pobox.com writes:
Ramkumar Ramachandra artag...@gmail.com 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
Jason St. John jstj...@purdue.edu 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
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:
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
From: Junio C Hamano gits...@pobox.com
To: Ken Tanzer ken.tan...@gmail.com
Sent: Wednesday, November 13, 2013 5:04 PM
Ken Tanzer ken.tan...@gmail.com 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
On Wed, Nov 13, 2013 at 5:19 AM, Thomas Rast t...@thomasrast.ch 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
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 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 memory
[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
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?
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
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 =
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.
Sitaram Chamarty sitar...@gmail.com 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
33 matches
Mail list logo
