* Re: CRLF problems with Git on Win32
From: Peter Karlsson @ 2008-01-10 13:28 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Linus Torvalds, J. Bruce Fields, Steffen Prohaska,
Robin Rosenberg, Jeff King, Git Mailing List, msysGit
In-Reply-To: <alpine.LSU.1.00.0801101155140.31053-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org>
Johannes Schindelin:
> I cannot help but wonder what exactly you wanted to achieve with this
> provably bogus statement, other than provoking flames. I hereby
> refuse to insult you for it.
I meant to say that any software that claims to be Windows software
should handle, and produce, CRLF line breaks in text files. Whether it
also supports Unix (LF) or old Mac (CR) line breaks is up to it, but if
it is a Windows program, it should do CRLF, as that is the convention
(inherited from MS-DOS, which inherited it from CP/M).
> > True. And I run git a lot on a Novell disk share, which doesn't exactly
> > help improve the speed either :-)
> Don't do that, then.
I have to. Otherwise the compile server can't see the files (this is
not for the project that at in the start of the thread, this is what I
use to work around that my employer's choice of version control systems
could be better).
> > Windows has CRLF line endings. Just deal with it.
> No, I will not just deal with it.
Me neither, that is why I expect the software to do it for me.
Thinking of text files as a stream of bytes is so 1900s. In the 2000s
we should think of text files as a stream of characters. How these
characters are represented is up to each system that wants it. I see no
problem with storing text files as UTF-32 internally (disk is cheap).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Revert git push
From: Markus Korber @ 2008-01-10 13:15 UTC (permalink / raw)
To: git
Hi,
I've got two local git repositories, linux and mplayer, where I push to
from a local directory. Now I accidentally pushed from mplayer into the
linux repository (via a not updated URL[1]). Is it somehow possible to
revert this push if nobody has pushed something since my last pull from
the linux repository?
(Or can I just copy the .git/objects/ directory over to the repository?)
,----[ .git/remotes/mplayer [1]]
| URL: /prj/gitroot/linux
| Push: +master:master
`----
,----[ git push mplayer ]
| updating 'refs/heads/master'
| from 94545baded0bfbabdc30a3a4cb48b3db479dd6ef
| to 9085d919f7954ad629447157f054e55230513936
| Generating pack...
| Done counting 3240 objects.
| Deltifying 3240 objects...
| 100% (3240/3240) done
| Writing 3240 objects...
| 100% (3240/3240) done
| Total 3240 (delta 774), reused 0 (delta 0)
| refs/heads/master: 94545baded0bfbabdc30a3a4cb48b3db479dd6ef -> 9085d919f7954ad629447157f054e55230513936
`----
Regards,
Markus Korber
^ permalink raw reply
* [PATCH] gitweb: Change feeds from commit to commitdiff output.
From: Florian La Roche @ 2008-01-10 13:09 UTC (permalink / raw)
To: git, gitster
[PATCH] gitweb: Change feeds from commit to commitdiff output.
Change feeds from displaying the commit to displaying the commitdiff
output. This way the patches are shown directly and code review is
done more easily via watching feeds.
Signed-off-by: Florian La Roche <laroche@redhat.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6256641..0db83c0 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5566,7 +5566,7 @@ XML
or next;
# print element (entry, item)
- my $co_url = href(-full=>1, action=>"commit", hash=>$commit);
+ my $co_url = href(-full=>1, action=>"commitdiff", hash=>$commit);
if ($format eq 'rss') {
print "<item>\n" .
"<title>" . esc_html($co{'title'}) . "</title>\n" .
--
1.5.3.8
^ permalink raw reply related
* Re: [PATCH] bundle, fast-import: detect write failure
From: Jim Meyering @ 2008-01-10 13:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git list
In-Reply-To: <alpine.LSU.1.00.0801101234580.31053@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Are you aware what this code does? It writes a ".keep" file. Whose
> purpose is to _exist_, and whose purpose is fulfilled, even if the write
> or the push-back did not succeed.
Hi,
I do see what you mean.
If the write is not necessary, then perhaps you would prefer a comment
documenting that failures of the write and following close are ignorable.
And add a '(void)' stmt prefix, to tell compilers that ignoring the
return value is deliberate.
However, even if it's not technically required to fail at that point,
if it were my choice, I'd prefer to know when a .keep file whose
contents are unimportant just happens to reside on a bad spot on my
disk. I/O errors should never be ignored.
> I could not care less what the manual says. What is important is if the
> defensive programming is done mindlessly, and therefore can fail so not
> gracefully.
On the other hand, if that write failure is truly ignorable,
a mindless minimalist :-) might argue that it's best just to
omit the syscall.
^ permalink raw reply
* Re: [PATCH] bundle, fast-import: detect write failure
From: Johannes Schindelin @ 2008-01-10 12:37 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <87myrdhnn5.fsf@rho.meyering.net>
Hi,
On Thu, 10 Jan 2008, Jim Meyering wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I recently read an article which got me thinking about close(). The
> > author maintained that many mistakes are done by being overzealously
> > defensive; die()ing in case of a close() failure (when open()
> > succeeded!) might be just wrong.
>
> No. Whether open succeeded is a separate matter. Avoiding an unreported
> write (or close-writable-fd) failure is not being "overzealously
> defensive."
Are you aware what this code does? It writes a ".keep" file. Whose
purpose is to _exist_, and whose purpose is fulfilled, even if the write
or the push-back did not succeed.
I could not care less what the manual says. What is important is if the
defensive programming is done mindlessly, and therefore can fail so not
gracefully.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] bundle, fast-import: detect write failure
From: Jim Meyering @ 2008-01-10 12:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git list
In-Reply-To: <alpine.LSU.1.00.0801101204120.31053@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> However, you also have this:
>
>> - close(keep_fd);
>> + if (close(keep_fd))
>> + die("failed to write keep file");
Yes. I mentioned that in the commit log:
* bundle.c (create_bundle): Die upon write failure.
* fast-import.c (keep_pack): Die upon write or close failure.
But even the summary is accurate if you interpret
"write" not as the syscall, but as the semantic
push-data-through-OS-to-disk operation.
> I recently read an article which got me thinking about close(). The
> author maintained that many mistakes are done by being overzealously
> defensive; die()ing in case of a close() failure (when open() succeeded!)
> might be just wrong.
No. Whether open succeeded is a separate matter.
Avoiding an unreported write (or close-writable-fd) failure is not
being "overzealously defensive."
>From "man 2 close",
-------------
NOTES
Not checking the return value of close() is a common but nevertheless
serious programming error. It is quite possible that errors on a pre-
vious write(2) operation are first reported at the final close(). Not
checking the return value when closing the file may lead to silent loss
of data. This can especially be observed with NFS and with disk quota.
-------------
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Marco Costalba @ 2008-01-10 12:18 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nicolas Pitre, Sam Vilain, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LSU.1.00.0801101210031.31053@racer.site>
On Jan 10, 2008 1:12 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 10 Jan 2008, Marco Costalba wrote:
>
> > - Remove #include <zlib.h> from cache.h and substitute with #include
> > "compress.h"
>
> No. We will always need zlib for compatibility. You cannot just replace
> zlib usage in git.
>
Ok. This was just to check what is broken by removing zlib.h so that
I'm sure to renaming all the zlib related stuff.
But I agree this is most a development detail and I can do this just
in my private tree to help me hacking the patches.
Thanks
Marco
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Johannes Schindelin @ 2008-01-10 12:12 UTC (permalink / raw)
To: Marco Costalba
Cc: Nicolas Pitre, Sam Vilain, Git Mailing List, Junio C Hamano
In-Reply-To: <e5bfff550801100345i20cb3030mf04a11d610fda6f7@mail.gmail.com>
Hi,
On Thu, 10 Jan 2008, Marco Costalba wrote:
> - Remove #include <zlib.h> from cache.h and substitute with #include
> "compress.h"
No. We will always need zlib for compatibility. You cannot just replace
zlib usage in git.
> - Add #include <zlib.h> where it is "really" intended as example
> archive-zip.c
We have a long tradition to have the system includes in cache.h.
Besides, if you have "compress.h" included in cache.h, which in turn has
to include "zlib.h", what is the use of putting it also in archive-zip.c?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] bundle, fast-import: detect write failure
From: Johannes Schindelin @ 2008-01-10 12:05 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <874pdmhxha.fsf@rho.meyering.net>
Hi,
On Thu, 10 Jan 2008, Jim Meyering wrote:
> I noticed some unchecked writes. This fixes them.
Thank you.
However, you also have this:
> - close(keep_fd);
> + if (close(keep_fd))
> + die("failed to write keep file");
I recently read an article which got me thinking about close(). The
author maintained that many mistakes are done by being overzealously
defensive; die()ing in case of a close() failure (when open() succeeded!)
might be just wrong.
Ciao,
Dscho
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Johannes Schindelin @ 2008-01-10 11:57 UTC (permalink / raw)
To: Peter Karlsson
Cc: Junio C Hamano, Linus Torvalds, J. Bruce Fields, Steffen Prohaska,
Robin Rosenberg, Jeff King, Git Mailing List, msysGit
In-Reply-To: <Pine.LNX.4.64.0801101023380.11922-Hh8n7enkEC8qi7mQTfpNuw@public.gmane.org>
Hi,
On Thu, 10 Jan 2008, Peter Karlsson wrote:
> Johannes Schindelin:
>
> > The problem is that MinGW behaves sanely, i.e. it does not output CRLF
> > but only LF.
>
> Well, that is broken, since the convention on Windows is to use CRLF.
I cannot help but wonder what exactly you wanted to achieve with this
provably bogus statement, other than provoking flames. I hereby refuse to
insult you for it.
> > - Windows is already slow. So slow that it is not even funny.
> > Granted, if you use Windows daily, git on MinGW seems snappy, but if
> > you come from Linux, it is slow as hell.
>
> True. And I run git a lot on a Novell disk share, which doesn't exactly
> help improve the speed either :-)
Don't do that, then.
I mean, git is _distributed_. Not like there is no way out because your
"server" is on a disk share.
> Windows has CRLF line endings. Just deal with it.
No, I will not just deal with it.
Ciao,
Dscho
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Marco Costalba @ 2008-01-10 11:45 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin, Sam Vilain, Git Mailing List, Junio C Hamano
In-Reply-To: <e5bfff550801092255wc852252m9086567a88b1ae99@mail.gmail.com>
On Jan 10, 2008 7:55 AM, Marco Costalba <mcostalba@gmail.com> wrote:
>
> [1] where inflate() is called:
>
> -inflate_it() in builtin-apply.c
> -check_pack_inflate() in builtin-pack-objects.c
> -get_data() in builtin-unpack-objects.c
> -fwrite_sha1_file() in http-push.c and http-walker.c [mmm interesting
> same function in two files, also the signature and the contents seems
> the same....]
> -unpack_entry_data() in index-pack.c
> -unpack_sha1_header(), unpack_sha1_rest(), get_size_from_delta(),
> unpack_compressed_entry, write_sha1_from_fd() in sha1_file.c
>
Looking at the git sources I have found that zip routines are
candidate for a cleaning up, as example the more or less very similar
lines of code are repeated many times in git files:
memset(&stream, 0, sizeof(stream));
deflateInit(&stream, pack_compression_level);
maxsize = deflateBound(&stream, size);
out = xmalloc(maxsize);
stream.next_out = out;
stream.avail_out = maxsize;
So what I'm planning to do to test with different algorithms is first
a cleanup work that is more or less the following
- Remove #include <zlib.h> from cache.h and substitute with #include
"compress.h"
- Add #include <zlib.h> where it is "really" intended as example archive-zip.c
- Rename inflate()/deflate() and other zlib calls with corresponding
zlib_inflate()
zlib_deflate()
and declared in compress.h
- Define zlib_inflate() and friends as simple wrappers to
corresponding zlib function
- Test if everything is ok (should be only code shuffling/renaming until now)
- Start cleaning up as example adding a do_deflateInit() that wraps
all the code I have reported above and that involves deflateInit()
- When compression routines are cleaned up add new functions
do_inflate(), do_deflate() instead of zlib_* ones that wrap the
compression alghorithm dispatching logic.
Dispatching could be choose in different ways going from
- compile time (at #define level)
- config (some configuration value stored in some global variable)
- dynamic (at run time, with no configuration needed, I have some
ideas on this ;-)
Comments?
Thanks
Marco
^ permalink raw reply
* Re: gmail smtp server and git-send-mail. Is this combination working?
From: Paolo Ciarrocchi @ 2008-01-10 11:17 UTC (permalink / raw)
To: Douglas Stockwell; +Cc: git
In-Reply-To: <fm1h7t$nnr$1@ger.gmane.org>
On Jan 9, 2008 5:06 AM, Douglas Stockwell <doug@11011.net> wrote:
> Paolo Ciarrocchi wrote:
> > " Mailing off a set of patches to a mailing list can be quite neatly
> > done by git-send-email.
> > One of the problems you may encounter there is figuring out which machine
> > is going to send your mail.
> > I tried smtp.gmail.com, but that one requires tls and a password,
> > and git-send-email could not handle that "
> >
> > From http://git.or.cz/gitwiki/GitTips.
> >
> > Is this statemant still correct ?
> > Is msmtp the only solution for using git-send-mail with gmail? (tls +
> > autentication).
>
> No, as of 34cc60ce2b48f6037997543ddbab1ed9903df4a8 you can use SSL and
> SMTP-Auth.
>
> [sendemail]
> smtpserver = smtp.gmail.com
> smtpuser = <user>@gmail.com
> smtppass = <password>
> smtpssl = true
>
> Can you suggest changes to the documentation if these options are unclear?
I got confuse by the ssl part in the name of the option,
I was looking and grepping for tls.
As I wrote in my previous email I think it's worth to add this very useful
information into the wiki as well.
Thanks.
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: gmail smtp server and git-send-mail. Is this combination working?
From: Paolo Ciarrocchi @ 2008-01-10 11:13 UTC (permalink / raw)
To: Douglas Stockwell; +Cc: git
In-Reply-To: <fm44ck$299$1@ger.gmane.org>
On Jan 10, 2008 4:45 AM, Douglas Stockwell <doug@11011.net> wrote:
> Paolo Ciarrocchi wrote:
>
> > Well, it would be nice to add this information to the wiki, it's still
> > mentioning
> > that you require an external program for supporting the TLS connection.
> > I'll do that when I'll get my box working with the configuration you suggested,
> >
> > What I'm getting at the moment is:
> > paolo@paolo-desktop:~/git$ git-send-email -compose -to
> > paolo.ciarrocchi@gmail.com /home/paolo/Desktop/patch/
> > snip
> > snip
> > Can't locate Net/SMTP/SSL.pm in @INC (@INC contains:
>
> As indicated, the module you need is Net::SMTP::SSL, if there is no
> package for ubuntu, you can install it using CPAN:
>
> perl -MCPAN -e 'install Net::SMTP::SSL'
Thank you. I'll try that and update the wiki with the information you provided
as soon as I have git-send-email working properly :-)
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: Odd number of elements in anonymous hash
From: Dennis Schridde @ 2008-01-10 11:04 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20080110083846.GA15047@soma>
[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]
Am Donnerstag, 10. Januar 2008 09:38:46 schrieb Eric Wong:
> Dennis Schridde <devurandom@gmx.net> wrote:
> > Am Dienstag, 8. Januar 2008 18:21:55 schrieb Junio C Hamano:
> > > Dennis Schridde <devurandom@gmx.net> writes:
> > > > Hello!
> > > >
> > > > I am getting "Odd number of elements in anonymous hash at
> > > > /usr/bin/git-svn line 1760." (normal output, no warning/error) during
> > > > git-svn-clone. I am using git version 1.5.4.rc2.
> > > >
> > > > Line 1760 is this (with context, marked with '!!'):
> > > > # see if we have it in our config, first:
> > > > eval {
> > > > my $section = "svn-remote.$self->{repo_id}";
> > > > !! $svnsync = {
> > > > url => tmp_config('--get', "$section.svnsync-url"),
> > > > uuid => tmp_config('--get', "$section.svnsync-uuid"),
> > > > }
> > > > };
> > > >
> > > > The commandline was "git svn
> > > > clone --authors-file=/var/git/org.gna.warzone.git/authors
> > > > --use-svnsync-props --stdlayout file:///var/svn/warzone2100/
> > > > org.gna.warzone.git/"
> > > >
> > > > I assume this is some kind of bug?
> > >
> > > More than one svn-remote.$your_repo.svnsync-{url,uuid}?
> >
> > PS: It doesn't happen for every revision and the folders (and thus
> > config) were empty before. The config doesn't list any "svnsync-*" during
> > the import process.
>
> Can you look in .git/svn/.metadata for the svnsync-* values? Thanks.
>
> I downloaded your repository and couldn't reproduce it locally.
This is the file left after the segfault from the other mail:
---
[svn-remote "svn"]
reposRoot = file:///var/svn/warzone2100
uuid = 4a71c877-e1ca-e34f-864e-861f7616d084
branches-maxRev = 14
tags-maxRev = 14
svnsync-uuid = 4a71c877-e1ca-e34f-864e-861f7616d084\n
svnsync-url = http://svn.gna.org/svn/warzone
[svn-remote "tags/1.10a.12"]
reposRoot = file:///var/svn/warzone2100
uuid = 4a71c877-e1ca-e34f-864e-861f7616d084
---
I will post the whole file asap. (I think recompiling git,svn,perl with
CFLAGS=-g and not striping the binary magically solves the problem, at least
it seemed to when I tried to create a backtrace.)
--Dennis
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Peter Karlsson @ 2008-01-10 9:25 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Linus Torvalds, J. Bruce Fields, Steffen Prohaska,
Robin Rosenberg, Jeff King, Git Mailing List, msysGit
In-Reply-To: <alpine.LSU.1.00.0801091041570.31053-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org>
Johannes Schindelin:
> The problem is that MinGW behaves sanely, i.e. it does not output
> CRLF but only LF.
Well, that is broken, since the convention on Windows is to use CRLF.
> - Windows is already slow. So slow that it is not even funny. Granted,
> if you use Windows daily, git on MinGW seems snappy, but if you come
> from Linux, it is slow as hell.
True. And I run git a lot on a Novell disk share, which doesn't exactly
help improve the speed either :-)
> - Some tools ported to Windows from Unix do not like CRs.
Those tools are broken, for the same reason as above.
Windows has CRLF line endings. Just deal with it.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [PATCH/resend] Add color.ui variable which globally enables colorization if set
From: Matthias Kestenholz @ 2008-01-10 9:03 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This patch introduces the color.ui variable which globally enables colorization.
More specific colorization variables like color.branch, color.diff etc. take
precedence.
color.ui is not respected by git add --interactive and git svn yet.
Signed-off-by: Matthias Kestenholz <mk@spinlock.ch>
---
Documentation/config.txt | 7 +++++++
builtin-branch.c | 10 +++++++---
builtin-commit.c | 4 ++++
builtin-diff.c | 5 +++++
builtin-log.c | 17 +++++++++++++++++
color.c | 12 ++++++++++++
color.h | 11 +++++++++++
diff.c | 6 +++---
diff.h | 1 +
wt-status.c | 6 +++---
10 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1b6d6d6..b55f3b4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -439,6 +439,13 @@ color.status.<slot>::
commit.template::
Specify a file to use as the template for new commit messages.
+color.ui::
+ When set to `always`, always use colors in all git commands which
+ are capable of colored output. When false (or `never`), never. When
+ set to `true` or `auto`, use colors only when the output is to the
+ terminal. When more specific variables of color.* are set, they always
+ take precedence over this setting. Defaults to false.
+
diff.autorefreshindex::
When using `git diff` to compare with work tree
files, do not consider stat-only change as changed.
diff --git a/builtin-branch.c b/builtin-branch.c
index 089cae5..9a1eb21 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -31,7 +31,7 @@ static unsigned char head_sha1[20];
static int branch_track = 1;
-static int branch_use_color;
+static int branch_use_color = -1;
static char branch_colors[][COLOR_MAXLEN] = {
"\033[m", /* reset */
"", /* PLAIN (normal) */
@@ -76,12 +76,12 @@ static int git_branch_config(const char *var, const char *value)
if (!strcmp(var, "branch.autosetupmerge"))
branch_track = git_config_bool(var, value);
- return git_default_config(var, value);
+ return git_color_default_config(var, value);
}
static const char *branch_get_color(enum color_branch ix)
{
- if (branch_use_color)
+ if (branch_use_color > 0)
return branch_colors[ix];
return "";
}
@@ -585,6 +585,10 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
};
git_config(git_branch_config);
+
+ if (branch_use_color == -1)
+ branch_use_color = git_use_color_default;
+
track = branch_track;
argc = parse_options(argc, argv, options, builtin_branch_usage, 0);
if (!!delete + !!rename + !!force_create > 1)
diff --git a/builtin-commit.c b/builtin-commit.c
index 73f1e35..ba60cfa 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -7,6 +7,7 @@
#include "cache.h"
#include "cache-tree.h"
+#include "color.h"
#include "dir.h"
#include "builtin.h"
#include "diff.h"
@@ -640,6 +641,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
git_config(git_status_config);
+ if (wt_status_use_color == -1)
+ wt_status_use_color = git_use_color_default;
+
argc = parse_and_validate_options(argc, argv, builtin_status_usage);
index_file = prepare_index(argc, argv, prefix);
diff --git a/builtin-diff.c b/builtin-diff.c
index 29365a0..77a9c9a 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -4,6 +4,7 @@
* Copyright (c) 2006 Junio C Hamano
*/
#include "cache.h"
+#include "color.h"
#include "commit.h"
#include "blob.h"
#include "tag.h"
@@ -229,6 +230,10 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
prefix = setup_git_directory_gently(&nongit);
git_config(git_diff_ui_config);
+
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
init_revisions(&rev, prefix);
rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
diff --git a/builtin-log.c b/builtin-log.c
index dcc9f81..880da94 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -5,6 +5,7 @@
* 2006 Junio Hamano
*/
#include "cache.h"
+#include "color.h"
#include "commit.h"
#include "diff.h"
#include "revision.h"
@@ -235,6 +236,10 @@ int cmd_whatchanged(int argc, const char **argv, const char *prefix)
struct rev_info rev;
git_config(git_log_config);
+
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
init_revisions(&rev, prefix);
rev.diff = 1;
rev.simplify_history = 0;
@@ -307,6 +312,10 @@ int cmd_show(int argc, const char **argv, const char *prefix)
int i, count, ret = 0;
git_config(git_log_config);
+
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
init_revisions(&rev, prefix);
rev.diff = 1;
rev.combine_merges = 1;
@@ -367,6 +376,10 @@ int cmd_log_reflog(int argc, const char **argv, const char *prefix)
struct rev_info rev;
git_config(git_log_config);
+
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
init_revisions(&rev, prefix);
init_reflog_walk(&rev.reflog_info);
rev.abbrev_commit = 1;
@@ -395,6 +408,10 @@ int cmd_log(int argc, const char **argv, const char *prefix)
struct rev_info rev;
git_config(git_log_config);
+
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
init_revisions(&rev, prefix);
rev.always_show_header = 1;
cmd_log_init(argc, argv, prefix, &rev);
diff --git a/color.c b/color.c
index 7f66c29..09b81fe 100644
--- a/color.c
+++ b/color.c
@@ -3,6 +3,8 @@
#define COLOR_RESET "\033[m"
+int git_use_color_default = 0;
+
static int parse_color(const char *name, int len)
{
static const char * const color_names[] = {
@@ -143,6 +145,16 @@ int git_config_colorbool(const char *var, const char *value, int stdout_is_tty)
return 0;
}
+int git_color_default_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "color.ui")) {
+ git_use_color_default = git_config_colorbool(var, value, -1);
+ return 0;
+ }
+
+ return git_default_config(var, value);
+}
+
static int color_vfprintf(FILE *fp, const char *color, const char *fmt,
va_list args, const char *trail)
{
diff --git a/color.h b/color.h
index ff63513..ecda556 100644
--- a/color.h
+++ b/color.h
@@ -4,6 +4,17 @@
/* "\033[1;38;5;2xx;48;5;2xxm\0" is 23 bytes */
#define COLOR_MAXLEN 24
+/*
+ * This variable stores the value of color.ui
+ */
+extern int git_use_color_default;
+
+
+/*
+ * Use this instead of git_default_config if you need the value of color.ui.
+ */
+int git_color_default_config(const char *var, const char *value);
+
int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
void color_parse(const char *var, const char *value, char *dst);
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
diff --git a/diff.c b/diff.c
index b18c140..d6f23c7 100644
--- a/diff.c
+++ b/diff.c
@@ -20,7 +20,7 @@
static int diff_detect_rename_default;
static int diff_rename_limit_default = 100;
-static int diff_use_color_default;
+int diff_use_color_default = -1;
static const char *external_diff_cmd_cfg;
int diff_auto_refresh_index = 1;
@@ -189,7 +189,7 @@ int git_diff_basic_config(const char *var, const char *value)
}
}
- return git_default_config(var, value);
+ return git_color_default_config(var, value);
}
static char *quote_two(const char *one, const char *two)
@@ -2048,7 +2048,7 @@ void diff_setup(struct diff_options *options)
options->change = diff_change;
options->add_remove = diff_addremove;
- if (diff_use_color_default)
+ if (diff_use_color_default > 0)
DIFF_OPT_SET(options, COLOR_DIFF);
else
DIFF_OPT_CLR(options, COLOR_DIFF);
diff --git a/diff.h b/diff.h
index 073d5cb..8e73f07 100644
--- a/diff.h
+++ b/diff.h
@@ -174,6 +174,7 @@ extern void diff_unmerge(struct diff_options *,
extern int git_diff_basic_config(const char *var, const char *value);
extern int git_diff_ui_config(const char *var, const char *value);
+extern int diff_use_color_default;
extern void diff_setup(struct diff_options *);
extern int diff_opt_parse(struct diff_options *, const char **, int);
extern int diff_setup_done(struct diff_options *);
diff --git a/wt-status.c b/wt-status.c
index c0c2472..0dfc909 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -9,7 +9,7 @@
#include "diffcore.h"
int wt_status_relative_paths = 1;
-int wt_status_use_color = 0;
+int wt_status_use_color = -1;
static char wt_status_colors[][COLOR_MAXLEN] = {
"", /* WT_STATUS_HEADER: normal */
"\033[32m", /* WT_STATUS_UPDATED: green */
@@ -40,7 +40,7 @@ static int parse_status_slot(const char *var, int offset)
static const char* color(int slot)
{
- return wt_status_use_color ? wt_status_colors[slot] : "";
+ return wt_status_use_color > 0 ? wt_status_colors[slot] : "";
}
void wt_status_prepare(struct wt_status *s)
@@ -409,5 +409,5 @@ int git_status_config(const char *k, const char *v)
wt_status_relative_paths = git_config_bool(k, v);
return 0;
}
- return git_default_config(k, v);
+ return git_color_default_config(k, v);
}
--
1.5.4.rc2.68.ge708a-dirty
^ permalink raw reply related
* Re: [Fwd: [FORCEDETH]: Fix reversing the MAC address on suspend.]
From: David Woodhouse @ 2008-01-10 9:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, B.Steinbrink, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.1.00.0801091934160.3148@woody.linux-foundation.org>
On Wed, 2008-01-09 at 19:47 -0800, Linus Torvalds wrote:
> If you can make your editor/mail setup (I assume it's Gnu "bovine
> excrement" Emacs, since you say that you use your editor for email) use
> utf8 natively for saving any results, then all your problems should go
> away.
Careful with that approach. You don't necessarily want to convert the
patch; only the author info and the comments. I think git-mailinfo does
the right thing.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] bundle, fast-import: detect write failure
From: Pierre Habouzit @ 2008-01-10 9:17 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <874pdmhxha.fsf@rho.meyering.net>
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]
On Thu, Jan 10, 2008 at 08:54:25AM +0000, Jim Meyering wrote:
>
> I noticed some unchecked writes. This fixes them.
Yeah, while we're at it, compiling git with -D_FORTIFY_SOURCE=2 isn't
really brilliant right now, there are quite many places with unchecked
writes, fwrites and chdirs.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Pierre Habouzit @ 2008-01-10 9:16 UTC (permalink / raw)
To: Sam Vilain
Cc: Git Mailing List, Johannes Schindelin, Marco Costalba,
Junio C Hamano
In-Reply-To: <4785A6DB.3080007@vilain.net>
[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]
On Thu, Jan 10, 2008 at 07:02:39AM +0000, Sam Vilain wrote:
> Sam Vilain wrote:
> > I do really like LZOP as far as compression algorithms go. It seems a
> > lot faster for not a huge loss in ratio.
>
> Coincidentally, I read this today on an algorithm (LZMA - same as 7zip)
> which is very slow to compress, high ratio but quick decompression:
>
> http://use.perl.org/~acme/journal/35330
>
> Which sounds excellent for squeezing those "archive packs" into even
> more ridiculously tiny spaces.
Well, lzma is excellent for *big* chunks of data, but not that impressive for
small files:
$ ll git.c git.c.gz git.c.lzma git.c.lzop
-rw-r--r-- 1 madcoder madcoder 12915 2008-01-09 13:47 git.c
-rw-r--r-- 1 madcoder madcoder 4225 2008-01-10 10:00 git.c.gz
-rw-r--r-- 1 madcoder madcoder 4094 2008-01-10 10:00 git.c.lzma
-rw-r--r-- 1 madcoder madcoder 5068 2008-01-10 09:59 git.c.lzop
And lzma performs really bad if you have few memory available. The "big" secret
of lzma is that it basically works with a huge window to check for repetitive
data, and even decompression needs quite a fair amount of memory, making it a
really bad choice for git IMNSHO.
Though I don't agree with you (and some others) about the fact that gzip is
fast enough. It's clearly a bottleneck in many log related commands where you
would expect it to be rather IO bound than CPU bound. LZO seems like a fairer
choice, especially since what it makes gain is basically the compression of the
biggest blobs, aka the delta chains heads. It's really unclear to me if we
really gain in compressing the deltas, trees, and other smallish informations.
And when it comes to times, for a big file enough to give numbers, here are the
decompression times (best of 10 runs, smaller is better, second number is the
size of the packed data, original data was 7.8Mo):
* lzma: 0.374s (2.2Mo)
* gzip: 0.127s (2.9Mo)
* lzop: 0.053s (3.2Mo)
For a 300k original file:
* lzma: 0.022s (124Ko)
* gzip: 0.008s (144Ko)
* lzop: 0.004s (156Ko) /* most of the samples were actually 0.005 */
What is obvious to me is that lzop seems to take 10% more space than gzip,
while being around 1.5 to 2 times faster. Of course this is very sketchy and a
real test with git will be better.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Signing by StGIT broken
From: Karl Hasselström @ 2008-01-10 7:42 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Catalin Marinas, git
In-Reply-To: <1199933596.21499.15.camel@dv>
On 2008-01-09 21:53:16 -0500, Pavel Roskin wrote:
> "stg edit --sign" is not working anymore. It was working in version
> 0.14.
Thanks for the report and the detailed analysis. I'll write a test and
fix it (but not quite immediately, so feel free to beat me to it).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] bundle, fast-import: detect write failure
From: Jim Meyering @ 2008-01-10 8:54 UTC (permalink / raw)
To: git list
I noticed some unchecked writes. This fixes them.
* bundle.c (create_bundle): Die upon write failure.
* fast-import.c (keep_pack): Die upon write or close failure.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
bundle.c | 6 +++---
fast-import.c | 5 +++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/bundle.c b/bundle.c
index be204d8..316aa74 100644
--- a/bundle.c
+++ b/bundle.c
@@ -320,9 +320,9 @@ int create_bundle(struct bundle_header *header, const char *path,
for (i = 0; i < revs.pending.nr; i++) {
struct object *object = revs.pending.objects[i].item;
if (object->flags & UNINTERESTING)
- write(rls.in, "^", 1);
- write(rls.in, sha1_to_hex(object->sha1), 40);
- write(rls.in, "\n", 1);
+ write_or_die(rls.in, "^", 1);
+ write_or_die(rls.in, sha1_to_hex(object->sha1), 40);
+ write_or_die(rls.in, "\n", 1);
}
if (finish_command(&rls))
return error ("pack-objects died");
diff --git a/fast-import.c b/fast-import.c
index 74597c9..82e9161 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -878,8 +878,9 @@ static char *keep_pack(char *curr_index_name)
keep_fd = open(name, O_RDWR|O_CREAT|O_EXCL, 0600);
if (keep_fd < 0)
die("cannot create keep file");
- write(keep_fd, keep_msg, strlen(keep_msg));
- close(keep_fd);
+ write_or_die(keep_fd, keep_msg, strlen(keep_msg));
+ if (close(keep_fd))
+ die("failed to write keep file");
snprintf(name, sizeof(name), "%s/pack/pack-%s.pack",
get_object_directory(), sha1_to_hex(pack_data->sha1));
--
1.5.4.rc2.85.g71fd
^ permalink raw reply related
* Re: Odd number of elements in anonymous hash
From: Eric Wong @ 2008-01-10 8:38 UTC (permalink / raw)
To: Dennis Schridde; +Cc: Junio C Hamano, git
In-Reply-To: <200801081830.25722.devurandom@gmx.net>
Dennis Schridde <devurandom@gmx.net> wrote:
> Am Dienstag, 8. Januar 2008 18:21:55 schrieb Junio C Hamano:
> > Dennis Schridde <devurandom@gmx.net> writes:
> > > Hello!
> > >
> > > I am getting "Odd number of elements in anonymous hash at
> > > /usr/bin/git-svn line 1760." (normal output, no warning/error) during
> > > git-svn-clone. I am using git version 1.5.4.rc2.
> > >
> > > Line 1760 is this (with context, marked with '!!'):
> > > # see if we have it in our config, first:
> > > eval {
> > > my $section = "svn-remote.$self->{repo_id}";
> > > !! $svnsync = {
> > > url => tmp_config('--get', "$section.svnsync-url"),
> > > uuid => tmp_config('--get', "$section.svnsync-uuid"),
> > > }
> > > };
> > >
> > > The commandline was "git svn
> > > clone --authors-file=/var/git/org.gna.warzone.git/authors
> > > --use-svnsync-props --stdlayout file:///var/svn/warzone2100/
> > > org.gna.warzone.git/"
> > >
> > > I assume this is some kind of bug?
> >
> > More than one svn-remote.$your_repo.svnsync-{url,uuid}?
> PS: It doesn't happen for every revision and the folders (and thus config)
> were empty before. The config doesn't list any "svnsync-*" during the import
> process.
Can you look in .git/svn/.metadata for the svnsync-* values? Thanks.
I downloaded your repository and couldn't reproduce it locally.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] - Updated usage and simplified sub-command action invocation
From: Imran M Yousuf @ 2008-01-10 7:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlve6t69.fsf@gitster.siamese.dyndns.org>
On Jan 10, 2008 1:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Imran M Yousuf" <imyousuf@gmail.com> writes:
>
> > On Jan 10, 2008 12:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > ...
> >> I somehow feel that syntactically the original implementation
> >> that allowed subcommand specific options to come before the
> >> subcommand name was a mistake. It may be easier for users that
> >> both "-b branch add" and "add -b branch" are accepted, but I
> >> have to wonder if it would really hurt if we made "-b branch
> >> add" a syntax error.
> >
> > I will recode it to have all options except for --quiet (which is
> > inverse of -v or --verbose) be mentioned after the subcommand.
>
> Just a word of caution when dealing with me.
>
> Unlike Linus, I am not always right. And other people on the
I will cautiously remember the caution :).
> list who are here longer already know this. I am reasonably sure
> that some of them will disagree with me on design issues like
> this one; I mildly suspect that this forbidding "-b branch add"
> might be met with resistance from existing users.
>
> You do not have to agree with me on every little detail I
> mention. If you feel a design issue might be contentious, it
> could turn out to be a better use of your time to keep the code
> as it is while waiting to see if other people would offer better
> alternatives.
Actually the best design, IMHO, is to have separate commands itself
for them, that is submodule-add, submodule-init, submodule-update,
submodule-status or submodule. I think this would also make it
coherent with other commands such as git-ls, git-merge, git-show. In
that way we could have a common .sh file that will contain the common
functions and can be accessed from the command shell scripts. This
would also make it quite simple.
>
> > Actually module_$command is not possible because only add's module is
> > module_add rest are modules_$command....
>
> Is there a fundamental reason why you cannot rename them to be
> more consistent?
In fact it is consistent, add works on a single module only, whereas
rest of the command works either on 1 or more. Thus having plural
(modules) is logical.
>
Best regards,
--
Imran M Yousuf
^ permalink raw reply
* Re: [PATCH] - Updated usage and simplified sub-command action invocation
From: Junio C Hamano @ 2008-01-10 7:22 UTC (permalink / raw)
To: Imran M Yousuf; +Cc: git
In-Reply-To: <7bfdc29a0801092251p3d46a3cau3db4d57c4f705043@mail.gmail.com>
"Imran M Yousuf" <imyousuf@gmail.com> writes:
> On Jan 10, 2008 12:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> I somehow feel that syntactically the original implementation
>> that allowed subcommand specific options to come before the
>> subcommand name was a mistake. It may be easier for users that
>> both "-b branch add" and "add -b branch" are accepted, but I
>> have to wonder if it would really hurt if we made "-b branch
>> add" a syntax error.
>
> I will recode it to have all options except for --quiet (which is
> inverse of -v or --verbose) be mentioned after the subcommand.
Just a word of caution when dealing with me.
Unlike Linus, I am not always right. And other people on the
list who are here longer already know this. I am reasonably sure
that some of them will disagree with me on design issues like
this one; I mildly suspect that this forbidding "-b branch add"
might be met with resistance from existing users.
You do not have to agree with me on every little detail I
mention. If you feel a design issue might be contentious, it
could turn out to be a better use of your time to keep the code
as it is while waiting to see if other people would offer better
alternatives.
> Actually module_$command is not possible because only add's module is
> module_add rest are modules_$command....
Is there a fundamental reason why you cannot rename them to be
more consistent?
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Marco Costalba @ 2008-01-10 6:55 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin, Sam Vilain, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.1.00.0801092234130.3054@xanadu.home>
On Jan 10, 2008 4:41 AM, Nicolas Pitre <nico@cam.org> wrote:
> On Wed, 9 Jan 2008, Johannes Schindelin wrote:
>
> > I agree that gzip is already fast enough.
> >
> > However, pack v4 had more goodies than just being faster; it also promised
> > to have smaller packs.
>
> Right, like not having to compress tree objects and half of commit
> objects at all.
>
>
Decompression speed has been shown to be a bottle neck on some tests
involving mainly 'git log'.
Regarding back compatibility I really don't know at what level git
functions actually need to know the compression format, looking at the
code I would say at very low level, functions that deal directly with
inflate() and friends are few [1] and not directly connected to UI,
nor to git config. Is this compression format something user should
know/care? and if yes why?
In my tests the assumption of a source files tar ball is unrealistic,
to test the final size difference I would like testing different
compressions on a big already packaged but still not zipped file.
Someone could be so kind to hint me on how to create such a package
with good quality, i.e. with packaging levels similar to what is done
for public repos?
This does not realistically tests speed because as Junio pointed out
the real decompressing schema is different: many calls on small
objects, not one call on a big one. But if final size is acceptable we
can go on more difficult tests.
Marco
[1] where inflate() is called:
-inflate_it() in builtin-apply.c
-check_pack_inflate() in builtin-pack-objects.c
-get_data() in builtin-unpack-objects.c
-fwrite_sha1_file() in http-push.c and http-walker.c [mmm interesting
same function in two files, also the signature and the contents seems
the same....]
-unpack_entry_data() in index-pack.c
-unpack_sha1_header(), unpack_sha1_rest(), get_size_from_delta(),
unpack_compressed_entry, write_sha1_from_fd() in sha1_file.c
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox