On Jan 16, 2014, at 20:21, Jeff King wrote:
When we run the pager, we always set "LESS=R" to tell the
pager to pass through ANSI colors. On modern versions of
FreeBSD, the system "more" can do the same trick.
[snip]
diff --git a/pager.c b/pager.c
index 90d237e..2303164 100644
--- a/pager.c
+++
On Fri, Jan 17, 2014 at 5:43 AM, Jonathan Nieder wrote:
> Subject: gitignore doc: add global gitignore to synopsis
>
> The gitignore(5) manpage already documents $XDG_CONFIG_HOME/git/ignore
> but it is easy to forget that it exists. Add a reminder to the
> synopsis.
Yes! I knew about the xdg thi
Junio C Hamano writes:
> Alexander Berntsen writes:
>
>> Signed-off-by: Alexander Berntsen
>> ---
>> .gitignore | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/.gitignore b/.gitignore
>> index b5f9def..2905c21 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -240,3 +240,5 @@
Some pagers do not like the ANSI colors we print. It used to
be that one had to opt into the colors, and you would
usually check your pager config at the same time. These
days, we turn on color.ui by default, meaning that some
users may see broken "git log" from the start, before they
have configur
On Jan 16, 2014, at 15:19, Junio C Hamano wrote:
Jonathan Nieder writes:
FWIW this should help on Mac OS X, too. Folks using git on mac
at $DAYJOB have been using the workaround described at
http://mercurial.selenic.com/wiki/CACertificates#Mac_OS_X_10.6_and_higher
so I forgot to report it. :/
The way the code is structured now, we have to repeat
ourselves in fetching the environment variables (which will
get annoying as we add more). Instead, let's use an
argv_array. That removes a lot of the extra conditionals
and makes it easier to add new variables.
It does means we'll leak the me
When we run the pager, we always set "LESS=R" to tell the
pager to pass through ANSI colors. On modern versions of
FreeBSD, the system "more" can do the same trick.
Unlike "less", we may be dealing with various versions of
"more" that do not understand the "R" option, but do know
how to read optio
On Thu, Jan 16, 2014 at 09:35:48PM -0500, Jeff King wrote:
> I can prepare a patch series, but I happily no longer have any antique
> systems to test this kind of stuff on.
Here it is. For those just joining us, the problem is that on some
systems, "git log" out of the box produces ANSI codes whi
On Thu, Jan 16, 2014 at 09:35:48PM -0500, Jeff King wrote:
> I think we should make an effort to set MORE=R on FreeBSD. We can
> perhaps just set it unconditionally, and assume that primitive "more"
> will ignore it. And then assume that "more" will handle colors (either
> because of the R setting
On 01/16/2014 06:21 PM, Jeff King wrote:
On Thu, Jan 16, 2014 at 05:08:14PM -0800, Siddharth Agarwal wrote:
With git-next, where git pull --rebase can print out "fatal: No such
ref: ''" if git pull --rebase is run on branches without an upstream.
This is already fixed in bb3f458 (rebase: fix f
On 01/16/2014 18:32, Jeff King wrote:
Ah, if "more" can handle the colors, then that is preferable.
I do think it would have to be system-specific, though. Unlike "less",
there are many implementations of "more", and quite a lot of them will
probably not support colors. We can make it a build-ti
On Thu, Jan 16, 2014 at 01:55:37PM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
> > On Thu, Jan 16, 2014 at 12:21:04PM -0800, Junio C Hamano wrote:
> >> "W. Trevor King" writes:
> >>> +is only touched when the remote reference does not match the
> >>> +submodule's HEAD (for none-mode u
On Thu, Jan 16, 2014 at 06:29:21PM -0800, Jonathan Nieder wrote:
> > + /*
> > +* We know that "more" does not pass through colors at all.
> > +*/
> > + if (!strcmp(pager, "more"))
> > + return 0;
>
> I seem to remember that on some systems "more" is the name of the
> full-fe
On Thu, Jan 16, 2014 at 06:28:10PM -0800, Yuri wrote:
> On 01/16/2014 18:13, Jeff King wrote:
> >Interesting. I take it that "more" does not pass through ANSI codes at
> >all, then.
>
> Actually, 'more -R' also passes colors on FreeBSD. So maybe you can
> always add -R if PAGER=more on *BSD (any
Hi,
Jeff King wrote:
> Obviously that does not help the "new unchanged user". I think we can
> be smarter about guessing whether the pager can actually handle color,
> based on the name.
[...]
> +++ b/pager.c
> @@ -182,3 +182,38 @@ int check_pager_config(const char *cmd)
[...]
> + /*
> +
On 01/16/2014 18:13, Jeff King wrote:
Interesting. I take it that "more" does not pass through ANSI codes at
all, then.
Actually, 'more -R' also passes colors on FreeBSD. So maybe you can
always add -R if PAGER=more on *BSD (any of them) ? This will fix this
issue.
I know, it is unpleasan
On Thu, Jan 16, 2014 at 03:58:57PM -0800, SH wrote:
> We have a repository which holds lots of shell and perl scripts. We add the
> files to repository (from windows client) with executable permissions (using
> cygwin) but when we pull that repository on another machine (windows or
> linux),
> fi
On Thu, Jan 16, 2014 at 05:08:14PM -0800, Siddharth Agarwal wrote:
> With git-next, where git pull --rebase can print out "fatal: No such
> ref: ''" if git pull --rebase is run on branches without an upstream.
This is already fixed in bb3f458 (rebase: fix fork-point with zero
arguments, 2014-01-0
On Thu, Jan 16, 2014 at 06:02:24PM -0800, Yuri wrote:
> On 01/16/2014 17:47, Jeff King wrote:
> >Are you using "less" as your pager (it is the default in git unless you
> >have set your PAGER environment variable)? If so, do you have the "R"
> >option set to pass through ANSI codes? Git will set t
On 01/16/2014 17:47, Jeff King wrote:
Are you using "less" as your pager (it is the default in git unless you
have set your PAGER environment variable)? If so, do you have the "R"
option set to pass through ANSI codes? Git will set this automatically
in your "LESS" variable if you do not already
On Thu, Jan 16, 2014 at 04:34:01PM -0800, Yuri wrote:
> When I run 'git log' on FreeBSD-9.2, I get output like this:
> ESC[33mcommit 398e78c62fd507a317de7c2abb8e25c9fac7ac9eESC[m
> Merge: 5fb8f6e d2138ba
> ...
>
> ESC is white on black background.
>
> Why ESC[33m aren't expanded by the terminal?
The is_binary flag needs only three values: -1, 0, and 1.
However, we use a whole 32-bit int for it on most systems
(both 32- and 64- bit).
Instead, we can mark it to use only 2 bits. On 32-bit
systems, this lets it end up as part of the bitfield above
(saving 4 bytes). On 64-bit systems, we don't
The middle of the diff_filespec struct contains a mixture of
ints, shorts, and bit-fields, followed by a pointer. On an
x86-64 system with an LP64 or LLP64 data model (i.e., most
of them), the integers and flags end up being padded out by
41 bits to put the pointer at an 8-byte boundary.
After the
The only mention of this field in the code is by some
debugging code which prints it out (and it will always be
zero, since we never touch it otherwise). It was obsoleted
very early on by 25d5ea4 ([PATCH] Redo rename/copy detection
logic., 2005-05-24).
Signed-off-by: Jeff King
---
No savings here
This struct field was obsoleted by be58e70 (diff: unify
external diff and funcname parsing code, 2008-10-05), but we
forgot to remove it.
Signed-off-by: Jeff King
---
8 bytes of our size savings come here...
diffcore.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/diffcore.h b/diffcore.h
i
diff_filespec has a 2-bit "dirty_submodule" field and
defines two flags as macros. Originally these were right
next to each other, but a new field was accidentally added
in between in commit 4682d85. This patch puts the field and
its flags back together.
Using an enum like:
enum {
DIR
I recently came across a repository with a commit containing 100 million
paths in its tree. Cleverly, the whole repo fits into a 1.5K packfile
(can you guess how it was done?). Not so cleverly, running "diff-tree
--root" on that commit uses a large amount of memory. :)
I do not think it is worth o
With git-next, where git pull --rebase can print out "fatal: No such
ref: ''" if git pull --rebase is run on branches without an upstream.
With git at b139ac2589b15d55cd9fa5c6957da44b150d0737, the following
commands demonstrate the problem:
git init repo1
cd repo1
touch a; git add a; git comm
When I run 'git log' on FreeBSD-9.2, I get output like this:
ESC[33mcommit 398e78c62fd507a317de7c2abb8e25c9fac7ac9eESC[m
Merge: 5fb8f6e d2138ba
...
ESC is white on black background.
Why ESC[33m aren't expanded by the terminal? Is this because git prints
an unsupported sequence?
Hex of what gi
Hi
We have a repository which holds lots of shell and perl scripts. We add the
files to repository (from windows client) with executable permissions (using
cygwin) but when we pull that repository on another machine (windows or linux),
files dont have executable permission. Can you please provi
Jonathan Nieder writes:
> FWIW this should help on Mac OS X, too. Folks using git on mac
> at $DAYJOB have been using the workaround described at
> http://mercurial.selenic.com/wiki/CACertificates#Mac_OS_X_10.6_and_higher
> so I forgot to report it. :/
Hmph, is that the same issue, though? Tha
On 16/01/14 22:06, Junio C Hamano wrote:
> Alexander Berntsen writes:
>
>> Signed-off-by: Alexander Berntsen
>> ---
>> .gitignore | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/.gitignore b/.gitignore
>> index b5f9def..2905c21 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@
Junio C Hamano wrote:
> These paths that depend on your choice of the editor and other tools
> can still be managed in your personal .git/info/exclude in the
> meantime.
Or $HOME/.config/git/ignore to not have to make the same setting
in every repository. :)
Maybe it would make sense to add a hi
On Thu, Jan 16, 2014 at 10:18:06PM -, Philip Oakley wrote:
> From: "Junio C Hamano"
> > "W. Trevor King" writes:
> >> + repository. The update mode defaults to 'checkout', but be
>
> nit: s/but be/but can be/ ?
Thanks. Queuing for v5.
Cheers,
Trevor
--
This email may be signed or en
From: "Junio C Hamano"
"W. Trevor King" writes:
[...]
@@ -155,13 +155,31 @@ it contains local modifications.
update::
Update the registered submodules, i.e. clone missing submodules and
- checkout the commit specified in the index of the containing
repository.
- This will make the submo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/01/14 23:06, Junio C Hamano wrote:
> I personally do not mind listing these common ones too much, but if
> I am not mistaken, our policy on this file so far has been that it
> lists build artifacts, and not personal preference (the *.swp
> ent
Hi,
On Fri, 20 Dec 2013, Duy Nguyen wrote:
> On Fri, Dec 20, 2013 at 3:50 AM, Jonathan Nieder wrote:
> > Junio C Hamano wrote:
> >> Jonathan Nieder writes:
> >
> >>> This includes the colon in the translated string, to make it easier to
> >>> remember to keep the non-breaking space before it.
>
Alexander Berntsen writes:
> Signed-off-by: Alexander Berntsen
> ---
> .gitignore | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/.gitignore b/.gitignore
> index b5f9def..2905c21 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -240,3 +240,5 @@
> *.pdb
> /Debug/
> /Release/
> +*~
"W. Trevor King" writes:
>> A naïve expectation from a casual reader of the above would be "The
>> superproject's tree ought to point at the same commit as the tip of
>> the branch used in the submodule (modulo mirroring delays and
>> somesuch),
>
> What is the branch used in the submodule? The
Signed-off-by: Alexander Berntsen
---
.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.gitignore b/.gitignore
index b5f9def..2905c21 100644
--- a/.gitignore
+++ b/.gitignore
@@ -240,3 +240,5 @@
*.pdb
/Debug/
/Release/
+*~
+.*.swp
--
1.8.3.2
--
To unsubscribe from this list:
On Thu, Jan 16, 2014 at 09:02:22PM +, John Keeping wrote:
> On Thu, Jan 16, 2014 at 12:55:21PM -0800, W. Trevor King wrote:
> > On Thu, Jan 16, 2014 at 12:21:04PM -0800, Junio C Hamano wrote:
> > > Not '--checkout'?
> >
> > Oops, will fix in v5.
>
> Shouldn't this also be `--checkout` (backti
From: "Stefan Näwe"
[...]
I'd really like to see 'git help relnotes' working as well...
Stefan
Stefan,
Were you thinking that all the release notes would be quoted verbatim in
the one long man page?
Or that it would be a set of links to each of the individual text files
(see the ifdef::
On Thu, Jan 16, 2014 at 11:43:44AM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
>
> > @@ -817,11 +831,15 @@ cmd_update()
> >
> > displaypath=$(relative_path "$prefix$sm_path")
> >
> > - if test "$update_module" = "none"
> > - then
> > + cas
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
I am planning to tag 1.9-rc0 preview release from the tip of
'master' soonish. Hopefully a few fix-up topics still in flight and
also updates t
On Thu, Jan 16, 2014 at 12:55:21PM -0800, W. Trevor King wrote:
> On Thu, Jan 16, 2014 at 12:21:04PM -0800, Junio C Hamano wrote:
> > "W. Trevor King" writes:
> > > @@ -155,13 +155,31 @@ it contains local modifications.
> > >
> > > update::
> > > Update the registered submodules, i.e. clone m
On Thu, Jan 16, 2014 at 12:21:04PM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
> > @@ -155,13 +155,31 @@ it contains local modifications.
> >
> > update::
> > Update the registered submodules, i.e. clone missing submodules and
> > - checkout the commit specified in the index o
"W. Trevor King" writes:
> On Thu, Jan 16, 2014 at 11:22:52AM -0800, Junio C Hamano wrote:
>> "W. Trevor King" writes:
>>
>> > To preserve the local branch, for situations where we're not on a
>> > detached HEAD.
>> >
>> > Signed-off-by: W. Trevor King
>> > ---
>>
>> This should be a part of
"W. Trevor King" writes:
> The old documentation did not distinguish between cloning and
> non-cloning updates and lacked clarity on which operations would lead
> to detached HEADs, and which would not. The new documentation
> addresses these issues while updating the docs to reflect the changes
On Thu, Jan 16, 2014 at 09:07:22PM +0100, Francesco Pretto wrote:
> 2014/1/16 W. Trevor King :
> > Avoiding useless clones is probably more important than avoiding
> > duplicate "Invalid update mode" messages.
>
> No, it's not duplicate code.
I meant “duplicating the "Invalid update mode" error m
2014/1/16 W. Trevor King :
> Avoiding useless clones is probably more important than avoiding
> duplicate "Invalid update mode" messages.
No, it's not duplicate code. I'll explain, please follow me:
> @@ -803,17 +803,10 @@ cmd_update()
> update_module=$update
>
"W. Trevor King" writes:
> @@ -817,11 +831,15 @@ cmd_update()
>
> displaypath=$(relative_path "$prefix$sm_path")
>
> - if test "$update_module" = "none"
> - then
> + case "$update_module" in
> + none)
> echo "
On Thu, Jan 16, 2014 at 11:22:52AM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
>
> > To preserve the local branch, for situations where we're not on a
> > detached HEAD.
> >
> > Signed-off-by: W. Trevor King
> > ---
>
> This should be a part of some other change that actually change
On Thu, Jan 16, 2014 at 11:18:00AM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
> > @@ -312,7 +317,16 @@ module_clone()
> > echo "gitdir: $rel/$a" >"$sm_path/.git"
> >
> > rel=$(echo $a | sed -e 's|[^/][^/]*|..|g')
> > - (clear_local_git_env; cd "$sm_path" && GIT_WORK_TREE=.
On 01/16/2014 10:03, Jeff King wrote:
We used to print "Reading from helper 'git-remote-https' failed" in this
instance. But in the majority of cases, remote-https has printed a
useful message already to stderr, and the extra line just confused
people. The downside, as you noticed, is that when t
"W. Trevor King" writes:
> To preserve the local branch, for situations where we're not on a
> detached HEAD.
>
> Signed-off-by: W. Trevor King
> ---
This should be a part of some other change that actually changes how
this "git submodule update" checks out the submodule, no?
> t/t7406-submod
On Thu, Jan 16, 2014 at 10:46:36AM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
> > @@ -803,17 +803,10 @@ cmd_update()
> > update_module=$update
> > else
> > update_module=$(git config submodule."$name".update)
> > -
"W. Trevor King" writes:
> The previous code only checked out branches in cmd_add. This commit
> moves the branch-checkout logic into module_clone, where it can be
> shared by cmd_add and cmd_update. I also update the initial checkout
> command to use 'reset' to preserve branches setup during m
"W. Trevor King" writes:
> This avoids the current awkwardness of having either '' or 'checkout'
> for checkout-mode updates, which makes testing for checkout-mode
> updates (or non-checkout-mode updates) easier.
>
> Signed-off-by: W. Trevor King
> ---
> git-submodule.sh | 27 +++---
On Thu, Jan 16, 2014 at 04:27:03AM -0800, Yuri wrote:
> While debugging, I find that remove_junk() deletes all directories
> from under __cxa_finalize.
> Before this, exit(128) is called from recvline_fh ("Debug: Remote
> helper quit.) And this function in turn is called from under
> refs = transp
I have two branches, 'master' and 'work'. 'master' I never work out
of, and I merge changes into it from another SVN repository (I do not
use git-svn, I do this all by hand as real git commits). My 'work'
branch is technically my 'master' in the git-trunk sense, as that is
my personal main line of
Hi All,
Max, you are right, my TK version is 8.4.
I applied the patch and it now works perfectly.
Thanks!!
Benoît
On Tue, Jan 14, 2014 at 5:58 PM, Max Kirillov wrote:
> Since 918dbf58, git-gui crashes if started with Tk 8.4. The reason is that
> tk < 8.5 does not support -stretch option for pa
On 16 Jan 2014, at 15:45, Pete Wyckoff wrote:
> Oh cool, that helps a lot. P4 is just broken here, so we can get
> away with being a bit sloppy in git. I'll try just pretending
> "empty symlinks" are not in the repo. Hopefully you'll have a
> future commit in your p4 repo that brings back bn.
dam...@iwi.me wrote on Thu, 16 Jan 2014 14:46 +0100:
>
> On 16 Jan 2014, at 14:08, Pete Wyckoff wrote:
>
> > dam...@iwi.me wrote on Wed, 15 Jan 2014 09:56 +0100:
> >> p4 fstat //depot/openssl/0.9.8j/openssl/include/openssl/bn.h@59702
> >> ... depotFile //depot/openssl/0.9.8j/openssl/include/op
On 16 Jan 2014, at 14:08, Pete Wyckoff wrote:
> dam...@iwi.me wrote on Wed, 15 Jan 2014 09:56 +0100:
>> p4 fstat //depot/openssl/0.9.8j/openssl/include/openssl/bn.h@59702
>> ... depotFile //depot/openssl/0.9.8j/openssl/include/openssl/bn.h
>> ... headAction edit
>> ... headType symlink
>> ...
dam...@iwi.me wrote on Wed, 15 Jan 2014 09:56 +0100:
> p4 fstat //depot/openssl/0.9.8j/openssl/include/openssl/bn.h@59702
> ... depotFile //depot/openssl/0.9.8j/openssl/include/openssl/bn.h
> ... headAction edit
> ... headType symlink
> ... headTime 1237906419
> ... headRev 2
> ... headChange 597
On one of my FreeBSD systems I can't clone github through https URL.
It only says "Cloning into 'MyProject'...", writes some files, but then
deletes everything, without printing anything else at all. Exit code is 128.
Replacing https:// with git:// makes it work fine.
While debugging, I find t
On 12/16/2013 12:52 PM, Kirill Likhodedov wrote:
> I received one more complaint for this issue, and now it appears in a public
> repository https://github.com/spray/spray
>
> To reproduce:
>
> # git clone https://github.com/spray/spray
> # cd spray
> # git log --no-walk --tags --pretty="%H %d
67 matches
Mail list logo
