* Re: .gitk should created hidden in windows
From: Johannes Schindelin @ 2009-03-24 2:14 UTC (permalink / raw)
To: John Tapsell; +Cc: Paul Mackerras, Steve Wagner, git
In-Reply-To: <43d8ce650903231908y54bb1c34t45a78f218b2ccd9f@mail.gmail.com>
Hi,
On Tue, 24 Mar 2009, John Tapsell wrote:
> How about making all files beginning with . hidden? .gitignore for
> example
Uhm.
Did you miss that this patch was about gitk, not git.git?
Ciao,
Dscho
^ permalink raw reply
* Re: .gitk should created hidden in windows
From: John Tapsell @ 2009-03-24 2:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Steve Wagner, git
In-Reply-To: <18887.26239.115820.450313@cargo.ozlabs.ibm.com>
2009/3/23 Paul Mackerras <paulus@samba.org>:
> Steve Wagner writes:
>
>> The problem is that windows dose not hides files beginning with a dot as
>> it is in unix. So the .gitk file is created as visible in the windows
>> user profile. Problematic too is that i can no set the hidden attribute
>> to this file, because it is recreated every time i start gitk, so the
>> hidden attribute gets lost.
>>
>> Can you control this and create the file with the hidden attribute on
>> windows?
>
> Please try this patch and let me know if it does what you want.
>
> Paul.
>
> diff --git a/gitk b/gitk
> index d7de27e..54f3f2b 100755
> --- a/gitk
> +++ b/gitk
> @@ -2487,6 +2487,9 @@ proc savestuff {w} {
> if {![winfo viewable .]} return
> catch {
> set f [open "~/.gitk-new" w]
> + if {$::tcl_platform(platform) eq {windows}} {
> + file attributes "~/.gitk-new" -hidden true
> + }
> puts $f [list set mainfont $mainfont]
> puts $f [list set textfont $textfont]
> puts $f [list set uifont $uifont]
How about making all files beginning with . hidden? .gitignore for example
^ permalink raw reply
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Junio C Hamano @ 2009-03-24 2:08 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Michael J Gruber, Jeff King, git
In-Reply-To: <94a0d4530903231721i2a2a6fc1yf54d4303283ec415@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
>> Also, it seems that everything which is not black is blue, except for
>> terms, which are green and slanted. I don't think that looks nice
>> together. How about slanted blue?
>
> What's wrong with having 2 colors?
I personally also do not like pages that are too colorful. If you can
convey the same information with smaller number of colors, please try to
do so. And remember that some people are colour-challenged.
By the way, are you using a font that is a bit smaller than the body text
to render the examples? I find it harder to read.
I thought that browsers typically have user control to let you set the
standard font size and choice independently for proportional, serif, sans
and mono, and people who want to see typewriter face in smaller font would
already have set their browser to do so (I don't do so myself because I'd
rather want to see them in uniform size). I haven't checked your CSS, but
if you are doing "monospace smaller than usual", aren't you effectively
(1) doing disservice to people like me, and (2) doing disservice to people
who do want smaller monospace and configured their browser already (the
outcome would be doubly smaller, which may become too small)?
^ permalink raw reply
* Re: Git for Windows 1.6.2.1-preview20090322
From: Johannes Schindelin @ 2009-03-24 2:06 UTC (permalink / raw)
To: Ludvig Strigeus; +Cc: git, msysgit
In-Reply-To: <4285cd450903231503x5d332bfft17b01e598d11bc09@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 719 bytes --]
Hi,
On Mon, 23 Mar 2009, Ludvig Strigeus wrote:
>
> On Sun, Mar 22, 2009 at 10:17 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > - There are a few issues with ssh hanging (Issue 197), permission
> > denied on renaming pack files (mentioned in Issue 194), and
> > spurious write errors during rebase (Issue 200) that seem not to be
> > reproducible on most computers.
>
> I had this problem with write errors during rebase. I tracked it down
> to having the files open in Visual Studio while doing the rebase.
It seems pretty clear from the original report (or at least from the
following comments) that the files haven't been opened anywhere.
But thanks for your help!
Ciao,
Dscho
^ permalink raw reply
* Re: Git for Windows 1.6.2.1-preview20090322
From: Johannes Schindelin @ 2009-03-24 2:04 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: git, msysgit
In-Reply-To: <200903240235.25192.markus.heidelberg@web.de>
Hi,
On Tue, 24 Mar 2009, Markus Heidelberg wrote:
> the company I'm working for plans to switch from our current commercial
> VCS, now I have the job to compare different tools (svn, git). Our
> clients run on Windows and probably our offices in foreign countries
> should work on our repository, too.
This...
> Johannes Schindelin, 22.03.2009:
> > Disclaimer: Git for Windows is still in a state where I do _not_
> > recommend using it unless you have the means to fix issues. Unlike
> > the git.git developer community, the msysGit team is heavily
> > undermanned.
... and this make me believe that Git for Windows is not at all what you
want. You seem to want to purely _use_ Git, and at this time, it is just
not there.
It would be different if you/your company were willing to pay for support,
but I just do not see from your mail that you are willing to contribute to
Git for Windows.
> > - If you want to specify a different location for --upload-pack, you
> > have to start the absolute path with two slashes. Otherwise MSys
> > will mangle the path.
>
> Only for msysgit on the server side, right? Then, never mind.
Nope. There is no msysgit on the server side. So no, it applies to the
client side.
> > - git and bash have serious problems with non-ASCII file names (Issue
> > 80, 108, 149, 159, 188).
>
> This may be a problem.
Indeed. I mean, 5 issues, and none of them resolved.
> > - If configured to use plink, you will have to connect with putty
> > first, as you cannot accept the host key due to the console window
> > being blocked (Issue 96).
>
> Just use OpenSSH?
> Problem in GUIs or only CLI?
See the issue if you want to know more.
> > - There are a few issues with ssh hanging (Issue 197), permission
> > denied on renaming pack files (mentioned in Issue 194), and spurious
> > write errors during rebase (Issue 200) that seem not to be
> > reproducible on most computers.
>
> OK, strange and not reproducible errors are a little bit scary.
A little scary? No. _Very_ scary.
Especially since the involved parties either do not have the time or the
willingness to investigate in detail.
As these issues are not reproducible on my side, it also does not make me
think more highly of that particular Operating System.
> I suppose there are already people using msysgit productive at work, are
> these only people who know how to fix such problems?
Yes.
> Regardless of git's Windows problems, another problem will probably be
> finding a decent GUI that suits my colleagues.
Yes.
Ciao,
Dscho
^ permalink raw reply
* Re: .gitk should created hidden in windows
From: Johannes Schindelin @ 2009-03-24 1:39 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Paul Mackerras, Steve Wagner, git
In-Reply-To: <49C82377.40101@users.sourceforge.net>
Hi,
On Tue, 24 Mar 2009, Pat Thoyts wrote:
> Paul Mackerras wrote:
> > Please try this patch and let me know if it does what you want.
> >
> [snip]
>
> This patch works fine on my Vista installation. The .gitk file is now
> hidden.
>
> An alternative that was discussed was to move it rather than hide it so
> that it ends up in the Application Data folder along with settings for
> other applications. The following patch does this but hits rather more
> lines of code and ends up needing to check the original location as
> well.
While I see your point, keep in mind that this patch would make Git for
Windows even more incompatible with Git "In The Rest Of The World"...
Ciao,
Dscho
^ permalink raw reply
* Re: Git for Windows 1.6.2.1-preview20090322
From: Markus Heidelberg @ 2009-03-24 1:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
In-Reply-To: <alpine.DEB.1.00.0903222149330.10279@pacific.mpi-cbg.de>
Hi,
the company I'm working for plans to switch from our current commercial
VCS, now I have the job to compare different tools (svn, git). Our
clients run on Windows and probably our offices in foreign countries
should work on our repository, too.
Johannes Schindelin, 22.03.2009:
> Disclaimer: Git for Windows is still in a state where I do _not_ recommend
> using it unless you have the means to fix issues. Unlike the git.git
> developer community, the msysGit team is heavily undermanned.
>
> Known issues
I favor git, but I have to be objective and if there are serious issues,
this will obviously influence the decision. Since the list below is not
complete, I guess these are just the most serious issues, and then it
doesn't sound too scary for the everyday use. Let me comment on them for
our workflow:
> - Some commands are not yet supported on Windows and excluded from the
> installation; namely: git archimport, git cvsexportcommit, git
> cvsimport, git cvsserver, git filter-branch, git instaweb, git
> send-email, git shell.
Not necessary.
> - The Logitec QuickCam software can cause spurious crashes. See "Why does
> make often crash creating a sh.exe.stackdump file when I try to compile
> my source code?" on the MinGW Wiki
> (http://www.mingw.org/wiki/Environment_issues)
Not plugged-in.
> - The Quick Launch icon will only be installed for the user running setup
> (typically the Administrator). This is a technical restriction and will
> not change.
Never mind.
> - Git Bash launched through the Explorer shell extension does not have the
> git icon in its taskbar. This is a technical restriction and will not
> change.
Never mind. Probably I would be the only one using the CLI anyway.
> - git send-mail does not work properly (Issue 27).
Not necessary.
> - curl uses $HOME/_netrc instead of $HOME/.netrc.
Never mind.
> - If you want to specify a different location for --upload-pack, you have
> to start the absolute path with two slashes. Otherwise MSys will mangle
> the path.
Only for msysgit on the server side, right? Then, never mind.
> - git and bash have serious problems with non-ASCII file names (Issue 80,
> 108, 149, 159, 188).
This may be a problem.
> - If configured to use plink, you will have to connect with putty first,
> as you cannot accept the host key due to the console window being
> blocked (Issue 96).
Just use OpenSSH?
Problem in GUIs or only CLI?
> - MinGW does not support IPv6 yet (Issue 182).
Not necessary.
> - When run from cmd.exe instead of Git Bash, some characters seem to be
> "swallowed" from Git's output (Issue 192).
Never mind.
> - There are a few issues with ssh hanging (Issue 197), permission denied
> on renaming pack files (mentioned in Issue 194), and spurious write
> errors during rebase (Issue 200) that seem not to be reproducible on
> most computers.
OK, strange and not reproducible errors are a little bit scary.
So, most of these issues I don't consider to be serious for us, but I
guess the remaining "real" issues let you stay at your opinion, not to
recommend using it, don't they?
I suppose there are already people using msysgit productive at work,
are these only people who know how to fix such problems?
Regardless of git's Windows problems, another problem will probably be
finding a decent GUI that suits my colleagues.
Markus
^ permalink raw reply
* Re: [PATCH 9/9] refs: use warning() instead of fprintf(stderr, "warning: ")
From: Erik Faye-Lund @ 2009-03-24 1:28 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <20090324012334.GL27459@genesis.frugalware.org>
OK, sorry for not reading the old discussion before commenting. :)
On Tue, Mar 24, 2009 at 2:23 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Tue, Mar 24, 2009 at 02:17:24AM +0100, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
>> > @@ -996,7 +996,7 @@ int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
>> >
>> > err = unlink(git_path("logs/%s", lock->ref_name));
>> > if (err && errno != ENOENT)
>> > - fprintf(stderr, "warning: unlink(%s) failed: %s",
>> > + warning("unlink(%s) failed: %s",
>>
>> Doesn't this add a newline? The original string doesn't have a '\n' at
>> the end of the format-field, but AFAIK warning() terminates with one.
>> I'm not saying it's a problem, I'm just pointing it out.
>
> Yes, it adds. As Jeff pointed out earlier in this thread, the lack of
> newline was a bug:
>
> http://article.gmane.org/gmane.comp.version-control.git/110783
>
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH 2/9] builtin-apply: use warning() instead of fprintf(stderr, "warning: ")
From: Erik Faye-Lund @ 2009-03-24 1:25 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <9287282d966904f06ae4b3d7cfdf1d79eb645b69.1237856682.git.vmiklos@frugalware.org>
On Tue, Mar 24, 2009 at 2:09 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> @@ -2932,8 +2932,7 @@ static int write_out_one_reject(struct patch *patch)
> cnt = strlen(patch->new_name);
> if (ARRAY_SIZE(namebuf) <= cnt + 5) {
> cnt = ARRAY_SIZE(namebuf) - 5;
> - fprintf(stderr,
> - "warning: truncating .rej filename to %.*s.rej",
> + warning("truncating .rej filename to %.*s.rej",
Again, doesn't this change the output?
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH 9/9] refs: use warning() instead of fprintf(stderr, "warning: ")
From: Miklos Vajna @ 2009-03-24 1:23 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Junio C Hamano, Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <40aa078e0903231817g41fd1bc1s296121d85923f7ea@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]
On Tue, Mar 24, 2009 at 02:17:24AM +0100, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> > @@ -996,7 +996,7 @@ int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
> >
> > err = unlink(git_path("logs/%s", lock->ref_name));
> > if (err && errno != ENOENT)
> > - fprintf(stderr, "warning: unlink(%s) failed: %s",
> > + warning("unlink(%s) failed: %s",
>
> Doesn't this add a newline? The original string doesn't have a '\n' at
> the end of the format-field, but AFAIK warning() terminates with one.
> I'm not saying it's a problem, I'm just pointing it out.
Yes, it adds. As Jeff pointed out earlier in this thread, the lack of
newline was a bug:
http://article.gmane.org/gmane.comp.version-control.git/110783
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: large(25G) repository in git
From: Nicolas Pitre @ 2009-03-24 1:19 UTC (permalink / raw)
To: Adam Heath; +Cc: git
In-Reply-To: <49C7FAB3.7080301@brainfood.com>
On Mon, 23 Mar 2009, Adam Heath wrote:
> Last friday, I was doing a checkin on the production server, and found
> 1.6G of new files. git was quite able at committing that. However,
> pushing was problematic. I was pushing over ssh; so, a new ssh
> connection was open to the preview server. After doing so, git tried
> to create a new pack file. This took *ages*, and the ssh connection
> died. So did git, when it finally got done with the new pack, and
> discovered the ssh connection was gone.
Strange. You could instruct ssh to keep the connection up with the
ServerAliveInterval option (see the ssh_config man page).
> So, to work around that, I ran git gc. When done, I discovered that
> git repacked the *entire* repository. While not something I care for,
> I can understand that, and live with it. It just took *hours* to do so.
>
> Then, what really annoys me, is that when I finally did the push, it
> tried sending the single 27G pack file, when the remote already had
> 25G of the repository in several different packs(the site was an
> hg->git conversion). This part is just unacceptable.
This shouldn't happen either. When pushing, git reconstruct a pack with
only the necessary objects to transmit. Are you sure it was really
trying to send a 27G pack?
> So, here are my questions/observations:
>
> 1: Handle the case of the ssh connection dying during git push(seems
> simple).
See above.
> 2: Is there an option to tell git to *not* be so thorough when trying
> to find similiar files. videos/doc/pdf/etc aren't always very
> deltafiable, so I'd be happy to just do full content compares.
Look at the gitattribute documentation. One thing that the doc appears
to be missing is information about the "delta" attribute. You can
disable delta compression on a file pattern that way.
> 3: delta packs seem to be poorly done. it seems that if one repo gets
> repacked completely, that the entire new pack gets sent, when the
> target has most of the objects already.
This is not supposed to happen. Please provide more details if you can.
Nicolas
^ permalink raw reply
* Re: [PATCH 9/9] refs: use warning() instead of fprintf(stderr, "warning: ")
From: Erik Faye-Lund @ 2009-03-24 1:17 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <f6b2ede9af2bd40ce89f0251b32861098af46aad.1237856682.git.vmiklos@frugalware.org>
> @@ -996,7 +996,7 @@ int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
>
> err = unlink(git_path("logs/%s", lock->ref_name));
> if (err && errno != ENOENT)
> - fprintf(stderr, "warning: unlink(%s) failed: %s",
> + warning("unlink(%s) failed: %s",
Doesn't this add a newline? The original string doesn't have a '\n' at
the end of the format-field, but AFAIK warning() terminates with one.
I'm not saying it's a problem, I'm just pointing it out.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* [PATCH 1/9] http-push: using error() and warning() as appropriate
From: Miklos Vajna @ 2009-03-24 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <cover.1237856682.git.vmiklos@frugalware.org>
Change three occurences of using inconsistent error/warning reporting by
using the relevant error() / warning() calls to be consitent with the
rest of the code.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
http-push.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/http-push.c b/http-push.c
index 48e5f38..e6bd01a 100644
--- a/http-push.c
+++ b/http-push.c
@@ -759,7 +759,7 @@ static void finish_request(struct transfer_request *request)
}
} else {
if (request->http_code == 416)
- fprintf(stderr, "Warning: requested range invalid; we may already have all the data.\n");
+ warning("requested range invalid; we may already have all the data.");
git_inflate_end(&request->stream);
git_SHA1_Final(request->real_sha1, &request->c);
@@ -1616,7 +1616,7 @@ static int locking_available(void)
}
XML_ParserFree(parser);
if (!lock_flags)
- error("Error: no DAV locking support on %s",
+ error("no DAV locking support on %s",
remote->url);
} else {
@@ -2225,7 +2225,7 @@ int main(int argc, char **argv)
if (info_ref_lock)
remote->can_update_info_refs = 1;
else {
- fprintf(stderr, "Error: cannot lock existing info/refs\n");
+ error("cannot lock existing info/refs");
rc = 1;
goto cleanup;
}
--
1.6.2
^ permalink raw reply related
* [PATCH 8/9] builtin-show-ref: use warning() instead of fprintf(stderr, "warning: ")
From: Miklos Vajna @ 2009-03-24 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <cover.1237856682.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-show-ref.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-show-ref.c b/builtin-show-ref.c
index 572b114..dc76c50 100644
--- a/builtin-show-ref.c
+++ b/builtin-show-ref.c
@@ -140,7 +140,7 @@ static int exclude_existing(const char *match)
continue;
}
if (check_ref_format(ref)) {
- fprintf(stderr, "warning: ref '%s' ignored\n", ref);
+ warning("ref '%s' ignored", ref);
continue;
}
if (!string_list_has_string(&existing_refs, ref)) {
--
1.6.2
^ permalink raw reply related
* [PATCH 9/9] refs: use warning() instead of fprintf(stderr, "warning: ")
From: Miklos Vajna @ 2009-03-24 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <cover.1237856682.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
refs.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/refs.c b/refs.c
index 8d3c502..aeef257 100644
--- a/refs.c
+++ b/refs.c
@@ -996,7 +996,7 @@ int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
err = unlink(git_path("logs/%s", lock->ref_name));
if (err && errno != ENOENT)
- fprintf(stderr, "warning: unlink(%s) failed: %s",
+ warning("unlink(%s) failed: %s",
git_path("logs/%s", lock->ref_name), strerror(errno));
invalidate_cached_refs();
unlock_ref(lock);
@@ -1438,8 +1438,7 @@ int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *
if (get_sha1_hex(rec + 41, sha1))
die("Log %s is corrupt.", logfile);
if (hashcmp(logged_sha1, sha1)) {
- fprintf(stderr,
- "warning: Log %s has gap after %s.\n",
+ warning("Log %s has gap after %s.",
logfile, show_date(date, tz, DATE_RFC2822));
}
}
@@ -1451,8 +1450,7 @@ int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *
if (get_sha1_hex(rec + 41, logged_sha1))
die("Log %s is corrupt.", logfile);
if (hashcmp(logged_sha1, sha1)) {
- fprintf(stderr,
- "warning: Log %s unexpectedly ended on %s.\n",
+ warning("Log %s unexpectedly ended on %s.",
logfile, show_date(date, tz, DATE_RFC2822));
}
}
--
1.6.2
^ permalink raw reply related
* [PATCH 5/9] builtin-init-db: use warning() instead of fprintf(stderr, "warning: ")
From: Miklos Vajna @ 2009-03-24 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <cover.1237856682.git.vmiklos@frugalware.org>
---
builtin-init-db.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index ee3911f..fc63d0f 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -130,8 +130,7 @@ static void copy_templates(const char *template_dir)
}
dir = opendir(template_path);
if (!dir) {
- fprintf(stderr, "warning: templates not found %s\n",
- template_dir);
+ warning("templates not found %s", template_dir);
return;
}
@@ -144,8 +143,8 @@ static void copy_templates(const char *template_dir)
if (repository_format_version &&
repository_format_version != GIT_REPO_VERSION) {
- fprintf(stderr, "warning: not copying templates of "
- "a wrong format version %d from '%s'\n",
+ warning("not copying templates of "
+ "a wrong format version %d from '%s'",
repository_format_version,
template_dir);
closedir(dir);
--
1.6.2
^ permalink raw reply related
* [PATCH 7/9] builtin-show-branch: use warning() instead of fprintf(stderr, "warning: ")
From: Miklos Vajna @ 2009-03-24 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <cover.1237856682.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-show-branch.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index 306b850..828e6f8 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -365,8 +365,7 @@ static int append_ref(const char *refname, const unsigned char *sha1,
return 0;
}
if (MAX_REVS <= ref_name_cnt) {
- fprintf(stderr, "warning: ignoring %s; "
- "cannot handle more than %d refs\n",
+ warning("ignoring %s; cannot handle more than %d refs",
refname, MAX_REVS);
return 0;
}
--
1.6.2
^ permalink raw reply related
* [PATCH 6/9] builtin-rm: use warning() instead of fprintf(stderr, "warning: ")
From: Miklos Vajna @ 2009-03-24 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <cover.1237856682.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-rm.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/builtin-rm.c b/builtin-rm.c
index c11f455..269d608 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -59,8 +59,7 @@ static int check_local_mod(unsigned char *head, int index_only)
if (lstat(ce->name, &st) < 0) {
if (errno != ENOENT)
- fprintf(stderr, "warning: '%s': %s",
- ce->name, strerror(errno));
+ warning("'%s': %s", ce->name, strerror(errno));
/* It already vanished from the working tree */
continue;
}
--
1.6.2
^ permalink raw reply related
* [PATCH 4/9] builtin-fetch-pack: use warning() instead of fprintf(stderr, "warning: ")
From: Miklos Vajna @ 2009-03-24 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <cover.1237856682.git.vmiklos@frugalware.org>
---
builtin-fetch-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index d571253..5d134be 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -605,7 +605,7 @@ static struct ref *do_fetch_pack(int fd[2],
/* When cloning, it is not unusual to have
* no common commit.
*/
- fprintf(stderr, "warning: no common commits\n");
+ warning("no common commits");
if (get_pack(fd, pack_lockfile))
die("git fetch-pack: fetch failed.");
--
1.6.2
^ permalink raw reply related
* [PATCH 2/9] builtin-apply: use warning() instead of fprintf(stderr, "warning: ")
From: Miklos Vajna @ 2009-03-24 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <cover.1237856682.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-apply.c | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index b52aa20..1926cd8 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2451,7 +2451,7 @@ static int check_preimage(struct patch *patch, struct cache_entry **ce, struct s
if ((st_mode ^ patch->old_mode) & S_IFMT)
return error("%s: wrong type", old_name);
if (st_mode != patch->old_mode)
- fprintf(stderr, "warning: %s has type %o, expected %o\n",
+ warning("%s has type %o, expected %o",
old_name, st_mode, patch->old_mode);
if (!patch->new_mode && !patch->is_delete)
patch->new_mode = st_mode;
@@ -2932,8 +2932,7 @@ static int write_out_one_reject(struct patch *patch)
cnt = strlen(patch->new_name);
if (ARRAY_SIZE(namebuf) <= cnt + 5) {
cnt = ARRAY_SIZE(namebuf) - 5;
- fprintf(stderr,
- "warning: truncating .rej filename to %.*s.rej",
+ warning("truncating .rej filename to %.*s.rej",
cnt - 1, patch->new_name);
}
memcpy(namebuf, patch->new_name, cnt);
@@ -3315,8 +3314,8 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
squelch_whitespace_errors < whitespace_error) {
int squelched =
whitespace_error - squelch_whitespace_errors;
- fprintf(stderr, "warning: squelched %d "
- "whitespace error%s\n",
+ warning("squelched %d "
+ "whitespace error%s",
squelched,
squelched == 1 ? "" : "s");
}
@@ -3326,12 +3325,12 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
whitespace_error == 1 ? "" : "s",
whitespace_error == 1 ? "s" : "");
if (applied_after_fixing_ws && apply)
- fprintf(stderr, "warning: %d line%s applied after"
- " fixing whitespace errors.\n",
+ warning("%d line%s applied after"
+ " fixing whitespace errors.",
applied_after_fixing_ws,
applied_after_fixing_ws == 1 ? "" : "s");
else if (whitespace_error)
- fprintf(stderr, "warning: %d line%s add%s whitespace errors.\n",
+ warning("%d line%s add%s whitespace errors.",
whitespace_error,
whitespace_error == 1 ? "" : "s",
whitespace_error == 1 ? "s" : "");
--
1.6.2
^ permalink raw reply related
* [PATCH 0/9] fprintf(stderr, "warning: ") -> warning() patches
From: Miklos Vajna @ 2009-03-24 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <7v3ad5dxt5.fsf@gitster.siamese.dyndns.org>
On Sun, Mar 22, 2009 at 02:58:46PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > Should I rebase the series against current master and resend?
>
> Yes, please, if the overlap with "diff master next" is small enough.
Okay, here it is, applies on top of master. All, except the http-push
one, applies cleanly on top of next as well here.
Miklos Vajna (9):
http-push: using error() and warning() as appropriate
builtin-apply: use warning() instead of fprintf(stderr, "warning: ")
builtin-checkout: use warning() instead of fprintf(stderr, "warning:
")
builtin-fetch-pack: use warning() instead of fprintf(stderr,
"warning: ")
builtin-init-db: use warning() instead of fprintf(stderr, "warning:
")
builtin-rm: use warning() instead of fprintf(stderr, "warning: ")
builtin-show-branch: use warning() instead of fprintf(stderr,
"warning: ")
builtin-show-ref: use warning() instead of fprintf(stderr, "warning:
")
refs: use warning() instead of fprintf(stderr, "warning: ")
builtin-apply.c | 15 +++++++--------
builtin-checkout.c | 4 ++--
builtin-fetch-pack.c | 2 +-
builtin-init-db.c | 7 +++----
builtin-rm.c | 3 +--
builtin-show-branch.c | 3 +--
builtin-show-ref.c | 2 +-
http-push.c | 6 +++---
refs.c | 8 +++-----
9 files changed, 22 insertions(+), 28 deletions(-)
^ permalink raw reply
* [PATCH 3/9] builtin-checkout: use warning() instead of fprintf(stderr, "warning: ")
From: Miklos Vajna @ 2009-03-24 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, John Tapsell, Git Mailing List
In-Reply-To: <cover.1237856682.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-checkout.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 9fdfc58..fc55bbe 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -558,8 +558,8 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
if (!old.commit && !opts->force) {
if (!opts->quiet) {
- fprintf(stderr, "warning: You appear to be on a branch yet to be born.\n");
- fprintf(stderr, "warning: Forcing checkout of %s.\n", new->name);
+ warning("You appear to be on a branch yet to be born.");
+ warning("Forcing checkout of %s.", new->name);
}
opts->force = 1;
}
--
1.6.2
^ permalink raw reply related
* GIT BUG? GIT occasionally redownloads its entire data set
From: David Howells @ 2009-03-24 0:45 UTC (permalink / raw)
To: git; +Cc: dhowells
Hi,
I'm seeing a possible bug in which GIT, in which I issue a git-pull command on
a tree that was okay the day before, GIT reports that there are "no common
commits" and then redownloads the entire tree (as far as I can tell).
This happened just now when I did I git-pull on a GIT repository that I think
went from Monday morning's head:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59fcbddaff6f862cc1584b488866d9c4a5579085
to v2.6.29. I've attached the command output for reference.
I've seen this a number of times. It has been suggested this usually happens
when a new version tag is committed, but I wouldn't normally see that as the
git-pull to my base repository is normally run by crond.
This bug is annoying as it can eat a big chunk out of the download quota set by
my ISP.
David
---
warthog>git-pull
remote: Counting objects: 447, done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 266 (delta 216), reused 254 (delta 207)
Receiving objects: 100% (266/266), 37.94 KiB, done.
Resolving deltas: 100% (216/216), completed with 105 local objects.
warning: no common commits
remote: Counting objects: 1075436, done.
remote: Compressing objects: 100% (176743/176743), done.
remote: Total 1075436 (delta 896164), reused 1072243 (delta 893708)
Receiving objects: 100% (1075436/1075436), 260.71 MiB | 307 KiB/s, done.
Resolving deltas: 100% (896164/896164), done.
From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
* [new tag] v2.6.29 -> v2.6.29
Updating 59fcbdd..8e0ee43
Fast forward
Documentation/filesystems/ext2.txt | 5 +-
Documentation/filesystems/proc.txt | 7 +++
Makefile | 7 ++-
arch/powerpc/kernel/head_32.S | 9 ++++
arch/sparc/include/asm/pil.h | 1 +
arch/sparc/kernel/kgdb_64.c | 2 +-
arch/sparc/kernel/pci_common.c | 2 +-
arch/sparc/kernel/ttable.S | 7 +++-
arch/sparc/mm/ultra.S | 24 +----------
drivers/dca/dca-sysfs.c | 21 ++++++++++
drivers/isdn/gigaset/bas-gigaset.c | 16 ++++++-
drivers/net/Kconfig | 2 +-
drivers/net/benet/be.h | 1 +
drivers/net/benet/be_main.c | 60 ++++++++++++++++------------
drivers/net/bnx2.c | 12 +++---
drivers/net/bonding/bond_main.c | 25 ++++++++++--
drivers/net/dm9000.c | 6 ++-
drivers/net/dnet.c | 6 +-
drivers/net/sh_eth.c | 20 ++++++++-
drivers/net/sh_eth.h | 4 +-
drivers/net/smsc911x.c | 4 ++
drivers/net/sungem.c | 9 ++--
drivers/net/tulip/tulip_core.c | 45 ++++++++++++++--------
drivers/net/ucc_geth.c | 34 +++++-----------
drivers/net/ucc_geth.h | 3 +-
drivers/net/virtio_net.c | 3 +
drivers/net/wireless/ath9k/ath9k.h | 4 +-
drivers/net/wireless/ath9k/core.h | 33 ++++++++++++++++
drivers/net/wireless/ath9k/hw.c | 22 ++++++++++-
drivers/net/wireless/ath9k/main.c | 1 +
drivers/net/wireless/zd1211rw/zd_mac.c | 8 +++-
drivers/sbus/char/openprom.c | 1 +
include/linux/dca.h | 20 ++++++++++
include/net/netfilter/nf_conntrack_core.h | 3 +-
kernel/signal.c | 8 ++++
net/core/dev.c | 7 ++-
net/ipv4/ip_fragment.c | 3 +-
net/ipv6/netfilter/nf_conntrack_reasm.c | 8 ++--
net/ipv6/reassembly.c | 7 +--
net/ipv6/sit.c | 2 +-
net/mac80211/tx.c | 2 +
net/netfilter/nf_conntrack_core.c | 2 +-
net/netfilter/nf_conntrack_netlink.c | 1 +
net/netfilter/nf_conntrack_proto_tcp.c | 4 +-
net/sctp/endpointola.c | 3 +-
net/wireless/Kconfig | 10 +++++
net/wireless/lib80211_crypt_ccmp.c | 2 +
net/wireless/lib80211_crypt_tkip.c | 4 ++
net/wireless/nl80211.c | 11 +++++
49 files changed, 351 insertions(+), 150 deletions(-)
warthog>
^ permalink raw reply
* Re: [RFC/PATCH 8/8] user-manual: simplify the user configuration
From: Felipe Contreras @ 2009-03-24 0:22 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <52360AC9-EAE8-4DC3-9368-7220A034E0B5@wincent.com>
On Mon, Mar 23, 2009 at 1:09 PM, Wincent Colaiuta <win@wincent.com> wrote:
> El 23/3/2009, a las 12:07, Felipe Contreras escribió:
>
>> On Mon, Mar 23, 2009 at 2:07 AM, Wincent Colaiuta <win@wincent.com> wrote:
>>>
>>> El 23/3/2009, a las 0:01, Felipe Contreras escribió:
>>>
>>>> On Mon, Mar 23, 2009 at 12:42 AM, Wincent Colaiuta <win@wincent.com>
>>>> wrote:
>>>>>
>>>>> El 22/3/2009, a las 19:05, Felipe Contreras escribió:
>>>>>
>>>>>> This is shorter, avoids the burder to think about the format of the
>>>>>> configuration file, and git config is already used in other places in
>>>>>> the manual.
>>>>>>
>>>>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>>>>> ---
>>>>>> Documentation/user-manual.txt | 8 +++-----
>>>>>> 1 files changed, 3 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/Documentation/user-manual.txt
>>>>>> b/Documentation/user-manual.txt
>>>>>> index b7678aa..c6ed940 100644
>>>>>> --- a/Documentation/user-manual.txt
>>>>>> +++ b/Documentation/user-manual.txt
>>>>>> @@ -1015,13 +1015,11 @@ Telling git your name
>>>>>> ---------------------
>>>>>>
>>>>>> Before creating any commits, you should introduce yourself to git.
>>>>>> The
>>>>>> -easiest way to do so is to make sure the following lines appear in a
>>>>>> -file named `.gitconfig` in your home directory:
>>>>>> +easiest way is to use the linkgit:git-config[1] command:
>>>>>>
>>>>>> ------------------------------------------------
>>>>>> -[user]
>>>>>> - name = Your Name Comes Here
>>>>>> - email = you@yourdomain.example.com
>>>>>> +$ git config --global user.name "Your Name Comes Here"
>>>>>> +$ git config --global user.email you@yourdomain.example.com
>>>>>> ------------------------------------------------
>>>>>>
>>>>>> (See the '"CONFIGURATION FILE"' section of linkgit:git-config[1] for
>>>>>> --
>>>>>> 1.6.2.1.352.gae594
>>>>>
>>>>> See this lengthy thread:
>>>>>
>>>>> http://article.gmane.org/gmane.comp.version-control.git/106634
>>>>
>>>> I've obviously seen that thread because I started it.
>>>
>>> Yeah, I noticed that only after sending my message. I hadn't realised at
>>> first because the patch really looked like it was written by someone who
>>> hadn't ever seen the thread, as it doesn't address the points raised in
>>> the
>>> thread at all.
>>
>> I am addressing the points.
>
> Sorry for not noticing the other patch in the series. I fired off the email
> because when I read 8/8 I thought, "This looks almost exactly like a patch
> that was previously rejected".
It's ok, thanks for the comment, I'll keep that in mind for the patch series.
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Felipe Contreras @ 2009-03-24 0:21 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jeff King, git
In-Reply-To: <49C7A8AF.9080500@drmicha.warpmail.net>
On Mon, Mar 23, 2009 at 5:20 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 23.03.2009 11:31:
>> On Mon, Mar 23, 2009 at 8:42 AM, Jeff King <peff@peff.net> wrote:
>>> On Sun, Mar 22, 2009 at 08:05:15PM +0200, Felipe Contreras wrote:
>>>
>>>> tt.literal, code.literal {
>>>> color: navy;
>>>> + font-size: 1em;
>>>> +}
>>>
>>> Isn't 1em already the default size? Or are you trying to override some
>>> other size specification elsewhere? It's hard to tell what the goal is
>>> because your commit message merely says "improve".
>>
>> That's correct.
>>
>> The problem is that when the user has a different size for the
>> sans-serif and monospace fonts it looks horrible when they are on the
>> same paragraph. I thought 1em did the trick, but you are right, it
>> doesn't.
>>
>> It looks like the only way to fix this is to set absolute sizes.
>>
>
> Also, it seems that everything which is not black is blue, except for
> terms, which are green and slanted. I don't think that looks nice
> together. How about slanted blue?
What's wrong with having 2 colors?
--
Felipe Contreras
^ 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